PMsoop: Глава №16: Про тест-планы

В ролях - Менеджер Проекта, тестировщики

Артефакты – ТЗ, План Проекта

Суть – Менеджер Проекта ставит тестировщикам задачу разработки планов/сценариев тестирования

Теперь, когда разработчики занялись своими прямыми обязанностями по разработке версии – самое время вспомнить про тестирование. Фактически, с задачами тестирования стоит сделать то же самое, что с задачами разработки – нужно их детализировать.

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

Часть 1.

В которой опишу некоторые нюансы детализации для разных видов тестирования:

1. Функциональное тестирование

Предполагает проверку реализованного функционала на работоспособность и соответствие ТЗ. Часто задача может быть переформулирована так: проверить, что пользователь сможет выполнить все необходимые действия и получить нужный ему результат. То есть, для выполнения функционального тестирования полезно/необходимо знать сценарий работы пользователя приложения. В редких случаях сценарий работы пользователя может быть предоставлен Заказчиком, чаще его составление является задачей тестировщиков проекта.

Сценарий работы пользователя представляет собой чёткую последовательность действий, которые необходимо выполнить пользователю в приложении для получения некоторого результата. Сценариев может быть несколько. Последовательность действий должна быть прямой, без ветвления. Если один и тот же результат можно получить разными способами – это будут разные сценарии. При функциональном тестировании приложения каждое действие сценария проверяется по отдельности – это нужно учитывать при разработке сценария. «Нажать на кнопку» - это не действие, а «ввести данные в форму А, нажать на кнопку Х – автоматический переход на страницу Б» это действие.

Действие из сценария работы пользователя, подлежащее тестированию, обычно определяют как Test Case. Набор test cases составленный согласно сценарию работы пользователя – сценарий тестирования. Если все test cases согласно сценарию пройдены успешно – можно сказать что функционал реализован правильно. Подробнее про сценарии тестирования и test cases можно узнать в специальной литературе – Гугл в помощь.

Таким образом, при детализации функционального тестирования обычно выделяют такие задачи:

- составление сценария работы пользователя;

- составления сценария тестирования согласно предыдущему пункту;

- описание test cases;

- выполнение test cases.

Все эти задачи кроме собственно выполнения test cases можно выполнять во время разработки версии, тестировщики работают параллельно с разработчиками. И тут есть следующий важный для fixed scope & fixed cost проектов момент: обычно при оценке планируемых трудозатрат оценивают только собственно выполнение test cases. Про необходимость разработки сценариев тестирования и test cases на этапе оценок часто забывают. Если так и произошло – придется либо выполнять эти задачи «за свой счет», либо опять пересогласовывать бюджет. А вот отказываться от написания как минимум сценария тестирования до начала тестирования – не стоит, так как качество тестирования «вслепую» всегда оставляет желать лучшего, а «препирательства» с Заказчиком по поводу исправления дефектов всегда затягивают сроки и портят настроение всем участникам проекта.

Впрочем, надо заметить что для некоторых совсем небольших проектов, либо проектов в выполнении которых у Разработчика накоплен большой опыт – бывает достаточно smoke testing, то есть тестирования «просто так», «вслепую», без сценариев и test cases, просто по интуиции тестировщиков.

Для некоторых проектов написание test cases может быть необязательным, достаточно сценария тестирования или сценария работы пользователя, которые можно написать относительно быстро.

Но, для большинства проектов test cases писать нужно, просто необходимо, и чем детальнее - тем лучше. По трудозатратам - на написание качественных test cases обычно уходит немногим меньше времени, чем на разработку функционала, который они покрывают. Чем качественнее test cases – тем качественнее продумано тестирование, и тем меньше дефектов «дойдут» до Заказчика, а значит, тем больше шансов сдать проект во время.

Необходимость написания сценариев тестирования и test cases Менеджер Проекта определяет самостоятельно, следуя принятым в компании-Разработчике стандартам, рекомендациям тестировщиков и руководства, своему опыту и бюджету проекта.

2. Тестирование безопасности

Часто (в относительно простых проектах) совмещается с функциональным тестированием следующим образом. Как уже упоминалось, test case описывает одно действие из сценария работы пользователя. Для выполнения сценария это действие должно совершаться успешно, то есть с определённым результатом. Однако, логично предположить что это действие может совершаться и с другими результатами – в большинстве случаев негативными с точки зрения выбранного сценария тестирования. Действия, которые направлены на проверку возможности получения негативных результатов в test case, могут являться элементами тестирования безопасности приложения. В общем, рекомендация – при разработке test cases следует по возможности запланировать попытки «сломать» функционал, заставить приложение выдавать негативные результаты.

