Раздел 03 — Требования и тестовая документация

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

Требования бывают в техническом задании (ТЗ, по ГОСТ 34 или в свободной форме), в пользовательских историях («Как пациент, я хочу…, чтобы…»), в макетах интерфейса, в документации API, в переписке с заказчиком. Если требований нет вовсе, ожидаемый результат берут из здравого смысла, похожих программ, законов и стандартов — и записывают как предположение, которое нужно подтвердить.

Свойств в литературе называют до десятка. Для проверки хватает четырёх главных — по ним в практике этого раздела и записываются дефекты.

Ещё полезно, чтобы требование было атомарным (одно требование — одно условие, тогда на него проще сослаться) и выполнимым («сайт работает без сбоев всегда» выполнить нельзя).

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

• Как я это проверю? Какой будет ожидаемый результат — число, текст, состояние?
• Что будет на границе: ровно 2 часа до приёма, ровно 7 дней, пустое поле?
• Что будет при ошибке: нет связи, занятый интервал, неверный ввод?
• Не говорит ли другой пункт иное о том же самом?
• Кто может это делать — любой пользователь, только владелец, администратор?
• Что происходит с данными до и после: создаются, меняются, удаляются, остаются?

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

Хороший вопрос экономит время обеим сторонам: на него можно ответить одной фразой, и этот ответ потом проверяется. Сравните:

Вопросы задают письменно, пачкой, с номерами требований. Ответы вносят в требования, а не оставляют в переписке: через месяц переписку никто не найдёт, а тест-кейсы будут ссылаться на пункт требований.

Критерии приёмки — условия, при которых функция считается сделанной. В гибких командах их пишут к каждой пользовательской истории до начала разработки, и тестировщик участвует в этом: он лучше других видит пропущенные случаи. Удобная форма — «Дано — Когда — Тогда» (в англоязычных источниках Given — When — Then):

История: как пациент, я хочу отменить запись, чтобы освободить время для других.

Критерий 1. Отмена заранее
  Дано: у пациента запись к терапевту на завтра 10:00
  Когда: он нажимает «Отменить запись» и подтверждает
  Тогда: запись пропадает из «Мои записи», интервал 10:00 снова свободен,
         пациенту приходит СМС «Запись на 10:00 отменена»

Критерий 2. Слишком поздно
  Дано: до приёма осталось 1 ч 59 мин
  Когда: пациент открывает запись
  Тогда: кнопки «Отменить запись» нет, показан телефон регистратуры

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

Документы тестировщика отвечают на разные вопросы и пишутся в разное время.

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

Поля тест-кейса:

Как писать тест-кейсы так, чтобы их можно было пройти без автора, — в разделе 04.

Трассировка — связь «требование → проверки → дефекты». Её ведут таблицей (матрицей трассировки):

По ней видно, какие требования не покрыты (6.1 — потому что непроверяемое, вопрос задан), и что придётся перепроверить, если требование изменится. В небольшом проекте достаточно столбца «Требование» в таблице тест-кейсов.