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

ОПИСАНИЕ ПРОЕКТА

ОПИСАНИЕ ПРОДУКТА

Заказчик из США обратился к компании 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-команд позволили эффективно распределять решение задач, а также решать рабочие вопросы.

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

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

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

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

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

ПРЕДОСТАВЛЕННЫЕ СЕРВИСЫ
  • Автоматизация тестирования
  • Функциональное тестирование
  • Кросс-браузерное тестирование
  • Тестирование локализации
  • Юзабилити-тестирование
  • Тестирование производительности
ТЕХНОЛОГИИ И ИНСТРУМЕНТЫ
  • .NET
  • KendoUI
  • ASP.NET
  • Azure
  • VSTests
  • NLog
  • Autofac
  • MVC
  • Thinktecture Identity Server
  • Entity Framework
  • WCF
  • MSSQL (SSRS, SSIS)
ТРУДНОСТИ И РЕШЕНИЯ

1. Поддержка свыше 30 тысяч тест-кейсов:

  • Использованы матрицы тест-кейсов, которые помогали заменять несколько проверок одним тест-кейсом. Это способствовало сокращению числа тест-кейсов.
  • Разработана матрица компонентов, содержащая все матрицы тест-кейсов с кейсами по соответствующему компоненту (модулю) системы.
  • Добавлено поле «Программа». В нем указывались виды программ, в рамках которых агентство по жилищным вопросам взаимодействовало со своими клиентами, и к которым относилась проверка.
  • Введен шаг «Повторить». К примеру, если два тест-кейса отличались всего одним шагом, создавался только один кейс. К нему добавлялся шаг, которым они отличались. В результате команда получала один тест-кейс вместо двух.

2. Большой объем регрессионного тестирования:

  • Все активности в текущем спринте были приостановлены, и QA-команды переключились на тестирование “KendoUI+IE11”, в то время как команда разработки занималась техническими задачами и исправлением дефектов. Благодаря параллельно выполняемому тестированию удалось сэкономить около 100 часов. Тестирование было завершено в течение двух недель, и QA-команды вернулись к своим обязанностям по спринту.

3. Тестирование в двух ветках:

  • Изначально тестирование проводилось в двух ветках, но после анализа результатов было установлено, что большинство проблем воспроизводится в обеих ветках. Поэтому было решено сократить объем тестирования в ветке с будущим релизом и проводить полный цикл тестирования в ветке с текущим релизом.

4. Коммуникация с командой разработки и бизнес-аналитиками:

  • QA-команда создала страницу «Questions & Answers», на которой размещались все вопросы от QA-инженеров и разработчиков, а также ответы на эти вопросы от бизнес-аналитиков. Данные страницы представляли собой дополнительные типы требований. Бизнес-аналитики также были добавлены в командный онлайн-чат. Так каждый член команды мог принимать активное участие в обсуждении вопросов.
РЕЗУЛЬТАТЫ
В ЦИФРАХ
  • 5+
    лет продолжительность проекта
  • 12114
    важных и критических дефектов обнаружено
  • 100%
    выполнение сроков и бюджета проекта