Далее, требования по безопасности приложения могут содержаться в ТЗ, либо выводиться из ТЗ косвенно посредством здравого смысла. Примером таких требований могут являться защита веб-форм от кросс-скриптинга, или защита от ввода спецсимволов в текстовые поля (если поле определено в ТЗ как текстовое – в большинстве случаев логично ограничить ввод спецсимволов, даже если это явно не указано в ТЗ). С точки зрения качества тестирования такие требования к безопасности приложения всегда стоит выписать в явном виде (особенно если их нет в ТЗ) и заранее запланировать средства проверки этих требований при тестировании приложения.

В общем, с точки зрения детализации задач тестирования, обычно стоит сделать следующее:

- учесть дополнительные трудозатраты при написании test cases на планирование проверки «нестандартных» результатов;

- запланировать трудозатраты на выведение основных требований безопасности (ТЗ + здравый смысл), либо их уточнение (если они уже есть);

- запланировать трудозатраты на переформулировку требований безопасности в сценарии проверки их выполнения;

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

Как можно заметить, и здесь все задачи, кроме последней, могут быть легко пропущенными при оценке трудозатрат на тестирование. Что именно и в какой форме потребуется в конкретном проекте предстоит решить Менеджеру этого конкретного Проекта.

3. Нагрузочное тестирование

С точки зрения детализации нагрузочного тестирования можно выделить следующие типичные задачи:

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

- подготовка инструментария – для проведения нагрузочного тестирования часто применяется специализированное ПО как для создания нагрузки, так и для контроля состояния приложения под нагрузкой.

- подготовка среды – задача должна быть определена в рамках спецификации сред и внесена в план проекта, но не лишним будет это проверить

- выполнение тестов и обработка результатов

4. Регрессионное тестирование

Обычно детализируется в соответствии с уже реализованным функционалом, на задачи вида «проверить функцию А». Так как для проведения регрессионного тестирования часто используются те же test cases что и при функциональном тестировании – можно просто скопировать задачи.

5. Тестирование интерфейсов

По этому виду тестирования замечу только один момент: при тестировании веб-приложения в разных браузерах – стоит выбрать основной браузер, в котором будут выполняться все test cases, и выделить отдельные задачи на проверку вида и поведения интерфейсов в остальных используемых браузерах. В случае если все test cases надо проверять во всех барузерах – время на выполнение test case можно смело умножать на количество браузеров. Кстати, аналогичная ситуация с тестированием исполняемых приложений в разных ОС.

Часть 2.

В которой речь пойдёт про действия Менеджера Проекта по детализации тестирования.

Фактически, в части 1 я кратко прошелся по основным понятиям, используемым при планировании тестирования. Теперь о том, что стоит, и что не стоит делать Менеджеру Проекта.

Для начала стоит поговорить с начальником группы тестирования (если он есть), либо ведущим тестировщиком (если он есть), либо с единственным или обоими (если тестировщиков трое – один должен быть либо ведущий либо начальник) тестировщиками. Поговорить следует о том, как он видит процесс тестирования версии, как оценивает необходимость создания тест-плана, разработки сценариев тестирования и написания test cases. По результатам данного разговора необходимо определить, какие средства из перечисленных в части 1, и, возможно, дополнительных средств, стоит использовать в данном конкретном проекте. После чего Менеджер Проекта может поставить своему собеседнику задачу: совместно с группой тестирования разработать и предложить вариант детализации плана тестирования, соответствующий выбранным средствам. В описании варианта должны быть представлены детализированные задачи тестирования + оценки трудозатрат.

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

Чего Менеджеру Проекта делать не стоит – так это пытаться определить, как и что делать тестировщикам, за самих тестировщиков. В большинстве случаев у тестировщиков опыта и квалификации больше, чем у МП, так что к их рекомендациям следует прислушаться. Тут важно понимать ещё и такой момент, что достаточно опытный тестировщик может выполнить тестирование без написанных test cases и сценариев тестирования, причём более качественно, чем новичок вооруженный всеми средствами, сценариями и планами.