Сложилось впечатление, что, когда звучит вопрос о целях тестирования, говорят исключительно о тест-плане (окей, иногда еще упоминают тестовую стратегию, но в отрыве от общей структуры). Так вот… Соответствуют ли цели, закрепленные в тест-плане, целям более высокого уровня?
Попробуем представить картину целиком:
Политика качества (quality policy) — документ, определяющий общее видение, цели и обязательства организации в области качества. Он отвечает на вопрос: “Что для нас качество?” и демонстрирует приверженность стандартам (например, ISO 9001)
Политика тестирования (test policy) — документ, в котором описаны принципы и цели тестирования в организации. Отвечая на вопрос: “Зачем мы тестируем?”, она задает универсальные правила тестирования, которые служат ориентиром для всех участников
Стратегия тестирования (test strategy) — документ, содержащий верхнеуровневое описание процесса тестирования продукта с точки зрения подходов и/или их сочетания (аналитический, методический, на основе рисков/стандарта/модели, консультативный, реактивный, на основе минимизации регресса… ), в общем: “Как мы будем тестировать в заданных условиях?”
План тестирования (test plan) — документ, описывающий цели тестирования, которые должны быть достигнуты и средства (приемы) их достижения: “Какие задачи по тестированию нужно выполнить и как они будут организованы?”. В отличие от стратегии, план тестирования имеет временные рамки и направлен уже непосредственно на практическую реализацию
Т.е. документы образуют иерархию, где каждый нижестоящий документ детализирует и адаптирует правила, описанные на более высоком уровне, позволяя тем самым сформировать наиболее полные ожидания от тестирования
Конечно же, в реальных условиях эта иерархия модифицируется: в небольших командах документы упрощаются или вовсе не нужны, в командах побольше они могут объединяться или называться как-то по-другому, поэтому не стоит сильно зацикливаться на шаблонах. Вопрос лишь в том, доносит ли документ ту мысль, ради которой он и был задуман или же от первоначальной задумки осталось одно только название
Например, если мы говорим о тестировании в agile, то сразу же могут возникнуть вопросы к тест-плану: “Какие временные рамки? У нас итеративный процесс, какой тест-план?!”. В таких условиях тест-план либо сокращается до одной страницы и фиксирует какие-то общие договорённости (см. хороший пример у AGIMA), либо становится излишней нагрузкой — документацией, которая никому не нужна, но её почему-то необходимо поддерживать. Быть может, тогда лучше сосредоточиться на тестовой стратегии, а для управления тестированием в итерациях использовать что-нибудь более подходящее?
Квадранты тестирования — модель, которая визуализирует управление тестами в гибких методологиях, где:
- Q1 — технологии, поддержка команды (неспосредственное качество кода: компонентное тестирование и тестирование интеграции компонентов)
- Q2 — бизнес, поддержка команды (работа с требованиями, сценариями и прототипами, функциональное тестирование)
- Q3 — бизнес, критика продукта (исследовательское тестирование, пользовательское приемочное тестирование, удобство использования)
- Q4 — технологии, критика продукта (нефункциональное тестирование, за исключением удобства использования)
Если какой-либо документ теряет смысл или начинает дублировать другой, возможно, пора пересмотреть его — это будет стоить явно дешевле, чем восстановление репутации команды тестирования спустя какое-то время 👌
На мой взгляд, стратегии, отражающей контекст тестирования продукта, и квадрантов с гиперссылками на ключевые узлы для большинства случаев будет более чем достаточно
