Никто и никогда не хочет работать с длинными и монотонными тест-планами. Все больше и больше QA переходят к так называемым методикам тест-планирования, заключающими в себе все мысли и идеи, которые могут и обязательно будут возникать в проектной группе при разработке и тестировании ПО.
Действенные размышления о разнообразных факторах тестирования должны фиксироваться в очень простой и понятливой форме, ведь подобная документация всегда будет на виду до финального релиза всего продукта.
При составлении тест-плана рекомендуется учитывать сразу 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-команды на определенный временной промежуток. Он постоянно будет видоизменяться в ходе продвижения всего проекта и дополняться все новыми и новыми данными.
Вместо того чтобы писать огромный документ, который точно устареет в ходе финализации требований, фокусируйтесь на работе по реализации небольших и гибких документов, которые не сложно обновлять и редактировать!
Оставить комментарий