Тем, кто пропустил наш
пост на прошлой неделе, напомним, что команда «Точка качества» более двух лет занималась тестированием новой платежной системы для крупного банка. На проекте не было ничего необычного до тех пор, пока заказчик не поставил перед нашей командой задачу провести демонстрацию первого релиза, или приемо-сдаточные испытания (ПСИ).
Наша команда прекрасно знала продукт, поэтому с радостью согласилась, хотя задача и требовала изучения ряда специфичных вопросов. И в сегодняшней статье мы рассказываем, как готовились к испытаниям, как вырабатывали эффективный подход и демонстрировали реализацию всех требований.
Подготовка к приемо-сдаточным испытаниям
Представители бизнеса и IT по-разному смотрят на разрабатываемый продукт. И в этом заключалась суть первой проблемы. Бизнесу важно, чтобы все процессы, заложенные в систему, функционировали корректно от начала и до конца. Наша же команда – функциональных тестировщиков – разбивала процессы на мелкие блоки и тестировала каждый блок в отдельности и очень подробно, но теряя порой из виду картинку в целом.
Второй проблемой стало отсутствие четкой привязки тест-кейсов к бизнес-требованиями. Тест-кейсы были подготовлены на основе технической документации, которую разработали системные аналитики и архитекторы.
Поэтому нам предстояло выработать подход, который помог бы продемонстрировать бизнесу ожидаемый результат.
Наш подход к демонстрации первого релиза
Для первого релиза были выставлены весьма лояльные критерии успешности приемки:
- Реализация 30% требований;
- Pass-rate – 80%;
- Отсутствие критических дефектов в реализованной функциональности.
Учитывая эти критерии, небольшое количество требований, заявленных на демонстрацию (порядка 180) и отсутствие реализации на тот момент в продукте законченных бизнес-процессов (первый релиз предполагал реализацию лишь некоторых модулей) мы решились использовать следующий подход:
- Отобрали реализованные пункты требований, которые требовалось продемонстрировать.
- Для каждого требования написали один или несколько тест-кейсов, направленных на демонстрацию именно этого требования.
- Все тест-кейсы оформили в отдельный Excel-документ, который добавили в качестве приложения к документу «Программа и методика испытаний» (ПиМИ).
Каждый тест-кейс, закрепленный за требованием, представлял собой стандартный тест-кейс с указанием тестовых данных, предусловия, подробного описания шагов и результатов. Особое внимание мы уделили описанию цели тест-кейса и постарались максимально четко описать, что именно проверяем и как это связанно с реализованным требованием.
Таким образом, реализация каждого требования демонстрировалась тем или иным сценарием, а корректность реализации подтверждалась прохождением соответствующего тест-кейса.
Как проходили приемо-сдаточные испытания
Со стороны исполнителя (разработчика продукта) на приемо-сдаточных испытаниях присутствовали несколько человек, но защищать продукт и проводить непосредственную демонстрацию по тест-кейсам доверили специалистам компании «Точка качества».
Комиссия состояла из 10 человек – представителей топ-менеджмента и обычных сотрудников, которым в будущем предстояло управлять платежной системой.
Техническое оснащение приемо-сдаточных испытаний было достаточно простым: проектор, на который выводилась информация по тестируемому продукту, монитор для отображения «Программы и методики испытаний».
Процесс был организован следующим образом: зачитываем проверяемое требование, рассказываем, как будем проверять и проверяем, максимально подробно комментируя свои действия. Результат каждой проверки протоколируется. По ходу проверки было много вопросов, замечаний, предложений по улучшению. Все это фиксировалось, на вопросы давались ответы. Если ответить не могли, вопрос протоколировался и передавался на последующий анализ ответственным людям. Все 230 тест-кейсов были пройдены успешно, а значит и все 180 требований реализованы корректно. Защита первого релиза состоялась.
Однако расслабляться было рано. Впереди у нас было еще два релиза, и подготовку к следующим ПСИ желательно было начать как можно раньше. Тем более что у нас была масса идей, что можно улучшить, чтобы превзойти себя в следующий раз.
Новый релиз – новый подход
Главное, что нам предстояло доработать – это подход по составлению раздела «Методика испытаний». Почему не годился подход, который мы применяли для демонстрации первого релиза? Дело в том, что все проверки были разрознены и не показывали функционирование системы в целом, бизнес-процессы не были охвачены полностью. Из-за этого отсутствовало ощущение целостности системы.
И если при первом релизе процент реализованных требований был не так высок, то для демонстрации финального продукта нужно было подход изменить.
Кроме того, следовало поработать над языком, на котором были написаны тест-кейсы. Он подходил для функциональных тестировщиков и других ИТ-специалистов, которые знали детали технической имплементации системы, но не для представителей бизнеса. Поэтому перед нами стояла задача использовать терминологию из бизнес-требований и подготовить тестовые данные наиболее близкие к реальным.
Решение найдено
Было решено отделить тестовую документацию, которую мы использовали для функционального тестирования от той, по которой планировалось проведение ПСИ. Так появилась идея о подготовке отдельных сценариев для демонстрации системы через бизнес-процессы – Е2Е-сценарии. End-to-end сценарии позволяют проверить совокупность действий с использованием максимально реалистичных тестовых данных.
Естественно, есть проекты, на которых приемку можно проводить и по обычным тест-кейсам, однако это был не наш случай. В рамках нашего проекта Е2Е-сценарии выигрывали перед тест-кейсами за счет следующих факторов:
- Снижение количества выносимых на демонстрацию тестовых артефактов за счет группировки нескольких требований в один сценарий. Это позволяло продемонстрировать всю реализованную функциональность быстрее. К слову, на демонстрацию первого релиза ушло пять дней. И это при реализации всего 180 требований.
- Демонстрация продукта через законченные и полноценные бизнес-процессы, близкие к реальным сценариям работы с системой. Заказчик получил возможность ознакомиться с продуктом в условиях, приближенных к реальным.
Как составить идеальный бизнес-сценарий?
Бизнес-сценарии описывают, как бизнес будет взаимодействовать с разрабатываемым решением. Работая совместно с заказчиком, мы смогли выработать определенный подход к составлению сценариев, а также определились с перечнем требований к этому виду тестовой документации.
Собрав опыт предыдущих приемок и пожелания заказчика, удалось составить следующую структуру у тестового сценария:
Название. Краткое, но четкое название сценария, которое помогает быстро понять, о чем пойдет речь.
Цель. Максимально точное описание цели; что мы увидим, выполнив данный сценарий.
Описание. Здесь необходимо рассказать, как будет проходить сценарий, при этом обязательно пользоваться бизнес-терминологией.
Ограничения. На крупных проектах часто один из затрагиваемых модулей не реализован или реализован не полностью. Но это не повод не демонстрировать связанные с ним функции. Не работает генерация нотификаций определенного типа? Криво отображаются элементы интерфейса? Это некритично. Главное, что вам, тестировщикам, это известно, и баг уже добавлен в баг-трекинговую систему. Вот это и должно быть описано в разделе «Ограничения».
Описание тестовых данных. На нашем проекте был уместен этот раздел, так как при описании сценариев использовались различные технические тестовые данные, которые трудно было связать с бизнес-составляющей. Поэтому в данном разделе снова используем бизнес-терминологию и описываем, что значат единицы и ноли, внесенные в БД.
Соотнесение шагов и требований. Так как одна из целей ПиМИ – доказать реализацию требований, то необходимо указать, какие требования мы демонстрируем тем или иным сценарием.
Шаги сценария. Данный блок состоит из трех компонентов:
- Описание действия в бизнес-терминах. Технические термины тоже допустимы, но только как крайняя мера. Главное, чтобы заказчику было понятно, о чем вы говорите.
- Ожидаемый результат (опять-таки в бизнес-терминах).
- Способ проверки. Вот тут уже можем позволить себе использовать технический язык, чтобы описать с точки зрения технической имплементации то, что ранее было изложено в бизнес-терминах.
Заключение
Наша команда прошла долгий путь от тест-кейсов ПиМИ до полноценных бизнес-сценариев, которые продемонстрировали бизнесу функциональность новой платежной системы. Путь был трудным, но мы справились.
Подводя итог, отметим следующее:
- Не всякий тест-кейс годится для использования в ПиМИ.
- Научитесь писать E2E-сценарии — это повысит ценность вашей работы и сделает вас более востребованным специалистом.
- Не бойтесь браться за новые задачи. Ведь если мы будем делать только то, что умеем, мы никогда не станем лучше.
Всем удачи на проектах! Если остались вопросы, с радостью
ответим на них.
