Обучение

Новости
О центре
Центр карьеры
Сообщение об ошибке

Обучение

Ближайшие старты

IT Bootcamp

Новости

О центре

Центр карьеры

Корпоративное обучение

Отзывы

Истории успеха

Сообщение об ошибке
Введите поисковый запрос

Всё идёт по тест-плану. Но не всегда...

9 апреля 2019

По сути, тест-план – это результат планирования, главный документ, которым руководствуется тестировщик при выполнении своей работы. В идеале в нём пошагово расписано, как, что, зачем, в какой срок и при помощи каких инструментов необходимо делать. Но это теория, а как дела обстоят на практике: всегда ли создаются тест-планы, обращают ли на них внимание заказчики, что вообще обязательно должно быть отражено в этом документе? На эти вопросы отвечает QA директор iTechArt, автор курса «Оценка трудозатрат и планирование тестирования» Оксана Скиндер.


В своей практике я сталкивалась как с небольшими, так и с масштабными проектами. И ни разу за всё время заказчики не просили показать тест-план. Просто потому, что большинство из них не знает о его существовании. Заказчик – не тестировщик, он не знаком с принципами организации работы. С другой стороны, нередко сами тестировщики пренебрегают созданием такого документа. Мол, у нас и так много работы, времени мало, а тест-план всё равно никто не просит, сделаем без него.

Соглашусь, в некоторых ситуациях реально обойтись без него, но моё личное мнение – в большинстве случаев тест-план всё же необходим. Потому у своей команды прошу: стартуете на проекте – через месяц представьте тест-план. Неважно, в каком формате и как он будет оформлен – в виде традиционного word или pdf файла, майнд-карт, таблиц, диаграмм. Это на суть не влияет, но для грамотной организации дальнейшей работы такой документ нужен.

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

Что при этом должно быть обязательно отражено в качественном тест-плане? В первую очередь – что мы тестируем, а что нет. Иногда доходит до смешного: заказчик разрабатывает приложение на английском языке, но при этом хочет предусмотреть поддержку на немецком, французском и русском. Спрашивает: вы же обратите внимание на корректность перевода? Сходу отвечаем: нет. Этим занимаются переводчики, тестировщики проверяют, есть ли перевод, все ли части текста переведены, правильно ли отображается, например, валюта при выборе той или иной страны. В тест-плане мы прописываем зону своей ответственности, и уже на старте регулируем ожидания заказчика и работу, которая будет выполняться при тестировании.

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


Следующий этап: решаем, какие виды тестов будем проводить. Это очень важная информация для всей команды. В своей практике я сталкивалась с тем, что тестировщики не всегда могут объяснить, зачем они проводят те или иные тесты, почему решили применять именно их или запланировали так много. Тест-план помогает чётко сформулировать, что реально важно сделать.

Затем прописываем тестовую документацию: под какие виды тестирования мы пишем сценарии, когда необходимы тест-кейсы, в каких случаях можно ограничиться чек-листами, какие матрицы будем создавать и так далее. И для команды, и для заказчика – это важный прогноз.

Далее определяемся, какие инструменты нужны для проведения тестирования. Этот пункт важен в том случае, если на проект добавляется новый тестировщик – он просто открывает тест-план и сразу видит, что ему нужно применять в своей работе. Нет необходимости тратить время на объяснения.

Иногда в тест-плане указывают и зону ответственности каждого участника команды – по каким вопросам и к кому можно обращаться. Например, тимлид отвечает за планирование и корректность требований, тест-аналитик пишет тестовую документацию, тестировщики – работают по ней. Бывает такое, что в команде нет чёткого разграничения обязанностей – все занимаются всем. И пишут тестовую документацию, и тестируют, и берут в работу новые фичи в зависимости от приоритета. В таком случае зону ответственности прописывать нет необходимости. В остальных – нужно. Это помогает разграничить работу и уменьшить количество вопросов.


Следующий момент – работа с рисками. В тест-плане обязательно прописывается план действий на случай, когда риск реализовался: если возникает проблема, то, пока она устраняется, команда занимается другими задачами. Например, в процессе тестирования видим больше багов, чем ожидали, – заново проводим эстимацию и согласовываем новые сроки, недоступен сервер – переходим к другим активностям. Все этим моменты должны быть прописаны и согласованы. При этом тест-план – живой документ, который можно и нужно обновлять. Когда встречаются новые риски, то мы их добавляем в план. Точно также в него вносятся и другие изменения, которые отражают реальное положение дел на проекте.

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

Подробнее о тест-планах и эстимации речь пойдёт на профессиональном курсе «Оценка трудозатрат и планирование тестирования», который стартует 18 мая. Узнать подробности и записаться можно здесь.


Полная, частичная перепечатка или любое иное использование материалов с сайта IT-Academy разрешается только с указанием активной гиперссылки, ведущей на первоисточник (точный адрес страницы на www.it-academy.by).