Размышления о миссии QA инженера

  Недавно мы сидели с коллегами вечером в каком-то ресторанчике в Париже и обсуждали миссию DevOps и QA инженеров на проектах.

  "QA должен так описать багу, чтобы, прочитав это описание, разработчик не только сразу понял в чем проблема, но и захотел это тут же исправить" (С) Я.

  Чтобы так описывать баги, QA инженер должен отлично понимать как работает проект, чтобы разработчик проникся описанной проблемой, а не тратил время и силы на "перевод" с языка QA на язык разработчика и многочасовые попытки воспроизвести описанную проблему.

  Миссия QA инженера на проекте - это обеспечить создание качественного программного обеспечения, всеми средствами. Сюда относится и наличие правильного CI/CD, и создание особой культуры разработки (как, например, "не релизим в пятницу вечером" или "изменения в коде должны пройти ревью как минимум двух инженеров кроме самого автора кода") и многое другое, но вот о чем многие из нас частенько забывают - QA должен понимать как работает проект и каждый его компонент изнутри и как это выглядит для обычного пользователя снаружи. Эти знания нужны нам, чтобы создавать адекватные тесты и понимать результаты проводимого тестирования, эти знания нужны нам чтобы с легкостью общаться с командой разработчиков, менеджерами и командой поддержки.

Баги-рекодсмены

Есть такие особенные баги, которые выделяются среди других. Либо по времени жизни в продуктах, либо по масштабам распространения и ущерба, наносимого этим багом.

Вот, например, недавно обнаружили баг в библиотеке OpenSSL: 

http://mashable.com/2014/04/09/heartbleed-bug-websites-affected

2/3 всех веб сервисов в Интернете подверглись риску открыть всю зашифрованную информацию - используя этот баг злоумышленник может (хоть и не сказать, что это легко) узнать закрытую часть RSA ключей или пароли пользователей. В общем расшифровать почти любую зашифрованную информацию, которую мы передавали по сети.

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

Но больше интересно как такие баги появляются и как попадают в "продакшн", как становятся частью сервисов, которыми пользуются люди и как и почему их находят и исправляют.

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

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

Есть множество онлайн-сервисов для кроссбраузерного тестирования веб приложений. Если выбирать из бесплатных, то мне больше всего нравится сервис 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 имеют один существенный недостаток, который так сразу и не замечаешь, особенно, если тестировать производительность приходится нечасто или впервые, а глубокого анализа результатов никто и не требует.
  А вот когда моделируешь серьезные нагрузки в десятки и сотни тысяч запросов в секунду, сразу понимаешь всё. Казалось бы - запустил тот же тест, просто указал другое число параллельно работающих пользователей. В результате видишь что-то странное - график скачет, дисперсия вне всякого сомнения на столько большая, что достоверность результатов под вопросом. И начинаешь сомневаться.