Какие техники тестирования вы знаете?
Что проверяют
Понимает ли аналитик, как из его требований получаются проверки, и умеет ли писать требования, которые вообще можно проверить. Следом часто просят составить критерии приёмки к конкретной пользовательской истории.
Как отвечать
Для аналитика вопрос не про ручное и автоматическое тестирование, а про тест-дизайн на основе требований и про приёмку. Каркас такой:
- статическое тестирование требований: ревью и walkthrough спецификации до разработки. Ищете неоднозначность («быстро», «удобно»), противоречия, пропущенные альтернативные сценарии и ошибки;
- классы эквивалентности и граничные значения: сразу закладывайте в требование диапазоны и включённость границ, тогда тестировщику не придётся угадывать;
- таблица решений: когда бизнес-правило зависит от нескольких условий, таблица в спецификации одновременно фиксирует логику и даёт готовый набор тестов;
- переходы состояний: диаграмма состояний сущности (заявка, договор, платёж) это готовая модель для тестов, включая запрещённые переходы;
- тестирование по сценариям использования: основной и альтернативные потоки use case или BPMN-процесса превращаются в сквозные сценарии;
- приёмочное тестирование (UAT): вместе с заказчиком проверяете, что система решает его задачу. Критерии приёмки удобно писать в формате Given/When/Then.
Добавьте пример из практики: какое требование переписали после ревью или какой дефект нашли ещё на этапе спецификации. Если сами тесты не писали, честно скажите, что участвовали через критерии приёмки и разбор дефектов.
Где спотыкаются
Путают виды тестирования и техники тест-дизайна: перечисляют нагрузочное и интеграционное, не назвав ни одного способа получить проверки из требования.
Говорят, что тестирование это зона QA. Дефект, найденный в спецификации, стоит дешевле всего, и аналитик здесь первый, кто может его поймать.
Пишут критерии приёмки, которые нельзя проверить: «система работает корректно» вместо конкретного условия и ожидаемого результата.