Хорошей практикой в нормальных компаниях считается, когда тест-план пишется до того, как началось тестирование, но уже началась какая никакая разработка. Но это в нормальных компаний. Большинство в ру сегменте такой практики не придерживаются. И это скорее плохо, чем никак. Потому что при наличии тест-плана можно объяснить, что и зачем ты в принципе будешь делать, а главное как.
Как любая проектная документация, тест-план может иметь совершенно разный вид и форму. Тут зависит от стандартов кампании и фантазии менеджеров и тестировщика, который в итоге будет этот тест-план составлять.
Но из опыта я могу выделить, какие пункты точно нужны. А дальше каждый уже сам может воевать в ту сторону, в которую ему велели.
Итак, что мы должны иметь:
- Объекты разработки.
- Объекты тестирования.
- Стратегии тестирования.
- Сроки тестирования.
- Критерии начала тестирования.
- Критерии окончания тестирования.
Это основные пункты, в которые, конечно же, включаются подпункты. Потому как тест-план документ расширяемый, и хорошо, если он динамический. То есть его пересмотр происходит если не каждый спринт, то хотя бы раз в месяц вместе с проджектом и продактом. А если у вас ещё и аналитик на проекте есть, то считайте, ваша жизнь удалась.
К слову о расширяемости. Я думаю, заметно, что первый и второй пункты выглядят э-э-э одинаковыми. Они на самом деле очень похожи. Просто их смысловая нагрузка различается. И вот как:
Первый пункт говорит нам об описании проекта и из чего он состоит в принципе. Что мы разрабатываем и как.
А вот второй пункт говорит о том, что конкретно мы будем тестировать. Даже если у нас совпадают пункты (например: сайт и мобильное приложение) информация в этих блоках по смысловой нагрузке разная. Во втором пункте мы должны составить список функций с описанием тестируемой системы и расписать каждый её компонент в отдельности.
Потому как заказчик всегда может прийти и сказать, что что-то он будет тестировать сам, на своей стороне. Значит, мы эту работу с себя снимаем и, конечно, не отражаем в тест-плане. Ну, или отражаем, но только в качестве ссылки на письмо или решение заказчика, которое должно быть задукоментированно.
Тест-план это то ещё хранилище ссылок. Но это здорово, когда ты можешь открыть один документ и найти в нем ссылки на все прочие, которые тебе, вероятно, понадобятся в работе.
Дальше у нас идет третий пункт. Стратегия. Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования. Желательно подробно, со всеми этапами.
И вот тут важный момент. Конечно, в начале разработки тест-плана когда ничего ещё нет, мы будем оперировать базовыми стратегиями тестирования. И это нормально. Поэтому я и говорю про то, что хорош тот тест-план который динамически развивается вместе с проектом.
Четвертый пункт - про то, как мы будем ходить и трясти проджекта, аналитика и разработчиков с одним вопросом: "Когда? ". Но изначально можно взять карту дат релиза, если она у вас есть, и посмотреть на даты оттуда. Берите минус месяц от даты релиза. Или минимум две недели, если у вас один проект и вы не один тестировщик. В противном случае культурно ругайтесь и спрашивайте у всех - "Ты, что, желаешь мне смерти? " Потому что если вам дали срок тестирования сайта в несколько страниц с полями ввода и логикой в неделю, вероятно, да. Они хотят вашей смерти.
Итак, мы подошли к критериям начала тестирования. Сюда входит перечисление того, что вам необходимо для начала работы. Готовность тестовой платформы (тестового стенда) законченность разработки требуемого функционала, наличие всей необходимой документации и тому подобное.
И финал - критерии окончания тестирования. Не знаю, как для кого, а я считаю, что критерий один. Тебе сказали: хватит, значит хватит. Сроки вышли - отдаем. Чаще всего происходит именно так. Но мы будем учитывать не только мой опыт, а как это должно быть. Поэтому прописываем такие пункты, как:
- результаты тестирования удовлетворяют критериям качества продукта.
- требования к количеству открытых багов выполнены.
- выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)
- выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
Ну вот и все. Базовый тест план готов. Теперь ссылкой на него можно бросить в проджекта и в продакта. Ну и в других членов команды тоже не помешало бы.