Весьма рассудительная статья План тестирования на блоге «Про тестинг».
Для тех, кто только что присоединился
Тест план (Test Plan) — это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Резюме статьи краткое:
хороший тест план должен как минимум отвечать на следующие вопросы:
- что надо тестировать (объект тестирования: система, приложение, оборудование)
- что будете тестировать (список функций и компонент тестируемой системы)
- как будете тестировать (стратегия тестирования — виды тестирования и их применение по отношению к тестируемому объекту)
- когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
- критерии начала и окончания тестирования
Это касается формализации тестирования, когда надо Cover Your Ass от возможных претензий, или кого-то по щекам стопкой бумаги похлестать. Или идёт обсуждение с участием многих людей, и все, о чем говорится, должно быть где-то как-то задокументировано.
Но бывают дни, когда тестировщик остается один на один с приложением. И возня с документами для него критична по времени. Например, никому не нужна…
На этот случай есть вариант создания тест-плана без возни с документами. Иногда можно и без тест-кейсов обойтись…
Ну так, рецепт:
- Логически разделить приложение на отдельные, независимые друг от друга модули (да, принципиально это возможно).
- В каждом модуле перечислить доступные функции.
- Для каждой функции написать списки (в виде заголовков тест-кейсов, не более) вероятных проверок для каждой функции. Без спецификаций или подробных документов.
- Проверять каждый пункт последовательно.
В этом стиле лучше всего работать с приложением типа MindMap или FreeMind, если Linux. Но в принципе все это можно сделать и в простом Notepad или Excel приложении (второе на порядок удобнее, например, можно модули по страницам разбросать, а потом автоматизировать отчет о количестве уже проверенных пунктов и о результатах проверок). Но так или иначе, главное — чтобы был список.
Со списком можно уверенно и быстро работать, неимоверно рулят принципы GTD. Видно, что можно вычеркнуть, а что важно. Видно, сколько еще софта осталось непроверенным. Многое видно, короче.
Простой тест-план, он же чек-лист, готов.
Еще раз — этот вариант подходит для ситуаций, когда времени на составление документов нет. Или когда нет необходимости в составлении околотестировочных документов.
Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.
Важное дополнение: хороший тест-план отвечает на косвенно задаваемый вопрос «Почему?».
Пример: https://ru.scribd.com/document/39391857/TestPlanTemplateV1-0
есть еще хорошая статья про планирование тестовых активностей http://www.a1qa.ru/blog/obespechivaem-kachestvo-mobilnyh-prilozhenij-shag-2-planirovanie-testovyh-aktivnostej/
кратко и по сути изложены основные моменты, можно использовать как шпаргалку 🙂
НравитсяНравится
сори! но я так и не увидел наглядной разницы с примерами. описание тест-плана есть а вот чек листа не наблюдаю!
НравитсяНравится
Вы правы.
Тогда я еще не был способен внятно всё сформулировать.
Сейчас могу, но не буду переписывать. К тому же, у меня тут был расширенный и достаточно исчерпывающий комментарий на эту тему.
НравитсяНравится
Большое спасибо за статью и дополняющие комментарии!
У меня на носу сдача базиса и все выше указанное очень помогло! 🙂
НравитсяНравится
«Или если вам скучно, а заняться на производстве нечем – вам нужно написать документик.» 😀
Спосибо большое! 🙂
НравитсяНравится
Ну, вот вам четкое определение: упорядоченный список всех дел, логических и физических сущностей, материалов, терминов, целей, понятий которые надо сделать, чтобы протестировать что-то, называется тест-планом.
Это рукописный документ, который нужно сочинять самостоятельно (это первая трудность при работе с подобной документацией).
Зачастую используется в компаниях и ситуациях, когда необходимо очень точно и четко договориться о целях тестирования, о физической или логической наличии возможностей для проведения тестирования…
Блин.
Получается заумно.
В общем, если у вас есть въедливый закащщик, который может взгреть вас за любой промах, или может переложить на вас ответственность за какие-то проблемы, вам нужно написать документик.
Или если у вас разрозненная команда, и нужно составить доступный для обеих сторон перечень целей тестирования, серверов, логинов, и прочих важных вещей, чтобы в итоге все стороны говорили об одном и том же на одном и том же языке — вам нужно написать документик.
Или если вам платят за часы работы по определенному плану, а не «в принципе» и «как получится» — вам нужно написать документик.
Или если вам скучно, а заняться на производстве нечем — вам нужно написать документик.
В нём будет несколько разделов с подробными (ключевое слово — подробными) ответами на ряд вопросов.
Вопросы простые, но ответы бывают очень неоднозначными.
Например:
— что будем тестировать,
— нафига нам это надо тестировать,
— кто именно это будет тестировать, сколько нужно народу,
— где именно мы это будем тестировать (сервера, компьютеры, конфигурация компьютеров, софта, погодных условий и тыды),
— до каких пор мы это будем тестировать,
— в какой последовательности мы это будем тестировать,
— какие области наиболее приоритетны,
— как именно мы это будем тестировать (сюда обычно попадают тест-кейсы),
— на протяжении какого периода суток,
— и тыды, если эта информация кому-то нужна и важна.
В разных школах разработки существуют примерные заготовки тест-планов. Типа как тут http://www.carnegiequality.com/testing/test-plan-template/
Предполагается, что умный человек-тестировщик эту заготовку прочитает, оставит там только то, что ему нужно, вычеркнет то, что не нужно, и план готов. Большинство людей ломаются уже на этом этапе — как, неужели это еще надо самостоятельно писать-то?
Предполагается, что в процессе работы над тест-планом все темные места прояснятся, все детали будут продуманы и все нужные средства будут собраны, чтобы все прошло без проблем.
А потом, мол, этот документ будет нам и ориентиром качества проделанной работы, и отчетом.
Итого: тест-планом является подробный перечень всего того, что нужно для проведения тестирования чего-то.
Указаны цели, задачи, требуемые ресурсы, технические подробности, ответственные лица, и прочее подобное. Приведена вся необходимая информация, ознакомившись с которой любой читатель документа узнает и поймет всё, что ему хотелось узнать и понять.
Еще раз отмечу — туда надо записывать то, что важно, а не всё подряд, «лишь бы было».
После написания тест-план надо согласовать со всеми участниками разработки, которым это тестирование и было нужно. Тяжелый этап 🙂
После согласования и внесения коррективов, можно приступать к работе по этому плану.
Отклонения надо подправлять, изменения отражать, итог всей работы делать максимально предсказуемым.
В общем, тест-план — это план действий с техническими подробностями.
Важно понимать, что информации в этом плане может быть очень до хрена. Человек должен решать, что именно в этом плане должно содержаться, ответы на какие вопросы там должны быть, а на какие совершенно не нужны, бо это никому не нужно.
Очень такие документы помогают в борьбе с уродами, которые говорят «А мы думали, что вы будете тестировать и под таким-то нестандартным браузером и нестандартным расширением — это же само по себе подразумевается…» Ни фига не самоподразумевается, и план помогает подобные пункты отдельно и особо обговорить. Мир во всем мире и свобода слова подразумеваются, а в тестировании все должно быть четким и ясным. Планировали тестировать с расширением 800×600 = получите и распишитесь.
Четкость и ясность приносят только подробные указания, которые обсуждаются заинтересованными сторонами.
Тест-план — инструмент, который помогает достичь ясности и всеобщего согласия.
Но!
Есть ситуации, когда объемный и красивый тест-план нафиг не нужен. И даже — вреден.
Есть компании, в которых тестировать можно без предварительного расписывания адресов серверов, логинов, тест-кейсов и тыды. Бывает, что тестировщиков всего двое на десять программистов, и все мелочи уже всем известны, и все задачи уже обсуждены, и написание тест-плана вызовет только хихиканье и вопросы «Нафига это было нужно? Что, ходил на курсы по написанию тест-планов? Книг начитался?»
Вообще, самой важной частью документации тестировщиков является перечень проверок, которым тестировщики могут подвергнуть тестируемое приложение.
Иногда это выглядит как список тест-кейсов.
Иногда это список функционала — ну, просто список.
Иногда это расширенный, подробный список — функционал отсортирован по значимости, например, и для каждого пункта отдельно прописаны его проверки.
Простой список того, что нужно не забыть протестировать — это чек-лист.
Чек-листы бывают разными-разными 🙂 Смотрим сюдой — http://nrukol.blogspot.com/2010/11/blog-post_08.html — там указан файлик, который нужно скачать и прочитать.
В файлике указаны, собственно, этапы детализации чек-листа. Можно сделать его простым, и этого достаточно. Можно детализировать, указав не только ЧТО надо протестировать, но и КАК это надо тестировать.
Сила тест-кейса в том, что в нем все расписано очень-очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но когда все это подробное добро приходится обновлять или изменять — становится кисло.
Сила чек-листа в том, что он простой. Там нет детализации, это просто памятка. Но тестировать приложение по чек-листу сразу, без подготовки, не понимая, что подразумевается под «Зачарджить ордер на бэкофисе» (это где? это как? это что? это откуда и куда?) — невозможно. И степень детализации низка. Глядим, к примеру, на пункт «Проверить чекаут» — там отмечено ‘Pass’. Ок, а как мне убедиться в том, что чекаут был проверен подробно? Тестировщик, который это проверял, действительно добавил товар в корзину всеми шестью способами, которыми это можно сделать на нашем сайте? Без деталей ИНОГДА кирдык как сложно. А иногда детали как раз и не требуются.
Дык вот.
Иногда тест-план — это просто очень детализированный чек-лист. Понятно, почему?
А иногда планировать тестирование можно только на основе чек-листа — он же может служить отчетом о работе. Понятно, почему?
Следовательно, моя подмена понятий может быть правомочной — в какой-то степени.
Вообще обойтись без тест-плана невозможно — он есть всегда, в любом виде, даже если ничего не расписано детально, и все хранится только в голове тестировщика.
Но иногда вполне можно обойтись без детализированного тест-плана, который подразумевается под «крутой документ, с кучей таблиц, графиков, списков и прочей лабуды«.
Надеюсь, не запутал.
НравитсяНравится
К теме.
«The Value of Checklists and the Danger of Scripts: What Legal Training Suggests for Testers.» Cem Kaner
Ссылка: http://www.kaner.com/pdfs/ValueOfChecklists.pdf
Вроде бы, на software-testing.ru выложили или собираются выложить статью в переводе.
НравитсяНравится
«Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.»
Могли бы ли Вы (очень Вас прошу) дать чуть более развернутый ответ чем же по сути отличается тест-план от чеклиста и чем чек-лист отличается от тест-кейса?
Зараннее спасибо!
Я хочу сказать что существует понятие чеклиста, но оно очень размытое и я до сих пор не нашел ни одного четкого определения.
НравитсяНравится
Спасибо, Saty
Однако рекомендую читать подобные статьи как пропаганадистские агитматериалы за подписью Геббельса, например. То есть, взвешенно и отстраненно, не принимая на веру.
НравитсяНравится
Говорю искренне человеческое спасибо за статью!
Статья и приложение к ней открывают глаза нам молодым неопытным;)
пасиб!
НравитсяНравится
[…] Решение в этому случае достаточно взвешенное, хотя и местами рисковое — чек-лист. […]
НравитсяНравится
Tlissy — спасибо.
Не видел я таких статей. Все ведь пишут о тестировании «как должно быть», с уровня обозрения методологий и их сравнения, да из глубин базисов, с толкования основных терминов тестирования… Я сам напишу на эту тему 🙂
Возможно, наиболее близко об этом иногда пишет James Bach — в pdf есть описание культивируемого им метода Rapid Testing — все на английском, переводов не видал. Еще у него есть блог.
Следует учесть, что в тестировании этот дядька с запамятных времен, и всех методологий он навидался изрядно. И знает, что иногда тестирование в отстутствии тестовой документации называется Exploratory testing, но чаще это называется «organisational disorder», с чем надо бороться.
То есть, метод/подход Баха — не панацея и не лоция к тихим гаваням Бермуд. Это «один из» методов — иногда где-то он «самое то».
Я бы уточнил, что чек-лист — это как быстрое, почти условное наложение перевязки в боевых условиях. Все равно — позже надо будет дотащить товарища до медсанбата, слишком велик риск инфекций.
Метод «тестирование без документации» обычно присущ опытным инженерам, которые настолько «наелись» знаний по тому, как и что должно было бы работать, что могут проверять это без особой подготовки или предварительной подготовки тестовой документации (не обязательно подробной).
Сравнил бы это с коллективом опытных музыкантов, которые могут играть вместе какую-то мелодию практически без подготовки, по-наитию. Но все опытные музыканты знают, что может случиться, если им предварительно НЕ сыграться…
Или он присущ молодым тестировщикам, которые еще не умеют сосуществовать с программистами, не умеют кормить программистов багами и бубликами, не умеют искать и находить нужные сведения в любой документации, даже в карандашном черновике «как будет выглядеть будущая система».
Во всех иных случаях эксплоратив и тестирование по чек-листу это, скорее, отработка служебных обязанностей, нежели результативная работа. Хотя бывает и положительный результат, но теоретизировать о практических вещах сложно и чаще — ненужно…
НравитсяНравится
Спасибо за статью. В условиях отсутствия документации (принципиального отсутствия, ее просто некому и некогда писать) очень полезная вещь. Хотя что-то в этом роде я и сама делаю, но приятно, что кто-то написал о том, что «и так тоже можно» 🙂
Может быть посоветуете, что еще можно почитать про тестирование в условиях «Вот тебе приложение, тестируй, как работает сама поймешь»? Хотелось бы более подробно.
НравитсяНравится
🙂
Верно, это часть тест-плана. Просто я «словчил», и выдал часть за целое. Как бы, мой ответ на информационную кашу, которую мне когда-то пришлось прожевать, чтобы понять разницу — что есть план тестирования, а что есть план действий.
Надеюсь, что в моем изложении это чётко видно.
НравитсяНравится
Спасибо, за отзыв о статье…
Ваше дополнение тоже понравилось, даже навело на мысли о написании статьи:
Test Plan vs Check List
Но это в будущем…
Что же сейчас: я согласен, что тест план надо, чтобы «Cover Your Ass», но и не только для этого… в первую очередь — это документ. И конечно как порождение бюрократии, он всеже нужен, а начинаешь это понимать, когда на любой вопрос по проекту, можешь найти ответ в своем тест плане 🙂
Что же касается чек листов, то для небольших проектов, я сам пользуюсь именно ими. Но если капнуть глубже, то чек лист — это часть тест плана, а именно пункт: Features To Be Tested, а этот пункт — можно сказать основной…
Вот…
Еще раз спасибо…
НравитсяНравится