План тестирования должен быть внятным, четким, небольшим

Автор: | 13.06.2008

Весьма рассудительная статья План тестирования на блоге “Про тестинг”.

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

Тест план (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

 

План тестирования должен быть внятным, четким, небольшим: 15 комментариев

  1. Alexey Bulat

    Спасибо, за отзыв о статье…
    Ваше дополнение тоже понравилось, даже навело на мысли о написании статьи:
    Test Plan vs Check List
    Но это в будущем…
    Что же сейчас: я согласен, что тест план надо, чтобы “Cover Your Ass”, но и не только для этого… в первую очередь – это документ. И конечно как порождение бюрократии, он всеже нужен, а начинаешь это понимать, когда на любой вопрос по проекту, можешь найти ответ в своем тест плане 🙂
    Что же касается чек листов, то для небольших проектов, я сам пользуюсь именно ими. Но если капнуть глубже, то чек лист – это часть тест плана, а именно пункт: Features To Be Tested, а этот пункт – можно сказать основной…
    Вот…
    Еще раз спасибо…

  2. astenix

    🙂
    Верно, это часть тест-плана. Просто я “словчил”, и выдал часть за целое. Как бы, мой ответ на информационную кашу, которую мне когда-то пришлось прожевать, чтобы понять разницу – что есть план тестирования, а что есть план действий.
    Надеюсь, что в моем изложении это чётко видно.

  3. Tlissy

    Спасибо за статью. В условиях отсутствия документации (принципиального отсутствия, ее просто некому и некогда писать) очень полезная вещь. Хотя что-то в этом роде я и сама делаю, но приятно, что кто-то написал о том, что “и так тоже можно” 🙂
    Может быть посоветуете, что еще можно почитать про тестирование в условиях “Вот тебе приложение, тестируй, как работает сама поймешь”? Хотелось бы более подробно.

  4. astenix

    Tlissy – спасибо.
    Не видел я таких статей. Все ведь пишут о тестировании “как должно быть”, с уровня обозрения методологий и их сравнения, да из глубин базисов, с толкования основных терминов тестирования… Я сам напишу на эту тему 🙂
    Возможно, наиболее близко об этом иногда пишет James Bach – в pdf есть описание культивируемого им метода Rapid Testing – все на английском, переводов не видал. Еще у него есть блог.
    Следует учесть, что в тестировании этот дядька с запамятных времен, и всех методологий он навидался изрядно. И знает, что иногда тестирование в отстутствии тестовой документации называется Exploratory testing, но чаще это называется “organisational disorder”, с чем надо бороться.
    То есть, метод/подход Баха – не панацея и не лоция к тихим гаваням Бермуд. Это “один из” методов – иногда где-то он “самое то”.
    Я бы уточнил, что чек-лист – это как быстрое, почти условное наложение перевязки в боевых условиях. Все равно – позже надо будет дотащить товарища до медсанбата, слишком велик риск инфекций.
    Метод “тестирование без документации” обычно присущ опытным инженерам, которые настолько “наелись” знаний по тому, как и что должно было бы работать, что могут проверять это без особой подготовки или предварительной подготовки тестовой документации (не обязательно подробной).
    Сравнил бы это с коллективом опытных музыкантов, которые могут играть вместе какую-то мелодию практически без подготовки, по-наитию. Но все опытные музыканты знают, что может случиться, если им предварительно НЕ сыграться…
    Или он присущ молодым тестировщикам, которые еще не умеют сосуществовать с программистами, не умеют кормить программистов багами и бубликами, не умеют искать и находить нужные сведения в любой документации, даже в карандашном черновике “как будет выглядеть будущая система”.
    Во всех иных случаях эксплоратив и тестирование по чек-листу это, скорее, отработка служебных обязанностей, нежели результативная работа. Хотя бывает и положительный результат, но теоретизировать о практических вещах сложно и чаще – ненужно…

  5. Уведомление: Источник всех бед « QA - грамотно

  6. Saty

    Говорю искренне человеческое спасибо за статью!
    Статья и приложение к ней открывают глаза нам молодым неопытным;)
    пасиб!

  7. Алексей Лупан

    Спасибо, Saty
    Однако рекомендую читать подобные статьи как пропаганадистские агитматериалы за подписью Геббельса, например. То есть, взвешенно и отстраненно, не принимая на веру.

  8. Serj

    “Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.”
    Могли бы ли Вы (очень Вас прошу) дать чуть более развернутый ответ чем же по сути отличается тест-план от чеклиста и чем чек-лист отличается от тест-кейса?
    Зараннее спасибо!
    Я хочу сказать что существует понятие чеклиста, но оно очень размытое и я до сих пор не нашел ни одного четкого определения.

  9. Алексей Лупан

    Ну, вот вам четкое определение: упорядоченный список всех дел, логических и физических сущностей, материалов, терминов, целей, понятий которые надо сделать, чтобы протестировать что-то, называется тест-планом.
    Это рукописный документ, который нужно сочинять самостоятельно (это первая трудность при работе с подобной документацией).
    Зачастую используется в компаниях и ситуациях, когда необходимо очень точно и четко договориться о целях тестирования, о физической или логической наличии возможностей для проведения тестирования…
    Блин.
    Получается заумно.
    В общем, если у вас есть въедливый закащщик, который может взгреть вас за любой промах, или может переложить на вас ответственность за какие-то проблемы, вам нужно написать документик.
    Или если у вас разрозненная команда, и нужно составить доступный для обеих сторон перечень целей тестирования, серверов, логинов, и прочих важных вещей, чтобы в итоге все стороны говорили об одном и том же на одном и том же языке – вам нужно написать документик.
    Или если вам платят за часы работы по определенному плану, а не “в принципе” и “как получится” – вам нужно написать документик.
    Или если вам скучно, а заняться на производстве нечем – вам нужно написать документик.
    В нём будет несколько разделов с подробными (ключевое слово – подробными) ответами на ряд вопросов.
    Вопросы простые, но ответы бывают очень неоднозначными.
    Например:
    – что будем тестировать,
    – нафига нам это надо тестировать,
    – кто именно это будет тестировать, сколько нужно народу,
    – где именно мы это будем тестировать (сервера, компьютеры, конфигурация компьютеров, софта, погодных условий и тыды),
    – до каких пор мы это будем тестировать,
    – в какой последовательности мы это будем тестировать,
    – какие области наиболее приоритетны,
    – как именно мы это будем тестировать (сюда обычно попадают тест-кейсы),
    – на протяжении какого периода суток,
    – и тыды, если эта информация кому-то нужна и важна.
    В разных школах разработки существуют примерные заготовки тест-планов. Типа как тут http://www.carnegiequality.com/testing/test-plan-template/
    Предполагается, что умный человек-тестировщик эту заготовку прочитает, оставит там только то, что ему нужно, вычеркнет то, что не нужно, и план готов. Большинство людей ломаются уже на этом этапе – как, неужели это еще надо самостоятельно писать-то?
    Предполагается, что в процессе работы над тест-планом все темные места прояснятся, все детали будут продуманы и все нужные средства будут собраны, чтобы все прошло без проблем.
    А потом, мол, этот документ будет нам и ориентиром качества проделанной работы, и отчетом.
    Итого: тест-планом является подробный перечень всего того, что нужно для проведения тестирования чего-то.
    Указаны цели, задачи, требуемые ресурсы, технические подробности, ответственные лица, и прочее подобное. Приведена вся необходимая информация, ознакомившись с которой любой читатель документа узнает и поймет всё, что ему хотелось узнать и понять.
    Еще раз отмечу – туда надо записывать то, что важно, а не всё подряд, “лишь бы было”.
    После написания тест-план надо согласовать со всеми участниками разработки, которым это тестирование и было нужно. Тяжелый этап 🙂
    После согласования и внесения коррективов, можно приступать к работе по этому плану.
    Отклонения надо подправлять, изменения отражать, итог всей работы делать максимально предсказуемым.
    В общем, тест-план – это план действий с техническими подробностями.
    Важно понимать, что информации в этом плане может быть очень до хрена. Человек должен решать, что именно в этом плане должно содержаться, ответы на какие вопросы там должны быть, а на какие совершенно не нужны, бо это никому не нужно.
    Очень такие документы помогают в борьбе с уродами, которые говорят “А мы думали, что вы будете тестировать и под таким-то нестандартным браузером и нестандартным расширением – это же само по себе подразумевается…” Ни фига не самоподразумевается, и план помогает подобные пункты отдельно и особо обговорить. Мир во всем мире и свобода слова подразумеваются, а в тестировании все должно быть четким и ясным. Планировали тестировать с расширением 800×600 = получите и распишитесь.
    Четкость и ясность приносят только подробные указания, которые обсуждаются заинтересованными сторонами.
    Тест-план – инструмент, который помогает достичь ясности и всеобщего согласия.
    Но!
    Есть ситуации, когда объемный и красивый тест-план нафиг не нужен. И даже – вреден.
    Есть компании, в которых тестировать можно без предварительного расписывания адресов серверов, логинов, тест-кейсов и тыды. Бывает, что тестировщиков всего двое на десять программистов, и все мелочи уже всем известны, и все задачи уже обсуждены, и написание тест-плана вызовет только хихиканье и вопросы “Нафига это было нужно? Что, ходил на курсы по написанию тест-планов? Книг начитался?
    Вообще, самой важной частью документации тестировщиков является перечень проверок, которым тестировщики могут подвергнуть тестируемое приложение.
    Иногда это выглядит как список тест-кейсов.
    Иногда это список функционала – ну, просто список.
    Иногда это расширенный, подробный список – функционал отсортирован по значимости, например, и для каждого пункта отдельно прописаны его проверки.
    Простой список того, что нужно не забыть протестировать – это чек-лист.
    Чек-листы бывают разными-разными 🙂 Смотрим сюдой – http://nrukol.blogspot.com/2010/11/blog-post_08.html – там указан файлик, который нужно скачать и прочитать.
    В файлике указаны, собственно, этапы детализации чек-листа. Можно сделать его простым, и этого достаточно. Можно детализировать, указав не только ЧТО надо протестировать, но и КАК это надо тестировать.
    Сила тест-кейса в том, что в нем все расписано очень-очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но когда все это подробное добро приходится обновлять или изменять – становится кисло.
    Сила чек-листа в том, что он простой. Там нет детализации, это просто памятка. Но тестировать приложение по чек-листу сразу, без подготовки, не понимая, что подразумевается под “Зачарджить ордер на бэкофисе” (это где? это как? это что? это откуда и куда?) – невозможно. И степень детализации низка. Глядим, к примеру, на пункт “Проверить чекаут” – там отмечено ‘Pass’. Ок, а как мне убедиться в том, что чекаут был проверен подробно? Тестировщик, который это проверял, действительно добавил товар в корзину всеми шестью способами, которыми это можно сделать на нашем сайте? Без деталей ИНОГДА кирдык как сложно. А иногда детали как раз и не требуются.
    Дык вот.
    Иногда тест-план – это просто очень детализированный чек-лист. Понятно, почему?
    А иногда планировать тестирование можно только на основе чек-листа – он же может служить отчетом о работе. Понятно, почему?
    Следовательно, моя подмена понятий может быть правомочной – в какой-то степени.
    Вообще обойтись без тест-плана невозможно – он есть всегда, в любом виде, даже если ничего не расписано детально, и все хранится только в голове тестировщика.
    Но иногда вполне можно обойтись без детализированного тест-плана, который подразумевается под “крутой документ, с кучей таблиц, графиков, списков и прочей лабуды“.
    Надеюсь, не запутал.

  10. Serj

    “Или если вам скучно, а заняться на производстве нечем – вам нужно написать документик.” 😀
    Спосибо большое! 🙂

  11. Albert Gareev

    К теме.
    “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 выложили или собираются выложить статью в переводе.

  12. Katerina

    Большое спасибо за статью и дополняющие комментарии!
    У меня на носу сдача базиса и все выше указанное очень помогло! 🙂

  13. Юрий

    сори! но я так и не увидел наглядной разницы с примерами. описание тест-плана есть а вот чек листа не наблюдаю!

  14. Алексей Лупан

    Вы правы.
    Тогда я еще не был способен внятно всё сформулировать.
    Сейчас могу, но не буду переписывать. К тому же, у меня тут был расширенный и достаточно исчерпывающий комментарий на эту тему.

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.