Чтобы сказать, баг перед вами или нет, нужно знать, как должно быть. Это «как должно быть» описано в требованиях — задаче, пользовательской истории, макете, комментариях аналитика. Тестирование по требованиям — это проверка, что продукт делает ровно то, что в них описано, и умение эти требования читать и оспаривать.

Парадокс профессии: самые дорогие баги закладываются не в коде, а в требованиях — когда что-то поняли неправильно или не описали вовсе. Поэтому хороший тестировщик начинает работу не с продукта, а с требований, и часто ловит проблемы ещё до появления кода.

Что такое требования

Требования — это описание того, что и как должно работать. Они бывают разной формы:

  • Пользовательская история — коротко от лица пользователя: «Как покупатель, я хочу…».
  • Критерии приёмки (acceptance criteria) — конкретный список условий, при которых задача считается выполненной. Например: «при верном пароле — вход; при неверном — сообщение об ошибке; после трёх неудачных попыток — блокировка на 5 минут».
  • Макеты (дизайн) — как это выглядит на экране.
  • Описание в задаче, комментарии, устные договорённости.

Для тестировщика золото — это критерии приёмки: они почти напрямую превращаются в тест-кейсы. Каждый критерий — это как минимум одна проверка.

Хорошее требование можно проверить

Ключевое свойство требования — тестируемость: по нему можно однозначно сказать, выполнено оно или нет. Сравните:

  • Плохо: «Страница должна загружаться быстро». Что значит «быстро»? Непроверяемо.

  • Хорошо: «Страница загружается не дольше 3 секунд». Проверяемо: замерил — сравнил.

  • Плохо: «Пароль должен быть надёжным».

  • Хорошо: «Пароль — минимум 8 символов, хотя бы одна цифра и одна буква».

Если, читая требование, вы не можете придумать проверку — это сигнал, что требование плохое. И это ваш повод задать вопрос. Требование, которое нельзя проверить, нельзя и реализовать правильно — его поймут как угодно.

Задавать вопросы — часть работы

Требования почти всегда неполны. В них не описаны «неудобные» случаи, потому что автор думал про счастливый путь. Ваша сила — задавать вопросы, которые вскрывают дыры:

  • «А что, если пользователь нажмёт кнопку дважды?»
  • «А что при отмене заказа после оплаты?»
  • «А максимальная длина у этого поля есть?»
  • «А что показать, если список пустой?»
  • «А если пропадёт интернет посередине?»

Эти вопросы задают до написания кода — аналитику, менеджеру, автору задачи. Найденная на этом этапе дыра стоит десять минут разговора. Та же дыра, найденная в бою, — это инцидент. Именно поэтому тестировщика ценят не только за найденные баги, но и за хорошие вопросы.

Матрица трассируемости — ничего не забыть

Когда требований много, полезно свести их и проверки в таблицу: слева требования (или критерии приёмки), справа — какие кейсы их покрывают. Такую таблицу называют матрицей трассируемости. Она отвечает на вопрос «всё ли требуемое покрыто проверками» и сразу показывает дыры: требование есть, а кейса на него нет.

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

Где это применяется

Требования — отправная точка всей вашей работы: из них рождаются кейсы, по ним вы отличаете баг от «так задумано», по ним решаете, что вообще проверять. Тестировщик, который умеет читать требования, замечать в них дыры и вовремя задавать вопросы, экономит команде больше всего — он гасит проблемы там, где они дешевле всего, ещё до кода.

Где спотыкаются начинающие:

  • Тестируют «как понравилось», не сверяясь с требованиями, — и спорят о багах, которые на самом деле «так задумано» (или наоборот).
  • Молчат, увидев непонятное требование, вместо того чтобы задать вопрос. Непонятное требование — это будущий баг.
  • Проверяют только явно описанное и забывают про неудобные случаи, которых в требованиях нет, но которые обязательно случатся у пользователя.

Что учить дальше. Вы прошли всю программу: от «что такое тестирование» до инструментов и работы в команде. Последняя статья — куда расти дальше: какие бывают направления и как двигаться после освоения ручного тестирования.