Тест-план не для галочки, или 8 вопросов к заказчику на старте проекта
Практически на всех проектах, где мне довелось работать, был тест-план. Этот документ колоссально облегчал жизнь тестировщиков и делал ценность нашей работы для заказчика очевидной. Но есть одна деталь. Чтобы тест-план работал в интересах команды, надо составлять его с умом, при этом задавая правильные вопросы клиенту. Меня зовут Юрий Бабай, я сотрудничаю с ЕРАМ в роли Software Testing Team Leader. В этом материале поделюсь своими наработками для создания качественного тест-плана.
Иллюстрация Алины Самолюк
Краткий ликбез
Тест-план — это документ, который описывает все работы, которые будет производить команда тестирования на проекте. Он содержит риски, список нужных ресурсов, распорядок, описание различных процессов тестирования. Тест-план нужен, чтобы дать всем заинтересованным в проекте людям понимание:
- что;
- как;
- когда;
- кем будет тестироваться;
- какие ресурсы требуются для этого процесса.
Тест-план создают на начальной стадии проекта, когда идет сбор требований, формируется техническое задание, становится понятен объем работы и перечень задач. Не только стейкхолдеры, но и тест-лид (или просто наиболее опытный тестировщик на проекте), который пишет этот документ, сталкивается с вопросами. Ответы на них помогают прояснить заказчику, какие виды и уровни тестирования нужны в конкретном случае. И, собственно, «продать» этот сервис с максимальной прозрачностью процессов.
Тест-план покрывает все тестирование на проекте: функциональное, автоматизированное, тестирование безопасности и так далее. Общий документ называют Master Test Plan. Однако в некоторых ситуациях он может покрывать только один или несколько уровней тестирования. Это — Level Test Plan.
А можно без этого?
Если коротко — можно. Тест-план целесообразно писать для длительных проектов. Если ваш проект рассчитан на месяц-два, времени на обширную документацию нет и вы уверены, что не придется вводить в проект новых тестировщиков, тест-стратегии будет достаточно. Она может быть как составляющей частью тест-плана, так и отдельным документом, в котором описано, как именно вы будете проводить тестирование.
Например, на одном из проектов мы начинали разработку с бэкенд-части, поэтому фокус тестирования был смещен на API и работу с базой данных. Соответствующие виды тестирования были отражены в стратегии, которая была частью тест-плана. Спустя несколько месяцев заказчик решил добавить UI, и здесь тест-стратегия была представлена как отдельный документ, в котором основной фокус был направлен на тестирование пользовательского интерфейса. Это позволило акцентировать внимание заказчика непосредственно на изменениях в тестовых подходах и быстрее получить его согласие на них.
В долгосрочных проектах тест-план помогает выстраивать доверительные отношения с клиентом, показывая, что именно будет делать команда тестирования. Особенно полезно создавать такую документацию, если клиент новый. Если вы уже сотрудничаете с заказчиком много лет и работаете над типовыми проектами (например, e-commerce), то зачастую тест-стратегии будет достаточно.
Если все-таки решили создавать тест-план, сразу уточните у клиента: возможно, у него есть шаблон, которому стоит следовать. Если нет, можете использовать общепринятые стандарты: IEEE 829 Test Plan, RUP Test Plan. Мы в ЕРАМ создали собственный шаблон, который подходит для большинства заказчиков. Он основан на нашем опыте и в некоторых пунктах перекликается с мировыми стандартами.
Я считаю, что без тест-плана обойтись можно, но с ним работается лучше. И вот почему:
- этот документ защищает команду тестирования от неожиданных вопросов клиента в духе «а почему мы эту часть не тестируем?»;
- он помогает тест-лиду на старте проекта понять, какие затраты надо запланировать на расширение или обучение команды, сколько времени;
- это хороший гид для ознакомления новичков с процессами на долгосрочном проекте.
Создаем тест-план проекта: поэтапный разбор
Итак, вы решили, что тест-план вашему проекту все-таки нужен. Каждый подобный документ состоит из перечня типичных разделов.
Объем работ. В этот раздел надо включить все, что будете тестировать. Чаще всего это функционал от вашей команды разработки. Пропишите также зоны, качество которых вы проверять не будете (например, зону работы другого подрядчика). Это позволить обозначить границы ответственности: в них может входить интеграция с частями от других вендоров, но не качество чужого кода.
Приёмочные критерии. Укажите уровень качества, которому должен соответствовать продукт, чтобы заказчик его принял. Например, вы обязуетесь, что к моменту релиза не будет известных дефектов с приоритетом critical или major. Или утверждаете, что 80% тест-кейсов должно быть автоматизировано. Подобные критерии позволят клиенту понять, что продукт качественный и его можно отдавать конечным пользователям.
Риски. Здесь можно и нужно прописывать те негативные сценарии, которые могут произойти по ходу проекта. Типичные риски: вовремя не предоставлены тестовые данные, не работают компоненты от сторонних вендоров, нет нужного устройства для тестирования. Например, когда вышел iPhone X с фирменной «челкой» на экране, для многих команд в Украине это стало проблемой. Они не могли тестировать свои продукты перед релизом, потому что на украинском рынке нового устройства еще не было. Проектным менеджерам приходилось искать способы раздобыть девайс, чтобы тестировщики могли проверить продукт на реальном устройстве.
У каждого указанного риска должна быть прописана вероятность наступления, потенциальный ущерб, который он может нанести, ответственное лицо (иными словами, владелец риска), а также меры по предотвращению или работе с последствиями. Конечно, на старте проекта учесть абсолютно все не получится. Потому тест-план стоит дополнять в ходе работы.
Ресурсы. Во-первых, оборудование и/или устройства, которые понадобятся. Во-вторых, программы для тестирования, софт от Word и Excel до Visio и платных лицензий для автоматизации, приложения для менеджмента тест-кейсов (на многих проектах используют TestRail, и он платный).
Команда. Опишите, сколько людей понадобится. Какие у них должны быть знания и навыки, чтобы выполнить все задачи по тестированию. Если требуется, запланируйте тренинги и другое обучение.
Документация. Перечислите все типы документов, которые будете использовать на проекте. Уточните, что они будут включать. Это могут быть чек-листы, тест-кейсы с описанием базовых полей, отчеты, которые вы будете предоставлять заинтересованным лицам (проектным менеджерам, представителям клиента и другим). Укажите периодичность подготовки этих документов и ответственных лиц.
Стратегия. Это, пожалуй, самый интересный и объемный пункт. В стратегии должны быть указаны все виды тестирования, которые будут на проекте: функциональное и нефункциональное, тестирование после изменений, подходы к автоматизации, описание CI/CD pipeline, уровни тестирования и так далее.
В блоке с видами тестирования стоит указать, как каждый из них будет применяться на определенном этапе, какие инструменты потребуются. Например, тестирование производительности можно проводить на разных этапах проекта, но охватывать не все приложение, а только часть. Или, скажем, тестирование доступности порой применяют только к той части приложения, которую будет видеть конечный пользователь (для админ-части интернет-магазина оно будет слишком дорогим и ненужным). Однако учтите, что для некоторых приложений этот вид тестирования является обязательным. Например, в США веб-сайты федерального правительства обязаны быть доступны для людей с ограниченными возможностями. Это регулируется так называемой секцией 508.
Добавьте к стратегии также описание процесса тестирования. Уточните, работаете ли по Scrum или другой методологии, обозначьте этапы, на которых будете начинать тестирование. Перечислите, на каких устройствах, браузерах, расширениях экрана будете проводить проверки качества. Опишите жизненный цикл дефекта на вашем проекте. Все это поможет команде и клиенту быть на одной странице, видеть процесс одинаково и избежать многих недоразумений в будущем.
Расписание. Перечислите все ключевые даты, когда должно быть выполнено то или иное тестирование. Если при написании тест-плана четких дат нет, то сфокусируйтесь на майлстоунах, к которым можно привязаться (например, к такому-то моменту вы проведете регрессионное тестирование, подготовите определенные документы или отчеты). В случае со Scrum опишите ежедневно повторяющиеся активности, дополните список ключевыми датами релизов. Если в графике будут изменения, вносите их в тест-план динамично.
Восемь вопросов для качественного тест-плана
Эти вопросы я задаю заказчику или человеку, который его представляет, на старте нового проекта. Ценность каждого прочувствована на собственном опыте: без дополнительных уточнений можно упустить это из виду и привести команду и проект к проблемам.
Вопрос № 1: Интеграции с другими системами
На крупных проектах, где интеграций со сторонними системами много, нередко возникают сложности. Важно обозначить свою зону ответственности и понимать ее границы. Бывают ситуации, когда мы не можем проверить новый функционал. Еще хуже, когда на продакшене что-то перестает работать и обеспокоенный заказчик звонит среди ночи с просьбой исправить как можно скорее. А при детальном разборе оказывается, что дело не в вашей системе, а в трудностях интеграции или проблемах на стороне другого вендора.
В моей практике был такой случай: мы разрабатывали сервис для покупки авиабилетов. Информацию о доступных маршрутах нам предоставлял сторонний сервис. В один «прекрасный» день у него поменялся API на тестовых окружениях во время того, как заказчик проводил UAT-тестирование перед релизом на продакшн. Очень скоро я обнаружил у себя на почте множество гневных писем от клиента и проектного менеджмента: мол, как мы могли допустить такой продукт на UAT? Реальную причину инцидента мы выяснили только после расследования ситуации: вендор поменял формат данных без предупреждения, и наше приложение перестало их «понимать». Из этой ситуации следует вывод, что перед релизами лучше перестраховаться и узнать у остальных вендоров насчет изменений в контрактах сервисов или запланированном обслуживании систем.
Вопрос № 2: Нефункциональные требования к приложению
Прояснение этого пункта значительно влияет на тестовую стратегию. Заказчики часто упускают нефункциональные требования. Скорость работы, безопасность и доступность приложения, требования к локализации и интернационализации, особые пожелания (например, поиск по каталогу интернет-магазина не дольше двух секунд). Эти и другие требования важно выяснить на этапе планирования, чтобы понимать бюджет, состав команды и части приложения, к которым будут выдвинуты самые строгие требования. Это поможет обезопасить команду после выхода в продакшн: на вопросы и претензии заказчика будете отвечать конкретными документами.
Как правило, нефункциональные дефекты очень дорогие в исправлении. Обращайте внимание на необходимые клиенту производительность, доступность, безопасность.
Вопрос № 3: Тестовые данные
Этот вопрос, увы, часто задают слишком поздно, уже перед самым тестированием. Но что делать, если заказчик не может предоставить необходимую информацию так быстро? Скажем, большие объемы данных надо специально сгенерировать для вас, сделать их максимально похожими на те, которые будут использоваться в продакшене, и заодно замаскировать личную информацию пользователей (номера паспортов, страховки, водительских прав и тому подобное).
Важность этого вопроса я прочувствовал на своем опыте. Однажды запросил тестовые данные за месяц до непосредственного тестирования. Но на их подготовку потребовалось два с половиной месяца, это заблокировало часть работы и, как вы понимаете, никого не обрадовало. Оказалось, что у этого клиента никогда не возникало подобных запросов, потому службе поддержки пришлось строить процесс генерации тестовых данных практически с нуля.
Вопрос № 4: Конечные пользователи
Этот момент может ощутимо повлиять на ваше приложение. Например, у вас специфическое решение, созданное для людей, которые знакомы с его ранней версией. Для них подсказки по использованию могут быть излишними, они уже знают, какая функция и для чего нужна. А вот если уровень пользователей разный, то подсказками и инструкцией пренебрегать не стоит. И это тоже дополнительная работа для команды тестирования.
Кроме того, если приложение будет доступно пользователям из разных стран, надо проверить, какие требования есть на законодательном уровне (например, приложение должно быть доступным для пользователей с ограничениями по зрению или слуху). Важно понимать и то, на каких устройствах люди будут использовать ваш продукт.
Некоторые сервисы, такие как StatCounter или Google Analytics, позволяют получить эту статистику в зависимости от географии. Это поможет сфокусировать усилия команды тестирования и не распыляться на ненужные версии. Скажем, 90% процентов наших юзеров использует
Вопрос № 5: Устройства для тестирования
Этот вопрос становится ребром на середине процесса разработки. Часто, если под рукой нет нужного устройства, можно купить его или просто написать письмо на другие отделы и одолжить девайс ненадолго. Но бывают исключительные ситуации.
Однажды мы делали проект для крупной киностудии. Пробы актеров ее сотрудники записывали на профессиональные камеры, видео с них должны были конвертироваться с помощью специального устройства и только потом попадать в наше приложение. Найти этот конвертирующий девайс в Украине на тот момент было невозможно. О его важности для тестирования мы узнали за пару дней до завершения разработки, а потом еще месяц ждали, пока устройство дойдет от клиента до нас. Это повлияло на сроки. Потому, когда пишете тест-план, задумывайтесь, какие устройства понадобятся, и обсуждайте заранее с проектным менеджером и клиентом, удастся ли обойтись эмуляторами или все-таки надо приобрести нужный девайс заранее.
Вопрос № 6: Ограничения со стороны клиента
Выясните, какие процессы в компании клиента отличаются от ваших. Возможно, вы узнаете об ограничениях в инструментах тестирования. В моей практике был случай, когда у заказчика был определенный набор софта и библиотек для автоматизации. Это внесло коррективы в расписание, потому что нашим тестировщикам надо было изучить некоторые с нуля. Из-за того, что мы не обсудили этот момент на старте, ситуация повлекла за собой переработки. Теперь задаем вопрос об ограничениях всегда.
Вопрос № 7: UAT/Beta-тестирование
На одном из финальных этапов продукт важно показать небольшой группе пользователей или тестировщикам клиента. Иногда для этого необходима специальная документация. Помню, как один заказчик решил провести UAT-тестирование со своей командой и попросил наши тест-кейсы. Однако изначально мы это не оговаривали, поэтому тест-кейсы были высокоуровневыми. Для нас информации было достаточно, некоторые вещи мы воспринимали как само собой разумеющиеся, а вот клиенту не хватало деталей. В итоге пришлось в авральном режиме дорабатывать документацию. Снова же: это переросло в опыт. Теперь на этапе создания тест-плана мы уточняем уровень детализации тест-кейсов.
Вопрос № 8: Аудит со стороны заказчика
У некоторых заказчиков есть свой отдел QA, и однажды он может прийти к вам с аудитом. Уточните на старте проекта, какие требования к документации выдвигает клиент, есть ли у него шаблоны. Это поможет вам не только удовлетворить свои потребности в документации, но и избежать инцидентов с несоответствием стандартам.
В заключении напомню, что тест-план — это динамический документ. Он требует регулярного обновления и наверняка пригодится на долгоиграющем проекте. Если у вас есть собственные рекомендации к составлению качественного тест-плана, делитесь в комментариях. Буду рад обмену опытом!
Чтобы не пропустить новые статьи Юрия Бабая — подпишитесь на него в телеграм-боте Ленты DOU.
