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

Это рукописный документ, который нужно сочинять самостоятельно (это первая трудность при работе с подобной документацией).

Зачастую используется в компаниях и ситуациях, когда необходимо очень точно и четко договориться о целях тестирования, о физической или логической наличии возможностей для проведения тестирования…

Получается заумно.

В общем, если у вас есть въедливый закащщик, который может взгреть вас за любой промах, или может переложить на вас ответственность за какие-то проблемы, вам нужно написать документик.

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

Или если вам платят за часы работы по определенному плану, а не «в принципе» и «как получится» — вам нужно написать документик.

Или если вам скучно, а заняться на производстве нечем — вам нужно написать документик.

В нём будет несколько разделов с подробными (ключевое слово — подробными) ответами на ряд вопросов.

Вопросы простые, но ответы бывают очень неоднозначными.

Например:
— что будем тестировать,
— нафига нам это надо тестировать,
— кто именно это будет тестировать, сколько нужно народу,
— где именно мы это будем тестировать (сервера, компьютеры, конфигурация компьютеров, софта, погодных условий и тыды),
— до каких пор мы это будем тестировать,
— в какой последовательности мы это будем тестировать,
— какие области наиболее приоритетны,
— как именно мы это будем тестировать (сюда обычно попадают тест-кейсы),
— на протяжении какого периода суток,
— и тыды, если эта информация кому-то нужна и важна.

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

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

А потом, мол, этот документ будет нам и ориентиром качества проделанной работы, и отчетом.

Итого: тест-планом является подробный перечень всего того, что нужно для проведения тестирования чего-то.

Указаны цели, задачи, требуемые ресурсы, технические подробности, ответственные лица, и прочее подобное. Приведена вся необходимая информация, ознакомившись с которой любой читатель документа узнает и поймет всё, что ему хотелось узнать и понять.

Еще раз отмечу — туда надо записывать то, что важно, а не всё подряд, «лишь бы было».

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

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

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

В общем, тест-план — это план действий с техническими подробностями.

Важно понимать, что информации в этом плане может быть очень до хрена. Человек должен решать, что именно в этом плане должно содержаться, ответы на какие вопросы там должны быть, а на какие совершенно не нужны, бо это никому не нужно.

Очень такие документы помогают в борьбе с уродами, которые говорят «А мы думали, что вы будете тестировать и под таким-то нестандартным браузером и нестандартным расширением — это же само по себе подразумевается… » Ни фига не самоподразумевается, и план помогает подобные пункты отдельно и особо обговорить. Мир во всем мире и свобода слова подразумеваются, а в тестировании все должно быть четким и ясным. Планировали тестировать с расширением 800×600 = получите и распишитесь.

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

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

Есть ситуации, когда объемный и красивый тест-план нафиг не нужен. И даже — вреден.

Есть компании, в которых тестировать можно без предварительного расписывания адресов серверов, логинов, тест-кейсов и тыды. Бывает, что тестировщиков всего двое на десять программистов, и все мелочи уже всем известны, и все задачи уже обсуждены, и написание тест-плана вызовет только хихиканье и вопросы «Нафига это было нужно? Что, ходил на курсы по написанию тест-планов? Книг начитался? »

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

Иногда это выглядит как список тест-кейсов.

Иногда это список функционала — ну, просто список.

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

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

Чек-листы бывают разными-разными 🙂 Смотрим сюдой — http://nrukol.blogspot.com/2010/11/blog-post_08.html — там указан файлик, который нужно скачать и прочитать.

В файлике указаны, собственно, этапы детализации чек-листа. Можно сделать его простым, и этого достаточно. Можно детализировать, указав не только ЧТО надо протестировать, но и КАК это надо тестировать.

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

Сила чек-листа в том, что он простой. Там нет детализации, это просто памятка. Но тестировать приложение по чек-листу сразу, без подготовки, не понимая, что подразумевается под «Зачарджить ордер на бэкофисе » (это где? это как? это что? это откуда и куда?) — невозможно. И степень детализации низка. Глядим, к примеру, на пункт «Проверить чекаут» — там отмечено ‘Pass’. Ок, а как мне убедиться в том, что чекаут был проверен подробно? Тестировщик, который это проверял, действительно добавил товар в корзину всеми шестью способами, которыми это можно сделать на нашем сайте? Без деталей ИНОГДА кирдык как сложно. А иногда детали как раз и не требуются.

Иногда тест-план — это просто очень детализированный чек-лист. Понятно, почему?

А иногда планировать тестирование можно только на основе чек-листа — он же может служить отчетом о работе. Понятно, почему?

Следовательно, моя подмена понятий может быть правомочной — в какой-то степени.

Вообще обойтись без тест-плана невозможно — он есть всегда, в любом виде, даже если ничего не расписано детально, и все хранится только в голове тестировщика.

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

Надеюсь, не запутал.

Нравится

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

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

