Заказчик из США обратился к компании a1qa с просьбой провести полный цикл тестирования системы. Продукт представлял собой масштабную SaaS ERP-систему, позволяющую управлять всеми процессами по предоставлению субсидированного жилья:

• подача и рассмотрение заявок, проверка необходимых условий для предоставления субсидированного жилья;
• управление заселением/выселением жильцов, инспектирование состояния жилища;
• распределение задач, нотификации, планирование рабочего времени.

Заказчик стремился достичь следующих целей:

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

Для обеспечения качества всех процессов системы специалистами a1qa был подобран индивидуальный комплекс услуг по тестированию (тестирование полного цикла), учитывающий планы по выпуску продукта на рынок, а также специфику продукта и пользовательской аудитории.

Различные виды тестирования проводились в разное время, в зависимости от текущего этапа разработки. Так, на стадии активного роста функциональности специалисты a1qa проводили функциональное тестирование, параллельно с работой по проверке производительности и автоматизацией тестирования.

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

Перед релизом продукта были проведены end-to-end тесты, которые помогли оценить, насколько система в целом готова к выходу на рынок.

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

Для эффективной работы была внедрена матрица тест-кейсов (Test Cases Matrix), которая дала возможность:

• убедиться, что все требования к системе покрываются тест-кейсами;
• объединить несколько проверок и тем самым уменьшить количество тест-кейсов в несколько раз.

Разработка системы сопровождалась изменениями функциональности, которые требовали обновлений тест-кейсов. Для того чтобы QA-инженер не тратил много времени на выбор тест-кейсов, которых коснулись изменения, было решено использовать матрицу компонента (Component Matrix).

Матрица компонента включает матрицы тест-кейсов по компоненту (модулю) системы.

При разработке новой функциональности матрица тест-кейсов добавлялась к соответствующей матрице компонента.

Разработка технической документации

Заказчик обратился к команде технических писателей a1qa для создания и обновления обширного пакета справочной документации. Документы должны были учитывать различные особенности системы и описывать всю функциональность.

Команда технических писателей a1qa выполнила следующие задачи:

• создание контекстно-зависимой справки;
• разработка инструкций «How-To» и FAQ-страниц;
• разработка документации для обучающих тренингов.

За время проекта техническими писателями a1qa было подготовлено свыше 90 документов, насчитывающих 1000+ страниц.

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

Приемочное тестирование (UAT)

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

Трудности:

• большое количество времени на подготовку сценариев приемочного тестирования;
• необходимость изменения/создания тестовых сценариев для каждого UAT.

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

Решение:

QA-командой был разработан новый подход к написанию сценариев для приемочного тестирования. Было решено создать UAT-сценарии, описывающие основные действия пользователей, а для новой функциональности — использовать тест-кейсы, ранее созданные для тестирования пользовательских требований.

Таким образом, подготовка к приемочному тестированию была сведена к выбору соответствующих тест-кейсов. Впоследствии все QSC-тесты и BAS (Business Analysts Scenarios) были автоматизированы. Поведение каждой функции описывалось бизнес-аналитиками в BAS. QA-команда дополняла их и передавала команде по автоматизации. Каждая тестируемая функция имела, по крайней мере, один автотест, что помогло сэкономить 3 часа на тестирование каждой функции в рамках UAT.

Переход ОТ Scrum К SAFe

Первоначально разработка на проекте велась по методологии Scrum. Но после нескольких лет было решено перейти на Scaled Agile Framework (SAFe). SAFe нацелен на большие компании и позволяет более эффективно управлять разработкой программного обеспечения, в том числе проектами, включающими несколько команд.

Команде a1qa требовалось глубже понять основополагающие ценности и принципы разработки по SAFe.

Самым очевидным преимуществом перехода на SAFe стали согласованная работа всех команд и быстрая доставка конечного продукта.

Тестовые метрики

По согласованию с заказчиком QA-инженеры отслеживали динамику выбранных метрик.

Пример:

Пояснение:

Rejected,% (отклоненных) дефектов от общего числа всех проверенных дефектов.

Качество исправления дефектов:

• 0% — 3.9% переоткрытых -> высокое;
• 4% — 9.9% переоткрытых -> среднее;
• 10% и более переоткрытых -> низкое.

Цель-<10% от всех исправленных дефектов.

Дефекты спринта по степени критичности (Sprint defects by Severity) – количество всех дефектов, связанных с пользовательскими требованиями текущего спринта, ранжированное по степени критичности. Количество открытых дефектов указано в скобках.

QA-команда

Изначально на проекте была задействована одна QA-команда (2 инженера и 1 руководитель команды).

К 2014 году обеспечением качества занимались 7 команд, включавших координатора проекта, менеджера проекта, руководителей групп, инженеров по тестированию, инженеров по автоматизации тестирования, команду по тестированию производительности, технических писателей и экспертов по UX.

Перед завершением проекта было проведено масштабирование команды до трех специалистов a1qa, которые занимались поддержкой продукта, валидируя дефекты и тестируя дополнительную функциональность, разработанную по требованиям пользователей. 

Вклад a1qa

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

За время проведения тестирования было зарегистрировано более 12000 серьезных и критических дефектов, которые были успешно исправлены. 

Команда a1qa обеспечила качественную миграцию на новую ERP-систему.

Специалисты a1qa провели ряд обучающих мероприятий для сотрудников клиента, а менеджеры со стороны a1qa консультировали заказчика при найме новых QA-инженеров.

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

Все цели проекта были своевременно достигнуты, и продукт был успешно выпущен на рынок в срок.