Исследовательское тестирование: когда его стоит применять и как это делать
Многие скептически относятся к исследовательскому тестированию, так как считают, что это пустая трата времени и ресурсов. Но на самом деле это не так. В этой статье я расскажу, когда исследовательское тестирование принесет проекту пользу. В русскоязычной литературе дается очень много различных определений для термина «исследовательское тестирование». Нередко под этим понятием подразумевается ad-hoc тестирование и наоборот. Почему так сложилось исторически можно узнать там — Исследовательское тестирование 3.0. Чтобы при чтении статьи не возникало путаницы, сверим часы и зафиксируем определения.
Что такое исследовательское тестирование
Ad-hoc тестирование
Под ad-hoc тестированием будем понимать тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импровизация.
Исследовательское тестирование
Более формальная версия ad-hoc: тестирование, не требующее написания тест-кейсов, но подразумевающее, что каждый последующий тест выбирается на основании результата предыдущего теста. А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестирования.
Сценарное тестирование
Классическое тестирование по предварительно написанным и задокументированным сценариям.
В пользу сценарного тестирования:
- сравнительная легкость планирования: тест-кейсы можно легко поделить между различными тестировщиками или командами.
- важные кейсы не останутся не пройденными;
- проще оценить процент покрытия проекта тестированием и понять, какая часть уже протестирована;
- легче ввести в проект нового человека: действия, которые от него ожидаются, уже структурированы в последовательности шагов тестовых сценариев;
- при достаточно детальном описании тестовых сценариев квалификация тестировщика может быть минимальной;
- разработанные тестовые сценарии можно передать заказчику для приемочных испытаний продукта.
В пользу исследовательского тестирования:
- без предсказуемости и жесткой привязанности к фиксированной последовательности шагов можно найти больше дефектов. В основном это будут дефекты, не относящиеся к основной функциональности;
- не нужно тратить время на предварительное доскональное описание всех сценариев;
- не нужна поддержка тестовых сценариев;
- не происходит привыкание к тестовым сценариям, и их прохождение не происходит «не глядя»;
- не теряется цельное видение продукт;
- критические дефекты находятся быстрее;
- повышается скорость тестирования;
- можно сразу начинать тестировать продукт, даже если требований нет вообще. Кроме того, что это весело, это еще и значительная экономия времени, в сравнении с отдельным изучением документации и последующем тестированием;
- интереснее и креативнее. Тесты ограничиваются только фантазией проходящего и его глубиной знаний о продукте.
Перечитайте эти пункты еще раз, но уже с мыслью о том, почему плюсы сценарного тестирования могут оказаться минусами для исследовательского и наоборот.
Когда можно применять исследовательское тестирование в чистом виде
Мало времени
Если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них.
Сложности с требованиями
Требований нет, они не полны или устарели и нет возможности их актуализировать.
Небольшой проект
Продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования.
Когда можно применять исследовательское тестирование в дополнение к обычному тестированию
Тестировщики постоянно проходят одни и те же тестовые сценарии
При многократном прохождении одних и тех же тестов, например, при регресионном тестировании, тестировщики теряют концентрацию и начинают пропускать дефекты. В этом случае исследовательское тестирование помогает взглянуть на проект под новым углом и найти пропущенные дефекты.
Тестировщик отвлекается от шаблонных действий и чувствует себя в большей степени обычным пользователем. Это помогает найти дефекты, сильнее влияющие на конечного потребителя разрабатываемого продукта.
Здесь можно воспользоваться концепцией туров. Почитать подробнее на русском — Жизнь — это движение! А тестирование — это жизнь :) Большинство туров тестировщики используют интуитивно, а остальные не приносят большой пользы, но боевой дух и желание исследовать после прочтения статьи должно появиться точно.
Пришел внезапный запрос на изменения
Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
Когда хочется перестраховаться
Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.
Когда одним исследовательским тестированием не обойтись:
Приложение стандартизованное
Приложения, работающие по стандартам и гостам, а также системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
Проводится интеграционное тестирование
В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется.
Тестовые сценарии отдаются на аутсорс
Аутсорс аутсорсу рознь, но контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.
Длительный проект
Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается.
Развенчание мифов или как применять исследовательское тестирование
Миф 1:
«Исследовательское тестирование невозможно проконтролировать, им нельзя управлять. Сложно определить, когда пора остановиться и покрыт ли весь функциональность»
Иногда исследовательское тестирование воспринимают как антоним к сценарному и относятся к нему как к тестированию в полном хаосе.
На самом деле эффекта измеримости и распараллеливания задач добиться достаточно просто. Хватает зафиксировать объем работ и разделить его на измеримые по времени части.
Миф 2:
«Нельзя доверить выполнение тестирования первому встречному»
Отчасти это действительно так. Но и сценарное тестирование не следует отдавать «случайному» человеку. На практике невозможно хорошо тестировать продукт, следуя только по заранее подготовленным шагам. Всегда возникает желание отступить от тщательно выверенных сценариев и поработать с деталями — добавить негативных проверок, проверить работу с прерываниями и так далее. И это хорошо, так как покрыть продукт тестами на 100% невозможно и никогда нельзя до конца исключить фактор человеческой ошибки.
В целом, улучшение навыков QA-команды всегда является одной из целей QA-подразделения. Используя исследовательское тестирование, инженеры задействуют интуицию и опыт, накопленные ранее и привыкают постоянно анализировать продукт.
Миф 3:
«Сложно „продать" исследовательское тестирование заказчику, объяснить его необходимость»
На самом деле для заказчика важен результат и прозрачность процессов. В данном случае результат – это продукт, удовлетворяющий представлениям заказчика о качестве. А необходимой прозрачности процессов можно достигнуть с помощью грамотных отчетов.
Если в случае сценарного тестирования упрощенным отчетом может быть список тестовых сценариев с проставленным результатом, то для отчета об исследовательском тестировании нужно выработать немного иной формат.
«Хороший» отчет об исследовательском тестировании может выглядеть следующим образом:
- список протестированных функциональностей продукта (чтобы примерно оценить тестовое покрытие, а также необходимость дополнительных исследований);
- список дефектов (найденных вообще или только самых критических – в зависимости от того, для кого и на какой стадии тестирования делается отчет. А также в зависимости от общего количества дефектов в продукте в целом);
- внутренние отчеты можно дополнить проблемами, вопросами и/или наблюдениями;
- риски. Здесь важно рассказать о том, что не было протестировано и в связи чем это произошло – функциональность не входила в cкоуп работ, не работал сервер, не было подходящих тестовых данных и так далее;
- краткий вывод по результатам тестирования (в зависимости от изначальной цели тестирования – например, можно ли передавать продукт заказчику для ознакомления).
Естественно, эти пункты не теряют актуальности и для отчетов о тестировании другими методами.
Выводы
Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, детализируя структурно составленные чек-листы, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса.
Будьте гибкими. Вырабатываете стратегию, которая наилучшим образом подойдет для вашего продукта. Качественных вам проектов.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Runscope: удобный тул для тестирования API
Back-end не всегда функционирует так идеально, как указано в API-спецификации. Например, кто-нибудь забывает внести обязательный параметр в JSON-строку выдачи или вместо «0» решает вписать null. Если такие данные проникают в мобильное приложение, последствия могут быть самые неприятные.
Сегодня я расскажу об инструменте, который используется для выявления таких случаев. Это Runscope.
Как это работает?
Runscope — сервис для автоматизированного тестирования API. С его помощью можно посылать запросы к серверу и проверять полученные ответы по заранее установленным критериям. Интерфейс Runscope интуитивно понятен, если у вас под рукой есть API-спецификации.
1. Создание запроса
Поддерживаются:
- HTTP verb. Все необходимые методы (GET, HEAD, POST, PUT, PATCH, OPTIONS, DELETE)
- Авторизация логином/паролем и OAuth
- Изменение Header'ов
- Querystring-параметры, которые сразу подставляются в URL
- Обычные параметры, которые отправляются как body
2. Установка проверок
Для проверки ответов сервера используются Assertions (англ. – утверждения). К любой части ответа можно выставить проверку на свой вкус. К примеру, мы запрашиваем баланс пользователя, и нам нужно проверить вот такой ответ:
{ "balance":150 } В данной ситуации мы можем выставить следующий Assertion:
Assertions поддерживают множество сравнений. Вот некоторые из них:
3. Использование переменных
Если вам нужно использовать одинаковые данные в нескольких запросах подряд, вы можете создать переменные.
Переменные можно создать до выполнения теста:
Или во время выполнения теста можно взять часть ответа и использовать её в качестве переменной:
Созданные переменные появляются на вкладке Request в правом верхнем углу (см п.1 Создание запроса). Для того, чтобы они появились в вашем запросе, нужно просто на них кликнуть.
4. Использование скриптов
Скрипты используются далеко не в каждом запросе, но они дают невероятную гибкость тестированию. Скрипты пишутся на JavaScript. Основной инструмент — Chai Assertion Library.
Скрипты позволяют:
1. Изменять переменные после выполнения запроса
2. Выводить любую информацию в лог
3. Использовать функции всех сторонних библиотек, которые поддерживает Runscope
Пример скрипта, который используется в реальном тестировании:
variables.get("token") достает Runscope переменную, которая была создана на вкладке Variables.
В итоге в лог выводится следующая информация:
5. Просмотр ответов
После выполнения какого-либо теста Runscope позволяет посмотреть результат каждого запроса.
Важно!
Runscope не отображает ответы с размером более 1мб. Если вы хотите посмотреть картинку с помощью Runscope, то с этим возникнут проблемы.
После создания нескольких запросов мы получаем полноценный тест, который можно запустить большой зеленой кнопкой "Run Now".
Что еще умеет Runscope?
1. Хорошо писать документацию.
2. Запускать тесты по расписанию.
3. Автоматически собирать performance-статистику всех тестов.
4. Отсылать уведомления о проведенных тестах на почту.
5. Присоединяться к стороннему сервису и пользоваться его дополнительными возможностями. К примеру, автоматически запускать тест после коммита в GitHub.
6. Запускать тесты из разных локаций. Runscope предоставляет несколько proxy-серверов, разбросанных по всему миру и проводит тесты с них.
7. Запускать тесты удаленно с помощью Trigger URL. По сути надо просто перейти по специальной URL с любого устройства, и тест начнется.
8. Сохранять результаты предыдущих тестов, если вы не хотите смотреть их прямо сейчас.
Самое главное
Ценовой политикой в Runscope определяется только количество пользователей на организацию и количество запросов в месяц. За превышение лимита запросов необходимо отдельно доплачивать (около 0.30 центов за 1000 запросов).
Но можно остаться и на бесплатном аккаунте.
Итоги
Runscope активно развивается и часто выкатывает новые фичи. Сервис предельно простой, и в этой статье описана далеко не вся его функциональность. У нас в Redmadrobot с ним работают не только QA, но также разработчики и бизнес-аналитики. Сейчас мы используем Runscope для тестирования новых и старых API, для просмотра JSON-строк в удобном формате и для сбора логов по разным аккаунтам.
Для перехвата выдачи сервера на конкретном устройстве мы используем Charles:
Charles: незаменимый тул в арсенале QA-инженера