Я абсолютно уверен, что PHP-программисты редко пишут тесты, потому что начинают не с того конца. Все знают, что тесты это хорошо и клево. Но открыв сайт того же PHPUnit , и прочитав красочный пример о тестировании калькулятора умеющего выполнять операцию a + b, они спрашивают себя: какое отношение этот калькулятор имеет к моему приложению? Ответ: никакого. Ровно как все похожие примеры, на сайтах других фреймворков тестирования. Будто бы все забыли, что PHP прежде всего для веба. Будто бы все пишут калькуляторы, а не сайты на основе MVC-парадигмы.

Положим, вы создаете сайт или разрабатываете веб-приложение. На нем уже есть некоторые страницы, формы, возможно даже интерактивные элементы. Как вы (или, допустим, ваш заказчик) проверяете что сайт работает? Наверняка вы заходите на сайт, кликаете по ссылкам, заполняете формы, смотрите на результат. И по-хорошему, все эти рутинные процессы кликанья и заполнения форм, стоит автоматизировать в первую очередь.

И потому мы поговорим о функциональных тестах (или приемочных).

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

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

Что у нас есть для функционального тестирования? Из всего известного мне, это Codeception и, например, PHPUnit + Mink или прямое использование Selenium. Я хотел включить в этот печерень и Behat , но его автор попросил не использовать Behat для функционального тестирования .

Если бы тестировать с Selenium или PHPUnit + Mink было просто, вы бы уже наверняка их использовали. Потому остановимся на Codeception.

Тест в нем описывается так:

wantTo("see my site is working"); $I->amOnPage("/"); $I->see("Welcome, on my site!"); ?>

Всего в несколько строчек вы проверяете, что как минимум, главная страница вашего сайта открывается. За длительной работой, сломать её, не так и сложно.
Точно так же, вы можете описывать дальнейшие действия:

click("Feedback"); $I->see("Submit your feedback"); $I->fillField("Body","Your site is great!"); $I->click("Submit"); $I->see("Thanks for your feedback!"); ?>

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

А теперь попробуем определиться, с unit-тестами.

Модульное тестирование, или юнит-тестирование (англ. unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

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

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

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

Или ещё один пример: у вас на сайте акция - каждый 100ый зарегистрированый пользователь получает подарок. Как бы так проверить, что подарки выдаются, и не создавать при этом 100 лишних пользователей? Вот тут уже пишите юнит-тесты. Без них, скорее всего, никак.

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

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

Для юнит-тестирования фреймворков много.

Недавно прогулявшись по форумам и по ресурсам посвященным тестированию ПО, нашел определенный дефицит информации по планированию тестирования . Точнее информация есть, но не всегда в доступной форме. Постараюсь разжевать и объяснить на простом языке "Кто? Где? Когда?" занимается планированием и какая информация должна входить в тест план. Начнем с определения:

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

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829 :

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

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

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

• Окружение тестируемой системы
• Необходимое для тестирования оборудование и программные средства
• Риски и их разрешение

Виды тест планов

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

• Мастер Тест План (Master Plan or Master Test Plan)
• Тест План (я его называю детальный тест план)

На мой взгляд явное отличие этих документов в том, что мастер тест план является более статичным в силу того, что содержит в себе High Level информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестированияи, расписанию выполнения работ, является "живым" документом, который постоянно притерпевает изменения, отражающие реальное положение вещей на проекте.

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

Рецензия и Утверждение

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

• Ведущий тестировщик
• Тест менеджер (менеджер по качеству)
• Руководитель разработки
• Менеджер Проекта

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

Вывод

Воспользовавшись вышеуказанными советами, у вас будет больше шансов написать хороший документ, нежели придумывать все самим.
Жду ваши вопросы и замечания.

Переработки и дополнения к статье смотрите на сайте ПроТестинг - Тест план

11 комментариев:

Анонимный комментирует...

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

Саша, спасибо за комментарий.
На счет разных тест планов дам тебе наводку. Есть 2 тест плана - Master Test Plan и просто Test Plan...
На сколько я понял, повозившись с интернетом и документацией, мастер тест план составляется для крупных проектов, где функционал разделен на несколько частей. И в нем все описано достаточно поверхностно High Level, а вот уже детализация начинается в конкретных тест планах. Но об этом я думаю еще немного дополнить статью... Вот...

Анонимный комментирует...

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

Анонимный комментирует...

Понравилось, как логично и чётко изложено.

С высот QA я спустился в низины QC, и написал вот такое дополнение - План тестирования должен быть внятным, четким, небольшим .

Не сочтите за спам или желание линки раскидать. Все по-делу. Как дополнение к основному тексту, но на более низком уровне.

Статья совершенно бесполезная. Если читатель откроет для себя что-то новое в этой статье то статья точно ему навредит. Моя рекомендация - сначала ответьте себе на вопрос - а зачем вам тестплан? Из своего же ответа на этот вопрос вы получите всю необходимую информацию о содержании тестплана. Если не можете ответить - не делайте тестплана, потеряете время даром, не доросли еще. Всем удачи, abbuk ;)