Исследовательское тестирование широко используется в методологии разработки Agile. Оно является противоположностью сценарного тестирования и позволяет выходить за его рамки.
Сценарное тестирование можно сравнить с поездкой на поезде, который стоит на рельсах. Он никогда не отклоняется от своего пути. Исследовательское тестирование больше похоже на вождение автомобиля. В обоих случаях общая цель – добраться из пункта А в пункт Б, но всегда можно съехать с основного маршрута и выбрать любой другой, который попадется вам на глаза по дороге.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Что такое исследовательское тестирование?
Исследовательское тестирование программного обеспечения проводится в режиме спонтанности. Оно основано на опыте тестировщика и подразумевает нестандартный уровень мышления. QA инженеры разрабатывают тесты, сразу же их выполняют, анализируют результаты и используют их для разработки следующих тестов.
Важность исследовательского тестирования
Такой подход обычно занимает больше времени, чем сценарное тестирование, в дополнение к которому он идет. Поэтому часто его могут посчитать не столь важным этапом и пропустить.
Однако в процессе исследовательского тестирования выявляется больше дефектов.
Вот некоторые статистические данные, подтверждающие этот факт:
- В среднем исследовательское тестирование обнаруживает на 11% больше общих дефектов, чем сценарное.
- Исследовательское тестирование выявляет на 29% больше дефектов, которые сразу бросаются в глаза (отсутствующая кнопка в пользовательском интерфейсе).
- Когда речь заходит о “сложных” ошибках ( требующих 3 и более действий пользователя для воспроизведения ошибки или сбоя), их количество возрастает до 33%.
Исследовательское тестирование дает возможность найти больше дефектов, потому что у тестировщика появляется свобода действий, он может проводить различные типы тестов, используя свой прошлый опыт и знания о продукте. Сценарное тестирование ограничено шагами, описанными в тест-кейсах, алгоритм которых необходимо строго соблюдать.
Почему тест-кейсов недостаточно для полного покрытия
Даже если будут существовать “идеальные” тест-кейсы, исследовательское тестирование все равно обнаружит больше дефектов после релиза по нескольким причинам:
- Тестирование вокруг основного функционала позволяет выявить большее количество багов. Устранение одного дефекта часто приводит к возникновению новых в другой области.
- Если баг существует, но не обнаружен при сценарном тестировании, маловероятно, что другой тестировщик найдет его, применяя те же тест-кейсы. При этом исследовательское тестирование в той же функциональной области сможет выявить эту ошибку.
- Исследовательское тестирование более гибкое, оно позволяет мыслить нестандартно и отклоняться от сценария, прописанного в тест-кейсах. Всегда можно выполнить один тест, а затем спросить себя: “А что, если я попробую еще и эти шаги?”.
- Обнаружение дефектов, в основном тех, которые трудно найти, часто зависит от последовательности событий. Если у вас нет перечня тест-кейсов, с помощью которых можно провести действительно углубленные проверки, высока вероятность пропустить баги, которые обнаружит более длительное и менее структурированное исследовательское тестирование .
Пример исследовательского тестирования
Исследовательское тестирование позволяет быстрее найти важные дефекты, поскольку не ограничено алгоритмом конкретных действий. Оно позволяет повысить уровень покрытия и сосредоточиться на тестировании по методу “что, если”.
Например, вам поставлена задача протестировать функциональную область “Редактировать закладку”.
Есть два возможных сценария:
1. Выполнить тестовый прогон
-ИЛИ-
2. Провести исследовательское тестирование функциональной области “Редактирование закладки”.
В первом случае вы будете строго выполнять шаги, описанные в тест-кейсе, чтобы убедиться, что каждый шаг работает, и сообщать о любых найденных багах. Но что, если критическая ошибка – например, сбой или потеря данных – не произойдет во время выполнения этих шагов?
Вы ее не найдете.
Во втором сценарии вы изучаете процесс редактирования закладок. Сначала можно выполнить действия, прописанные в тест-кейсе. Однако по мере тестирования вы можете спросить себя: “Что произойдет, если я нажму “Редактировать”, удалю название и попытаюсь сохранить закладку с пустым полем?”. Пример результата – приложение аварийно завершает работу и удаляет все данные пользователя. Вы только что нашли очень важную ошибку, проверив то, что отсутствовало в перечне шагов тест-кейса.
Как структурировать исследовательское тестирование
Спонтанность такого подхода не означает, что он не структурирован. Процесс управления исследовательским тестированием должен гарантировать следующие моменты:
- Определяется четкая задача тестирования.
- Ведется тщательный учет того, что необходимо протестировать и с какой целью, оценивается качество программного обеспечения.
Тщательно фиксируются проблемы и вопросы, возникшие в ходе тестирования. - Для исполнения задачи назначаются два тестировщика с соответствующим уровнем опыта.
Это достигается посредством применения метода управления тестированием на основе сессий (SBTM Cycle):
1. Классификация ошибок.
- Классифицируйте виды дефектов, наиболее часто встречающиеся в предыдущих проектах.
- Ищите их первопричину.
- Определите риски и разработайте идеи для тестирования программного обеспечения.
2. Создайте устав тестирования.
- Определите, что именно тестировать, каким образом и какие факторы следует учесть.
- Опишите начальную точку тестирования.
- Подумайте, как будет использоваться программное обеспечение с точки зрения пользователя.
3. Создайте временную шкалу.
- Два тестировщика работают параллельно не менее 90 минут.
- В течение 90 минут прерывания не допускаются.
- Допускается продление или сокращение процесса тестирования на 45 минут.
- Тестировщики реагируют на поведение программного обеспечения и предполагают ожидаемый результат, опираясь на опыт.
4. Проанализируйте результаты.
- Оцените дефекты.
- Извлеките уроки.
- Проанализируйте зоны покрытия.
5. Подведение итогов.
- Скомпилируйте результаты.
- Сравните результаты с характеристикой.
- Проверьте, не требуется ли дополнительное тестирование.
Не пренебрегайте исследовательским тестированием
Сочетание исследовательского тестирования с обязательным сценарным тестированием позволяет поддерживать высокий уровень качества проверок и снизить риск появления дефектов в релизе.
Используйте программное обеспечение, чтобы составлять, планировать и запускать тест-кейсы. Оно позволит вашей команде упростить и ускорить тестирование.
Усовершенствуйте текущий процесс тестирования, чтобы повысить качество продукта и ускорить его выпуск.
Перевод статьи Tom Totenberg «What is Exploratory Testing? Benefits, Examples, How-To».