Что такое тест-план? Страница, на которой написано, что вы не тестируете

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

Перечислить, что вы собираетесь проверить, может кто угодно. Записать, что вы намеренно оставляете в стороне, - это та часть, которая избавляет от разговора три недели спустя, где кто-то считал, что нечто покрыто, потому что никто не сказал, что это не так.

Что в нём должно быть

Шесть разделов несут почти всю ценность, и каждый из них может уместиться в несколько строк.

• Область. Что покрывает этот круг тестирования: какие функции, какие релизы, какие платформы.
• Вне области. Что он намеренно не покрывает и почему. Самый полезный раздел и тот, которого чаще всего нет.
• Подход. Вручную, автоматизированно или в каком-то соотношении между ними, и на каком уровне.
• Окружения и данные. Где всё выполняется и на чём, потому что именно это решает, что вообще можно найти. План, в котором написано “staging” без указания сборки и данных, говорит немного.
• Критерии входа и выхода. Что должно быть верно до начала тестирования и что должно быть верно до того, как его назовут законченным.
• Риски. Что может помешать этому плану сработать, названное, пока это ничего не стоит.

Некоторые планы добавляют роли, график и процесс работы с дефектами. Это тем важнее, чем больше людей вовлечено, и почти не имеет значения, когда вас двое.

Споры возникают вокруг критериев выхода

“Готово” - вещь неочевидная, и план, который её не определяет, порождает релиз, о котором спорят в день выпуска вместо того, чтобы договориться заранее.

Слабо

Все крупные ошибки исправлены, тестирование завершено

Лучше

Каждый случай в наборе для оформления заказа проходит, нет открытых дефектов серьёзности 1 или 2, а три известных дефекта серьёзности 3 записаны вместе с обходными путями в примечаниях к релизу

Второе может проверить тот, кого не было в комнате. Первое - это настроение.

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

Какой длины он должен быть

Короче, чем кажется, и пропорционально числу людей, которым нужно договориться.

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

Проверка, которую стоит применить: изменилось бы чьё-нибудь поведение, если бы этого раздела не было? Если нет, удалите его. План, который никто не читает, хуже, чем его отсутствие, потому что создаёт уверенность, будто тестирование было спланировано.

Где он стоит среди остальных документов

План находится на уровень выше самих проверок.

• План говорит, что оформление заказа будет протестировано вручную в Chrome и Safari, а мобильные устройства в этом круге вне области.
• Тест-кейсы говорят в точности, что делать и что должно произойти.
• Регрессионный набор говорит, что перепроверяется, потому что раньше это работало.
• Критерии приёмки говорят, что функция вообще должна была делать, и они были написаны раньше всего остального.

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

Процесс работы с дефектами - его часть

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

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

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

Коротко

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