Раздел 04 — Чек-листы и тест-кейсы

Чек-листы и тест-кейсы ведут в таблице — LibreOffice Calc, Excel или Яндекс Таблицах. В шаблонах уже есть столбцы, выпадающие списки приоритета и итога, закреплённая шапка и фильтры. Серые строки — образец, их удаляют.

Файлы открываются в LibreOffice и Excel; в Яндекс Таблицы — загрузкой файла.

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

1. Требования — по каждому пункту хотя бы одна позитивная и одна негативная проверка.
2. Наблюдения исследовательского прохода — каждое «а что, если…» становится строкой.
3. Типовые проверки, которые нужны почти любой функции: пустые поля, слишком длинный ввод, повторное нажатие кнопки, обновление страницы, кнопка «Назад», вход другим пользователем.

Пример — функция «Отмена записи к врачу» (требование 4.2 из раздела 03 после ответов заказчика: отмена не позже чем за 2 часа, интервал освобождается, приходит СМС):

Строки 7 и 8 — типовые проверки без явного требования: в столбце «Требование» прочерк, и это сигнал задать вопрос аналитику. Приоритет показывает, что проверять первым, если времени мало.

Приоритет отвечает на вопрос «что будет, если этот дефект уйдёт к пользователям, и как часто они туда попадут».

Если высоким оказалась половина чек-листа, приоритет не работает. Ориентир: высокий — до трети проверок.

Тест-кейс расписывает одну проверку так, чтобы её прошёл человек, который не видел программу и не может спросить автора. Правила:

• Одна цель. Название говорит, что проверяется: «Отмена записи ровно за 2 часа разрешена», а не «Проверка отмены».
• Предусловия — состояние, а не действия. «Пациент вошёл, есть запись на 14:00, текущее время 12:00». Как этого добиться, если неочевидно, — отдельной строкой.
• Конкретные данные. Не «ввести длинное название», а «ввести 101 символ: aaaa… (101 раз)».
• Шаги — действия пользователя, одно действие на шаг, глаголом: «Нажать „Отменить запись“». Обычно 3–8 шагов.
• Ожидаемый результат проверяемый — точный текст сообщения, значение поля, состояние списка. «Всё работает правильно» — не результат.
• Независимость. Тест-кейс не опирается на то, что предыдущий оставил данные. Нужны данные — в предусловиях.

Тот же тест-кейс плохо и хорошо:

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

Тест-кейс пишут не на каждую строку чек-листа. Выбирают:

• проверки высокого приоритета — их будут проходить в каждом регрессе;
• проверки со сложной подготовкой данных — «текущее время 12:01» нужно уметь получить;
• то, что будут автоматизировать — автотест пишется по тест-кейсу.

Остальное остаётся строками чек-листа: «двойное нажатие — одно СМС» опытный тестировщик пройдёт и без шагов. В итоговом проекте курса минимум — 40 строк чек-листа и 15 тест-кейсов.

В столбце «Требование» у каждой проверки стоит номер. После этого на листе «Трассировка» видно, какие требования покрыты и сколькими проверками. Требование без проверок — либо пропуск, либо непроверяемое требование, на которое задан вопрос. В «Задачнике» это значит: по каждому из Т1–Т9 должна быть хотя бы одна проверка или запись, почему её нет.

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

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

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

Замечания пишут в столбец «Комментарий» или комментарием к ячейке, а автор исправляет. Это статическое тестирование самой тестовой документации — дешёвое и полезное.