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

Пытается программист уточнить, зачем эта труба клиенту нужна. Умудренный знает, что клиенту этой информацией делиться нафиг не нужно. Что ему труба нужна. Или пирожок 🙂 Но пытается.

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

«How to test software with dynamic requirements?» — достаточно вменяемая статья на тему нестандартных труб, исходя из всей доступной «широты» этого вопроса.

Решение в этому случае достаточно взвешенное, хотя и местами рисковое — чек-лист.

Кто незамутненно уверен в том, что чек-лист — стопроцентная панацея в работе тестировщика, тот дурак. Зависит от проекта и уровня образования тестировщика. Например, без понимания софта тестировать в таком режиме почти невозможно. А вот по тест-кейсам может тестировать любой товарищ, даже не понимающий, что именно оне изволят-с тестировать и зачем. Доказательство.

Или MindMap.

Вот пример карты в MindMap (required Flash). В примере я показал часть того, что должно было быть сделано программистом в отношении гипотетической задачи «ER-678».

Это все было расписано не в требованиях, а размазано в комментариях к задаче. Занести все это в MindMap и как следует раскидать по логикам вещей — 7 минут. Проще, чем просить письмо с однозначными требованиями и громко предпочитать работать в гетеросексуальном коллективе.

Сколько времени занимает само тестирование — уже не так важно, it’s depends… Важно то, что если какое-то требование будет изменено через час, его изменение займет в этой карте минимальное время, и все равно будет понятно, что и как надо делать. А если будет добавлено что-то новое, то и в карту его добавить несложно.

Интереснее всего то, что будет видно потом. Видно, что в пункте «all the other checkboxes should be unchecked and greyed out» возникли какие-то проблемы… И в комментарии указано, что по этому поводу открыт новый баг в баг-трекере.

MindMap позволяет очень и очень грамотно и гибко сортировать топики по разным признакам — пользуемся Queries.

Для тех, кто только что присоединился

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

Резюме статьи краткое:

хороший тест план должен как минимум отвечать на следующие вопросы:

1. что надо тестировать (объект тестирования: система, приложение, оборудование)
2. что будете тестировать (список функций и компонент тестируемой системы)
3. как будете тестировать (стратегия тестирования — виды тестирования и их применение по отношению к тестируемому объекту)
4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
5. критерии начала и окончания тестирования

Это касается формализации тестирования, когда надо Cover Your Ass от возможных претензий, или кого-то по щекам стопкой бумаги похлестать. Или идёт обсуждение с участием многих людей, и все, о чем говорится, должно быть где-то как-то задокументировано.

Но бывают дни, когда тестировщик остается один на один с приложением. И возня с документами для него критична по времени. Например, никому не нужна…

На этот случай есть вариант создания тест-плана без возни с документами. Иногда можно и без тест-кейсов обойтись…

Ну так, рецепт:

1. Логически разделить приложение на отдельные, независимые друг от друга модули (да, принципиально это возможно).
2. В каждом модуле перечислить доступные функции.
3. Для каждой функции написать списки (в виде заголовков тест-кейсов, не более) вероятных проверок для каждой функции. Без спецификаций или подробных документов.
4. Проверять каждый пункт последовательно.

В этом стиле лучше всего работать с приложением типа MindMap или FreeMind, если Linux. Но в принципе все это можно сделать и в простом Notepad или Excel приложении (второе на порядок удобнее, например, можно модули по страницам разбросать, а потом автоматизировать отчет о количестве уже проверенных пунктов и о результатах проверок). Но так или иначе, главное — чтобы был список.

Со списком можно уверенно и быстро работать, неимоверно рулят принципы GTD. Видно, что можно вычеркнуть, а что важно. Видно, сколько еще софта осталось непроверенным. Многое видно, короче.

Простой тест-план, он же чек-лист, готов.

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

Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.

Важное дополнение: хороший тест-план отвечает на косвенно задаваемый вопрос «Почему?».

Пример: https://ru.scribd.com/document/39391857/TestPlanTemplateV1-0