Весьма рассудительная статья План тестирования на блоге “Про тестинг”.
Для тех, кто только что присоединился
Тест план (Test Plan) – это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Резюме статьи краткое:
хороший тест план должен как минимум отвечать на следующие вопросы:
- что надо тестировать (объект тестирования: система, приложение, оборудование)
- что будете тестировать (список функций и компонент тестируемой системы)
- как будете тестировать (стратегия тестирования – виды тестирования и их применение по отношению к тестируемому объекту)
- когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
- критерии начала и окончания тестирования
Это касается формализации тестирования, когда надо Cover Your Ass от возможных претензий, или кого-то по щекам стопкой бумаги похлестать. Или идёт обсуждение с участием многих людей, и все, о чем говорится, должно быть где-то как-то задокументировано.
Но бывают дни, когда тестировщик остается один на один с приложением. И возня с документами для него критична по времени. Например, никому не нужна…
На этот случай есть вариант создания тест-плана без возни с документами. Иногда можно и без тест-кейсов обойтись…
Ну так, рецепт:
- Логически разделить приложение на отдельные, независимые друг от друга модули (да, принципиально это возможно).
- В каждом модуле перечислить доступные функции.
- Для каждой функции написать списки (в виде заголовков тест-кейсов, не более) вероятных проверок для каждой функции. Без спецификаций или подробных документов.
- Проверять каждый пункт последовательно.
В этом стиле лучше всего работать с приложением типа MindMap или FreeMind, если Linux. Но в принципе все это можно сделать и в простом Notepad или Excel приложении (второе на порядок удобнее, например, можно модули по страницам разбросать, а потом автоматизировать отчет о количестве уже проверенных пунктов и о результатах проверок). Но так или иначе, главное – чтобы был список.
Со списком можно уверенно и быстро работать, неимоверно рулят принципы GTD. Видно, что можно вычеркнуть, а что важно. Видно, сколько еще софта осталось непроверенным. Многое видно, короче.
Простой тест-план, он же чек-лист, готов.
Еще раз – этот вариант подходит для ситуаций, когда времени на составление документов нет. Или когда нет необходимости в составлении околотестировочных документов.
Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.
Важное дополнение: хороший тест-план отвечает на косвенно задаваемый вопрос “Почему?”.
Спасибо, за отзыв о статье…
Ваше дополнение тоже понравилось, даже навело на мысли о написании статьи:
Test Plan vs Check List
Но это в будущем…
Что же сейчас: я согласен, что тест план надо, чтобы “Cover Your Ass”, но и не только для этого… в первую очередь – это документ. И конечно как порождение бюрократии, он всеже нужен, а начинаешь это понимать, когда на любой вопрос по проекту, можешь найти ответ в своем тест плане
Что же касается чек листов, то для небольших проектов, я сам пользуюсь именно ими. Но если капнуть глубже, то чек лист – это часть тест плана, а именно пункт: Features To Be Tested, а этот пункт – можно сказать основной…
Вот…
Еще раз спасибо…
Верно, это часть тест-плана. Просто я “словчил”, и выдал часть за целое. Как бы, мой ответ на информационную кашу, которую мне когда-то пришлось прожевать, чтобы понять разницу – что есть план тестирования, а что есть план действий.
Надеюсь, что в моем изложении это чётко видно.
Спасибо за статью. В условиях отсутствия документации (принципиального отсутствия, ее просто некому и некогда писать) очень полезная вещь. Хотя что-то в этом роде я и сама делаю, но приятно, что кто-то написал о том, что “и так тоже можно”
Может быть посоветуете, что еще можно почитать про тестирование в условиях “Вот тебе приложение, тестируй, как работает сама поймешь”? Хотелось бы более подробно.
Tlissy – спасибо.
Не видел я таких статей. Все ведь пишут о тестировании “как должно быть”, с уровня обозрения методологий и их сравнения, да из глубин базисов, с толкования основных терминов тестирования… Я сам напишу на эту тему
Возможно, наиболее близко об этом иногда пишет James Bach – в pdf есть описание культивируемого им метода Rapid Testing – все на английском, переводов не видал. Еще у него есть блог.
Следует учесть, что в тестировании этот дядька с запамятных времен, и всех методологий он навидался изрядно. И знает, что иногда тестирование в отстутствии тестовой документации называется Exploratory testing, но чаще это называется “organisational disorder”, с чем надо бороться.
То есть, метод/подход Баха – не панацея и не лоция к тихим гаваням Бермуд. Это “один из” методов – иногда где-то он “самое то”.
Я бы уточнил, что чек-лист – это как быстрое, почти условное наложение перевязки в боевых условиях. Все равно – позже надо будет дотащить товарища до медсанбата, слишком велик риск инфекций.
Метод “тестирование без документации” обычно присущ опытным инженерам, которые настолько “наелись” знаний по тому, как и что должно было бы работать, что могут проверять это без особой подготовки или предварительной подготовки тестовой документации (не обязательно подробной).
Сравнил бы это с коллективом опытных музыкантов, которые могут играть вместе какую-то мелодию практически без подготовки, по-наитию. Но все опытные музыканты знают, что может случиться, если им предварительно НЕ сыграться…
Или он присущ молодым тестировщикам, которые еще не умеют сосуществовать с программистами, не умеют кормить программистов багами и бубликами, не умеют искать и находить нужные сведения в любой документации, даже в карандашном черновике “как будет выглядеть будущая система”.
Во всех иных случаях эксплоратив и тестирование по чек-листу это, скорее, отработка служебных обязанностей, нежели результативная работа. Хотя бывает и положительный результат, но теоретизировать о практических вещах сложно и чаще – ненужно…
[...] Решение в этому случае достаточно взвешенное, хотя и местами рисковое – чек-лист. [...]
Говорю искренне человеческое спасибо за статью!
Статья и приложение к ней открывают глаза нам молодым неопытным;)
пасиб!
Спасибо, Saty
Однако рекомендую читать подобные статьи как пропаганадистские агитматериалы за подписью Геббельса, например. То есть, взвешенно и отстраненно, не принимая на веру.