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

Спосибо большое!

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

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

Блин.

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

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

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

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

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

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

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

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

В разных школах разработки существуют примерные заготовки тест-планов. Типа как тут http://www.carnegiequality.com/testing/test-plan-template/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но!

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

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

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

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

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

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

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

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

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

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

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

Дык вот.

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

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

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

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

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

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

Могли бы ли Вы (очень Вас прошу) дать чуть более развернутый ответ чем же по сути отличается тест-план от чеклиста и чем чек-лист отличается от тест-кейса?
Зараннее спасибо!

Я хочу сказать что существует понятие чеклиста, но оно очень размытое и я до сих пор не нашел ни одного четкого определения.

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

Не видел я таких статей. Все ведь пишут о тестировании “как должно быть”, с уровня обозрения методологий и их сравнения, да из глубин базисов, с толкования основных терминов тестирования… Я сам напишу на эту тему

Возможно, наиболее близко об этом иногда пишет James Bach – в pdf есть описание культивируемого им метода Rapid Testing – все на английском, переводов не видал. Еще у него есть блог.

Следует учесть, что в тестировании этот дядька с запамятных времен, и всех методологий он навидался изрядно. И знает, что иногда тестирование в отстутствии тестовой документации называется Exploratory testing, но чаще это называется “organisational disorder”, с чем надо бороться.

То есть, метод/подход Баха – не панацея и не лоция к тихим гаваням Бермуд. Это “один из” методов – иногда где-то он “самое то”.

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

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

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

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

Во всех иных случаях эксплоратив и тестирование по чек-листу это, скорее, отработка служебных обязанностей, нежели результативная работа. Хотя бывает и положительный результат, но теоретизировать о практических вещах сложно и чаще – ненужно…