Тест план, тест дизайн, тест кейсы.

Поскольку возникла пищащая необходимость разложить в голове по полочкам эти понятия, постольку буду делать это здесь, да и в качестве вводной теорчасти это будет небесполезно, ящитаю. Итак, пункт первый.
Тест план. Как новичок обычно представляет себе процесс тестирования? Ну там посмотреть текстовые ошибки, отловить баги, понажимать кнопочки так и сяк. Баг репорт склепать и отправить разработчикам. Вот что я вам скажу - херня всё это, процесс собственно отлова багов занимает процентов 10-20 всего процесса (зато регрессионное тестирование это по стопиццот раз одно и тоже). Ибо нажимая так и сяк каждый раз одно и тоже, приходишь к выводу, что делаешь одну работу и нужно её как-то систематизировать, а потом просто адаптировать к каждому случаю. То есть нам нужен план отличный план!. Тест план Джеймс План. Итак, тест план - это документ, описывающий весь объём работ по тестированию (более полно тут, с обязательными пунктами) с учётом используемых подходов, системных ресурсов, человеческих в конце концов ресурсов (кто и что будет разрабатывать и тестировать). Я полагаю, тест план в идеале должен составлять руководитель отдела тестировщиков (Team Lead?), ибо плохо пока представляю иерархию в этой области. Но кто-то главный, кто видел процесс и изнутри, и снаружи - это точно.
Тест дизайн. Итак, тест план уже есть, задачи разделены, серьги розданы, можно кидаться к вожделенному отлову зловредных багов? Не-ет, родные, мы же не хотим из раза в раз на разных продуктах делать одно и тоже без системы, с ужасном накануне релиза вспоминая что забыли проверить ещё "вот это, это и то"? Мы-то хотим спать с чистой совестью, зная, что прошлись по всем возможным местам обитания любимых насекомых. Значит, каждому из команды нужен ещё и тест дизайн, на основе которого будут составлены тест кейсы, на основе которых будут писаться баг репорты в доме, который построил Джек, и на основе которых будет идти регрессионное тестирование (прогонка после отладки) и не один раз. Собственно, тест дизайн - это всего лишь набор техник для составления тест кейсов. В некотором роде у Тамре вот тут тоже техники тест дизайна. По protesting.ru это:
Эквивалентное Разделение (Equivalence Partitioning - EP)
Анализ Граничных Значений (Boundary Value Analysis - BVA)
Причина / Следствие (Cause/Effect - CE)
Предугадывание ошибки (Error Guessing - EG)
Исчерпывающее тестирование (Exhaustive Testing - ET)
То есть это приёмы, на основе которых мы будем писать тест кейсы. К примеру, Анализ граничных значений - это те самые граничные значение, +1 и -1, эта техника будет использована для валидации полей ввода данных. Если есть поля вводы данных - без этого не обойтись и мы уже не забудем включить этот метод в тест кейсы при проверке всех возможных полей ввода. Кстати, я не совсем понимаю почему бы, имея прямой контакт с разработчиками, заранее не оговорить, чтобы такие поля прописывались с некими стандартами - скажем, тип поля text с ограничением на ввод по ASCII (Юникод) и количеству символов? Ну, к примеру, в поле логин нельзя ввести больше 256 символов только из английской раскладки. На любое другое значение либо превышение размера поля возвращать сообщение об ошибке. Ну, это я так. В рамках тест дизайна. Что касается того, кто разрабатывает тест-дизайн, так это тест-аналитик (определяющий что тестировать) и тест-дизайнер (определяющий как тестировать).
Итак, техники тест дизайна мы изучили, можно приступать к разработке тест кейсов. Это, пожалуй, самая объемная часть работы, потому как, помимо составления, требует и документирования (первые две части тоже требуют документирования, просто эта - наиболее объемная). Тест кейс (тестовый случай) - это, если говорить по существу, условия, в которых система выдаёт ту или иную ошибку (или реагирует правильно). Как правило, условия создаются специально, но вот для текстовых ошибок не нужно что-либо создавать. Но вот указывая последовательность действий, которая приведет к окну с тестовой ошибкой, мы описываем Steps to reproduse - шаги воспроизведения ошибки- один из артефактов баг репорта. В тест кейсе это просто Action - действие, приведшее к фиксации бага. Два других артефакта тест кейса - это Result (результат фактический) и Expected Result (ожидаемый в идеале результат. Как обычно, тут более детально. Тест кейсы составляются непосредственно тестировщиком, хотя вот в России, по слухам с Дальнего Востока, они составляются старшим и даются для прохождения манки-тестеру.
Я хотела ещё зацепить такое понятие, как тестовое покрытие, но, видимо, уже в следующий раз, т.к. слишком много информации в одном посте и папа с малым уже нагулялись и требуют внимания :)
P.S. Ещё на эту же тему: та-дам очень хорророшая аналогия со строительством, настоятельно рекомендую.