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

[highlight dark=”no”]Действенные размышления о разнообразных факторах тестирования должны фиксироваться в очень простой и понятливой форме[/highlight], ведь подобная документация всегда будет на виду до финального релиза всего продукта.

При составлении тест-плана рекомендуется учитывать сразу 5 базовых критериев:

1. Что конкретно будет протестировано? – Масштабность тестирования.
2. Как именно ПО будет протестировано?
3. Кто конкретно будет это тестировать?
4. Почему это нужно обязательно протестировать?
5. Когда будет дан старт тестированию и когда оно будет завершено?

Нужно понимать, что составление плана на 50-100 страниц – это пустая трата бесценного времени, так как никто не будет вникать в такую документацию. Современные методики и тенденции в сфере QA услуг требуют минимального, но эффективного документирования.

Ниже представлены три варианта составления подобного тест-плана. Рассмотрим их более детально.

Тест-планирование как ментальная карта всего проекта

Ментальные карты – это бесценная экономия времени! В их содержание можно уместить массу полезных вещей.

Структура подобной ментальной карты должна содержать следующие моменты:

• Создание центрального раздела, суть которого раскрывается в вопросе, что должен получить QA-специалист по завершению тестирования, а что тестировать не нужно?
• Создание веток: масштабность тестирования, временные затраты, привлеченные тест-ресурсы, применяемые тест-подходы, потенциальные риски и возможные допущения.

Несколько примеров для составления своей ментальной карты:
Using Mind Maps for Test Planning
Mind Maps in Software Testing

Тест-план на 1 страницу

Сложно реализуемый подход – создание тест-плана в форме одностраничной документации. Касательно содержания, такой документ также охватывает все важные критерии тестирования, как и ментальная карта.

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

Охват подобного документа и последовательность имплементации тестовых шагов аналогична ментальной карте.

Конечно же, абсолютно все пункты тест-плана могут и не поместиться на 1 странице, но это не должно быть большой проблемой. Если есть стойкое желание минимизировать объем ненужной информации, значит все в полном порядке! Проверьте только, что изложенная информация актуальна как отделу тестирования, так и клиенту.

Тест-матрица

Подобная стратегия пользуется особой популярностью при Agile and Lean-подходах. Условно, если вы располагаете сразу несколькими ментальными картами, вы легко можете расположить их в набор секций общего тест-плана.

Вот простой и наглядный пример – https://www.slideshare.net/lonsdalesystems/software-testing-canvas

Базовая выгода от данного подхода – разработка качественного механизма для совместного тест-планирования (например, взаимодействие отдела тестирования и отдела поддержки).

Итог

Сам по себе тест-план не содержит ничего полезного. Крайне важно, какие мысли и идеи закладываются в его структуру. Тест-план – всего лишь «посредник», в структуре которого фиксируются намерения QA-команды на определенный временной промежуток. Он постоянно будет видоизменяться в ходе продвижения всего проекта и дополняться все новыми и новыми данными.

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