Проверять программное обеспечение можно совершенно по-разному, и у каждого QA-инженера с течением времени вырабатывается свой персональный стиль и «почерк» в работе.

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

Далее в статье речь как раз пойдет об основах исследовательского тестирования, а также его характерных особенностях и набора отличий от скриптового.

Итак, что же такое исследовательское тестирование?

[highlight dark=”no”]Это особый тип тестирования ПО, при котором пользователь одновременно и проверяет, и придумывает новую проверку, опираясь на текущее поведение программы.[/highlight]

Зачем вообще тестировать ПО подобным образом?

Причин может быть сразу несколько:

1. У QA-отдела пока нет набора готовых проверок;
2. Итог нужен «побыстрее»;
3. Тестировщик хочет перестраховаться — проверить ПО как новыми, так и уже готовыми тестами.

Полная противоположность исследовательскому тестированию — скриптовые проверки, где всё выполняется по готовому шаблону.

Тестовые действия таким способом изначально предписаны и предсказуемые, и расхождение с первоначальным тестовым сценарием исключено!

Исследовательское тестирование против скриптового тестирования

Базовые характеристики исследовательского тестирования

• Выполнение параллельного планирования, создание процессов и выполнение разработанных задач;
• Гибкость в подходе тестирования ПО — проверка без конкретно определенного скрипта;
• Возможность оперирования при отклонении от скрипта в любом направлении;
• Повышенная скорость компаний по тестированию для старта тестирования (старт тестов сразу после получения задачи — нет надобности создавать план).

Техники правильного исследовательского тестирования

Несмотря на то, что исследовательское тестирование — более «креативная работа» чем тестирование по сценариям, необходимо придерживаться определенных правил и техник, дабы не упустить мало-мальски существенный баг.

1. Принцип декомпозиции: одно большое ПО — это совокупность массы маленьких частиц. Разбивка чего-то большого на маленькие, простые в понимании части поможет пользователю, даже если он будет делать это простым карандашом на листке бумаги. Отдельно разработанные блоки проверять гораздо легче, чем весь продукт сразу;
2. Наборы тест-туров Джеймса Виттакера, которые акцентируют внимание на том, что, если вы ищите что-то определенное, вы обязательно это найдете. Фокус при этом — поиск одного вида багов;
3. Чит-листы — оригинальные списки проверок;
4. Мнемоники. Это своего рода способы запоминания.