Раздел 11 — Тестовый процесс

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

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

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

Пункт 3 «Что не тестируем» важнее, чем кажется: он заранее договаривается о рисках. Если оплата сломается, а в плане написано «оплату проверяем только smoke, потому что она не менялась», — это решение команды, а не промах тестировщика.

Тест-план согласуют до начала прогона: показывают руководителю или разработчикам и правят по замечаниям. Меняется объём работы — меняется и план.

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

1. Разбить работу на этапы из таблицы раздела 01.
2. Для каждого этапа — число единиц (требований, тест-кейсов, ожидаемых дефектов) и время на одну единицу. Время берут из своего опыта: засеките, сколько у вас уходит на один тест-кейс, и используйте это число.
3. Сложить и добавить запас 20–30% на непредвиденное: стенд упал, дефект не воспроизводится, требования уточняются.

23 часа — примерно три рабочих дня одного тестировщика: в дне не 8 часов проверок, остальное съедают встречи и переписка. Оценку называют вместе с условиями: «три дня, если сборка будет на стенде в понедельник утром». Когда срок жёстче оценки, сокращают объём — и это решение записывают в пункт 3 тест-плана.

Критерии входа — условия, без которых прогон начинать бессмысленно. Если smoke не прошёл (не открывается страница входа), три дня по плану уйдут на ожидание исправлений. Версию возвращают разработчикам с одним баг-репортом, а не начинают прогон.

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

Есть и критерий остановки по времени: срок вышел, а критерии выхода не выполнены. Тогда тестирование не продлевают молча — пишут отчёт с тем, что успели, и решение о выпуске принимает руководитель.

Прогон — выполнение набора проверок на конкретной версии в конкретном окружении. Для прогона копируют таблицу тест-кейсов или чек-лист и заполняют столбец «Статус» (в шаблонах курса — выпадающий список):

Правила, которые экономят время при отчёте:

• Один прогон — одна версия и одно окружение. Прогон на 2.4 в Chrome и на 2.4 в Firefox — две таблицы или два столбца статуса.
• Статус ставится сразу после проверки, а не вечером по памяти.
• «Не прошла» без номера баг-репорта не бывает. Один дефект может уронить несколько проверок — у всех тот же номер.
• В шапке прогона — версия, дата, окружение, кто проводил.

Итог прогона — несколько чисел. Пример: из 24 тест-кейсов прошли 17, не прошли 4, заблокированы 2, не проверялся 1. Выполнено 21, из них прошли 17 — 81%. Число без контекста мало что говорит: 4 не прошедших тест-кейса могут быть опечатками, а могут — невозможностью записаться к врачу. Поэтому в отчёте рядом с числами — список открытых дефектов по серьёзности.

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

С новой версией приходит список изменений (release notes): что исправлено и что добавлено. По нему составляют два набора проверок (понятия — из раздела 02):

• Повторная проверка — каждый дефект из списка «исправлено» проверяют по шагам его баг-репорта. Исправлен — в трекере комментарий «Проверено на 2.4 — исправлено» и статус «Завершена». Не исправлен или исправлен частично — комментарий с тем, что видно сейчас, и задача возвращается разработчику. Новый баг-репорт на тот же дефект не заводят.
• Регресс — проверки того, что раньше работало. Исправление в одном месте ломает соседнее: общий код, общие данные, общий экран. Регрессия — дефект, которого в прошлой версии не было; в заголовке баг-репорта её отмечают: «Регрессия 2.4: …».

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

К набору по анализу влияния добавляют постоянную часть: smoke и тест-кейсы высокого приоритета. Они ловят регрессии там, куда список изменений не указывает: разработчик мог поменять общий код и не упомянуть это, потому что «ничего не должно было измениться».

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

Рекомендация — работа тестировщика, решение о выпуске — работа руководителя. Отчёт даёт ему факты для решения: что сломано, чем это грозит пользователям, что не проверено.

Руководителю, который не будет открывать трекер, пишут короче и без техники — через последствия для пользователей и бизнеса:

Тема: Запись к врачу 2.4 — готова к выпуску после одного исправления

Проверили версию 2.4 за три дня. Новый срок отмены и календарь работают.
Мешает выпуску одна ошибка: с телефона нельзя отменить запись — пациенты
будут звонить в регистратуру. Разработчики оценили исправление в полдня,
повторная проверка — час. Не проверены SMS-уведомления: на тестовом стенде
они не отправляются, проверим в первый день после выпуска.
Подробный отчёт — во вложении.

Таблицы курса — рабочий инструмент для одного тестировщика и одного проекта. Когда тестировщиков несколько, прогонов много и нужна их история, переходят на систему управления тестированием (TMS, test management system):

• тест-кейсы в общей базе с версиями: видно, кто и когда поменял шаг;
• прогон собирается из тест-кейсов несколькими щелчками, статусы ставятся по ходу, отчёт строится сам;
• связь с баг-трекером: из «не прошла» сразу создаётся задача;
• результаты автотестов попадают в тот же отчёт, что и ручные проверки (курс «QA: автоматизация тестирования»).

Для зарубежных облачных сервисов проверяйте, доступны ли регистрация и оплата из России и можно ли хранить там данные проекта. Поля в любой TMS те же, что в шаблонах курса: предусловия, шаги, ожидаемый результат, приоритет, статус прогона. Тот, кто умеет вести прогон в таблице, освоит любую из них за день.