Кроссбраузерное тестирование: бесплатно и быстро

Кроссбраузерное тестирование - это особый вид тестирования, проводимый с целью проверить работу веб приложения в различных браузерах.

Есть множество онлайн-сервисов для кроссбраузерного тестирования веб приложений. Если выбирать из бесплатных, то мне больше всего нравится сервис Modern IE: http://loc.modern.ie/ru

Это самый лучший из найденных мной сервисов, позволяющих проверить внешний вид странички вашего веб приложения во множестве браузеров, включая браузеры на мобильных устройствах. Он просто делает скриншоты и вы можете их посмотреть или приложить к багу, если в каких-то браузерах веб страничка отображается неправильно.

Он так же умеет анализировать страницу и давать рекомендации о том, что можно было бы изменить для того, чтобы страница выглядела одинаково в различных браузерах. Для этого достаточно всего лишь ввести адрес приложения и нажать одну кнопку!

Партизанский баг

Самые интересные баги - это баги-провокаторы, баги-партизаны. Они ну никак не должны были выжить при тестировании и всё-таки они здесь, живут себе спокойно и попадаются пользователям.

Это что называется "недотестировали". Не подумали, что такая ситуация возможна (или подумали, но забыли записать). Не обратили внимания, списали на устаревший кэш браузера или проблемы настройки.

Всё бы ничего, но это баг на сайте сервиса кроссбраузерного тестирования. И воспроизвёлся он в обычном Firefox 27.0.1.

Эти баги очень интересно находить на каких-то случайных ресурсах, особенно посвящённых тестированию или на каких-нибудь серьёзных сайтах. К таким ресурсам всегда высокий уровень доверия и как-то не ожидаешь таких простых ошибок, а они всё равно есть.

Без тестировщиков: тестирование интерфейса на основе документации

   На SQA Days 12 мы обсуждали "будущее тестирования". Каким оно будет через десять лет? Умные роботы, которые сами ищут баги, а лучше и сразу их исправляют?


   И вот не так давно мы начали работу над новым проектом, и для документирования API на этом проекте разработчики воспользовались сервисом apiary.

   Обычно мы пишем тесты для API на Python, запуская nosetests и получаем отчёт в Jenkins CI. Если проект активно развивается, то API постоянно расширяется и изменяется, тесты постоянно необходимо поддерживать в актуальном состоянии.
   То есть мы каждый день начинаем с проверки последних запусков автоматизированных тестов и общения с разработчиком, который подсказывает нам, как мы можем протестировать новые функции, которые он добавил вчера.
   Казалось бы, как можно иначе?

Yandex Tank для нагрузочного тестирования API интерфейсов

"Каждую печеньку заворачивай в отдельные скобки"

Из разговоров QA команды во время

написания нагрузочных сценариев

  Я занимаюсь нагрузочным тестированием не каждый день, но когда я делаю это, я использую Яндекс Танк.
  Существует множество других инструментов для нагрузочного тестирования (давайте сразу определим область, для которой я это использую - это нагрузочное тестирование API интерфейсов). Например, есть ещё всем известный JMeter, при упоминании которого у многих лицо непроизвольно становится грустным (писать на нём тестовые сценарии и отлаживать их "ещё то удовольствие") или например FunkLoad (для любителей писать тесты на Python). Есть очень много других, но я выбрал ярких представителей своих "классов" инструментов для нагрузочного тестирования.
  Что же не так и почему не JMeter? Мне вот совсем не удобно писать на нём тесты. Если мне необходимо смоделировать небольшую нагрузку (до 500 пользователей), то я лучше воспользуюсь FunkLoad и напишу тесты на Python быстро и легко, особенно, если у тестируемого приложения уже есть готовый Python-client, что не редкость.
  Но и JMeter и FunkLoad имеют один существенный недостаток, который так сразу и не замечаешь, особенно, если тестировать производительность приходится нечасто или впервые, а глубокого анализа результатов никто и не требует.
  А вот когда моделируешь серьезные нагрузки в десятки и сотни тысяч запросов в секунду, сразу понимаешь всё. Казалось бы - запустил тот же тест, просто указал другое число параллельно работающих пользователей. В результате видишь что-то странное - график скачет, дисперсия вне всякого сомнения на столько большая, что достоверность результатов под вопросом. И начинаешь сомневаться.

Robot Framework: перезапуск "упавших" тестов

В автоматизированном тестировании есть хорошая практика делать независимые друг от друга автоматизированные тесты.  

Это означает, в частности, то, что вы можете запускать любой автоматический тест отдельно от остальных и он должен работать корректно: сообщать об ошибках, если они есть и сообщать что "все хорошо" если так и есть ) 

Вторая хорошая практика - это делать стабильные автоматизированные тесты, перезапуск которых для той же версии продукта в том же окружении должен заканчиваться с одинаковым результатом.

Этого добиться всегда сложно и иногда проще просто запускать автоматизированные тесты несколько раз для того чтобы убрать "ложно отрицательные" результаты из отчётов.

Запись видео с рабочего стола - незаменимые инструменты

Когда есть необходимость записать демо продукта или воспроизведение бага, нам требуется какой-нибудь хороший инструмент.

Требования к такому инструменту просты: пользоваться им должно быть легко, качество видео и звука должно быть хорошим (чтобы можно было различить текст на экране, движения мышкой и так далее) и при этом получаемый в результате видео файл должен быть небольшим.

Синхронизация систем ведения отчётов об ошибках

На многих проектах приходится пользоваться одновременно несколькими системами ведения отчётов об ошибках (bug tracking systems) - такими, как JIRA, launchpad, bugzilla и другие. Причина в основном одна - что-то используется "для команды", а что-то - для заказчика или community.
Часто приходится "синхронизировать" описания багов в различных системах "вручную" - это становится настоящим ночным кошмаром, ведь это работа для роботов (они могут делать её регулярно и максимально аккуратно), а у людей есть множество более интересных занятий.

Чтобы избежать дублирования багов вручную в двух системах (мы сейчас на многих проектах используем JIRA и Launchpad), я сначала поискал что-нибудь для решения этой проблемы на просторах Сети.

(пример скрипта автоматической синхронизации прилагается ;) )