Одни считают, что исследовательское тестирование более продуктивное, чем привычное нам тестирование по сценариям. Другие — что это пустая трата времени и ресурсов. Так ли это на самом деле?
Исследовательское тестирование это:
По формальности документирования выделяют три вида тестирования:
Разберемся с каждым из них чуть подробнее.
Под ad-hoc тестированием понимают тестирование без использования спецификаций, планов и разработанных тест-кейсов — здесь преимущественно чистая импровизация. В таком виде тестирования полностью отсутствует предварительная подготовка, происходит наиболее достоверная имитация случайного пользователя.
Исследовательское тестирование — более формальная версия ad-hoc: тестирование, не требует написания тест-кейсов без необходимости, но подразумевает, что каждый последующий шаг(тест) выбирается на основании результата предыдущего шага(теста). А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование является классическим тестированием по предварительно написанным и задокументированным сценариям. Оно требует наибольшей степени формальности и детализации документирования, что затрачивает гораздо больше сил тестировщика и его времени, однако наиболее подходит для ведения отчетности, статистики и т.п.
Исследовательское тестирование можно понимать как подход или саму идею, которой придерживается специалист в процессе. Исследовательское тестирование подразумевает под собой одновременное изучение проекта и его функционала, создание тест-кейсов в уме и их исполнение, не записывая и не создавая тестовую документацию без необходимости.
Такой вид тестирования может не предусматриваться в тест плане, а тест-кейсы выполняются и модифицируются динамически. Эффективность такого тестирования напрямую зависит от опыта тестировщика ранее имевшим дело с этим приложением, платформой, знанием мест скопления возможных багов и рисками которые относятся к конкретному продукту. Тестировщики могут успешно применять исследовательский подход и при разработке новых тестов в начале итерации, и при анализе уже завершенных тестов, и даже как вариант дымового тестирования, избегая лишних затрат времени.
— В запасе имеется довольно много времени после регресса
Бывает, конечно, зачастую не так часто, вы успеваете в срок и остается некоторое количество времени, и чтобы убедиться, что вы внимательно прошлись по всем тест-кейсам, что ничего не упустили, применяют исследовательское тестирование.
— Одни и те же тест-кейсы на регрессе
Количество имеющихся тест-кейсов на проекте зачастую довольно велико. Еженедельные прохождения по одним и тем же тест-кейсам приводят к тому, что глаз замыливается, и вследствие этого баги пробираются на прод. Когда же мы идем не по шагам и в голове не держим, что нам осталось еще пройти пару сотен кейсов – это помогает взглянуть на проект с несколько другой стороны.
— Небольшой стартап
Функционал нашего приложения не очень большой, поэтому можно смело использовать исследовательское тестирование. Но стоит помнить и об обратной стороне — проект расширяется, количество коллег в команде растет и документация в скором времени просто будет необходима. Даже если сроки «горят», закладывайте время на составление документации.
— Неактуальные тест-кейсы
Как было сказано выше, кейсов на проекте может быть очень большое количество и иногда, из-за горящих сроков, команда просто не успевает актуализировать тест-кейсы. Либо вы пришли на проект и там просто нет документации.
— Аутсорсинг тестирования
Клиенту важно знать, что было проверено, ему необходим отчет о тестировании. В данном случае составляются чек-листы и тест-кейсы.
— На проекте есть автоматизация
Приложение покрывается автотестами, тут тест-кейсы просто необходимы.
Многие могут подумать, что если при выборе данного подхода чаще всего отсутствует документация, то подготовки к тестированию не потребуется. Требования сами сформируются в процессе тестирования и так далее. Если мы не продумаем базовую схему выполнения проверок и вовремя не выясним возникающие вопросы, мы рискуем допустить ошибки как в оценке времени на тестирование, так и в понимании конечных целей работы нашего продукта. Применение того или иного вида тестирования зависит от конкретных целей и задач на проекте. А главным инструментом любого тестировщика являются: критическое мышление, умение анализировать и применять накопленный опыт. А если остались вопросы — скорее пишите в телеграм-канал @qa_chillout.
Исследовательское тестирование это:
Это метод ручного тестирования, который базируется на взаимодействии с приложением без детальной подготовки, основанное на знаниях и опыте тестировщика, из-за чего его квалификация может серьезно повлиять на результат.
Три вида тестирования, которые не стоит путать
По формальности документирования выделяют три вида тестирования:
- Ad-hoc тестирование,
- исследовательское тестирование,
- сценарное тестирование.
Разберемся с каждым из них чуть подробнее.
Под ad-hoc тестированием понимают тестирование без использования спецификаций, планов и разработанных тест-кейсов — здесь преимущественно чистая импровизация. В таком виде тестирования полностью отсутствует предварительная подготовка, происходит наиболее достоверная имитация случайного пользователя.
Исследовательское тестирование — более формальная версия ad-hoc: тестирование, не требует написания тест-кейсов без необходимости, но подразумевает, что каждый последующий шаг(тест) выбирается на основании результата предыдущего шага(теста). А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование является классическим тестированием по предварительно написанным и задокументированным сценариям. Оно требует наибольшей степени формальности и детализации документирования, что затрачивает гораздо больше сил тестировщика и его времени, однако наиболее подходит для ведения отчетности, статистики и т.п.
Общие сведения
Исследовательское тестирование можно понимать как подход или саму идею, которой придерживается специалист в процессе. Исследовательское тестирование подразумевает под собой одновременное изучение проекта и его функционала, создание тест-кейсов в уме и их исполнение, не записывая и не создавая тестовую документацию без необходимости.
Такой вид тестирования может не предусматриваться в тест плане, а тест-кейсы выполняются и модифицируются динамически. Эффективность такого тестирования напрямую зависит от опыта тестировщика ранее имевшим дело с этим приложением, платформой, знанием мест скопления возможных багов и рисками которые относятся к конкретному продукту. Тестировщики могут успешно применять исследовательский подход и при разработке новых тестов в начале итерации, и при анализе уже завершенных тестов, и даже как вариант дымового тестирования, избегая лишних затрат времени.
Рассмотрим преимущества и недостатки исследовательского тестирования
Преимущества исследовательского похода
- Тестировщик не ограничен в способах и инструментах тестирования, учится сам находить и предсказывать вероятные ошибки.
- Время максимально затрачивается на непосредственное тестирование.
- Тестировщик более детально и глубоко изучает продукт.
- Нет дополнительных затрат на актуализацию тест-кейсов.
Недостатки исследовательского подхода
- Тестировщику с небольшим опытом будет испытывать трудности на первых этапах работ, из-за отсутствия наглядного представление о том, что и как тестировать.
- Сложности в оценке тестового покрытия, а также в расчете временных затрат.
- Требуется большое количество времени для изучения продукта.
В каких же случаях стоит применять исследовательское тестирование?
— В запасе имеется довольно много времени после регресса
Бывает, конечно, зачастую не так часто, вы успеваете в срок и остается некоторое количество времени, и чтобы убедиться, что вы внимательно прошлись по всем тест-кейсам, что ничего не упустили, применяют исследовательское тестирование.
— Одни и те же тест-кейсы на регрессе
Количество имеющихся тест-кейсов на проекте зачастую довольно велико. Еженедельные прохождения по одним и тем же тест-кейсам приводят к тому, что глаз замыливается, и вследствие этого баги пробираются на прод. Когда же мы идем не по шагам и в голове не держим, что нам осталось еще пройти пару сотен кейсов – это помогает взглянуть на проект с несколько другой стороны.
— Небольшой стартап
Функционал нашего приложения не очень большой, поэтому можно смело использовать исследовательское тестирование. Но стоит помнить и об обратной стороне — проект расширяется, количество коллег в команде растет и документация в скором времени просто будет необходима. Даже если сроки «горят», закладывайте время на составление документации.
— Неактуальные тест-кейсы
Как было сказано выше, кейсов на проекте может быть очень большое количество и иногда, из-за горящих сроков, команда просто не успевает актуализировать тест-кейсы. Либо вы пришли на проект и там просто нет документации.
В каких же случаях не стоит применять одно только исследовательское тестирование?
— Аутсорсинг тестирования
Клиенту важно знать, что было проверено, ему необходим отчет о тестировании. В данном случае составляются чек-листы и тест-кейсы.
— На проекте есть автоматизация
Приложение покрывается автотестами, тут тест-кейсы просто необходимы.
Резюме
Многие могут подумать, что если при выборе данного подхода чаще всего отсутствует документация, то подготовки к тестированию не потребуется. Требования сами сформируются в процессе тестирования и так далее. Если мы не продумаем базовую схему выполнения проверок и вовремя не выясним возникающие вопросы, мы рискуем допустить ошибки как в оценке времени на тестирование, так и в понимании конечных целей работы нашего продукта. Применение того или иного вида тестирования зависит от конкретных целей и задач на проекте. А главным инструментом любого тестировщика являются: критическое мышление, умение анализировать и применять накопленный опыт. А если остались вопросы — скорее пишите в телеграм-канал @qa_chillout.
