Многие IT-компании до сих пор придерживаются традиционного цикла разработки программного обеспечения. Организации отдают больший приоритет реализации, чем проектированию и редко рассматривают вопросы качества приложения или продукта. Но что такое качественное приложение? В чем разница между компаниями, ориентированными на качество, и компаниями, нацеленными на конечный продукт?

Тренд на качество

Мы отошли от традиционных жизненных циклов разработки программного обеспечения, таких как модель Waterfall, и адаптировали гибкие методологии Agile и Scrum. У нас есть программа или патчи, которые выпускаются каждый день. Спринт изменился по продолжительности с нескольких месяцев на 2 недели. Требования часто меняются, и нам приходится адаптироваться к ним.

Но с таким большим количеством инноваций в дизайне, улучшениях пользовательского интерфейса, сотнями настроек A/B-тестов, множеством пользовательских интервью и наблюдений за взаимодействием пользователей с продуктом, а также постоянным изменением историй — как убедиться, что мы строим правильные вещи? (валидация). И как нам убедиться, что мы строим все правильно? (верификация).

Эта волна нового жизненного цикла программного обеспечения (Software Development Life Cycle, SDLC) вызвала у организаций необходимость адаптировать новый жизненный цикл тестирования (Software Testing Life Cycle, STLC). Но что изменилось на самом деле?

Shift Left

Shift Left — это подход в тестировании, при котором QA подключается к работе на самых ранних стадиях разработки и начинает тестировать продукт еще на уровне самой идеи. Источник: van der Cruijsen 2017

Подход Shift Left несет в себе следующие преимущества по сравнению с обычными моделями тестирования:

• Вовлечение команды QA на ранних этапах SDLC. Это означает, что тестировщики получают право голоса во время обсуждения изменений в дизайне и паттернов взаимодействия с пользователем.

• Определение и устранение серьезных ошибок происходит еще до создания приложения.

• Команда QA больше сотрудничает с продакт-менеджерами, инженерами, скрам-мастерами, дизайнерами продуктов, разработчиками, а иногда даже с юридическим отделом и отделом продаж.

• Команда QA тратит достаточно времени на разработку и определение критериев приемки до начала разработки, продвигая BDD.

• Команда QA имеет право голоса на различных скрам-митингах (груминг, планирование спринта) а также во время обработки обратной связи, которая собирается в ретроспективе спринта.

• В технической сфере есть много популярных выражений, среди которых «Качество — это ответственность каждого». Подход Shift Left поддерживает этот девиз.

BDD (Behavior Driven Development)

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

Разработчик, тестировщик и продакт-менеджер часто участвуют в разработке, основанной на поведении (могут быть вовлечены и другие заинтересованные стороны). Группа собирается вместе на мозговой штурм, на котором обсуждают реальные примеры критериев приемки в пользовательских историях. Эти примеры описываются в фича-файле с использованием предметно-ориентированного языка, такого как Gherkin. Фича-файл преобразуется в исполняемую спецификацию, из которой разработчики могут создать исполняемый тест.

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

Преимущества BDD:

• Тесное сотрудничество членов команды: владельцы продуктов, разработчики и тестировщики имеют полное представление о ходе проекта.

• Высокая степень наглядности: поскольку это нетехнический процесс, BDD может охватить гораздо более широкую аудиторию.

• Быстрая итерация: BDD помогает быстро реагировать на любую обратную связь от пользователей, что позволяет оперативно вносить улучшения в соответствии с их потребностями.

• Фокус на потребностях пользователей: удовлетворенность пользователей выгодна бизнесу, а метод BDD позволяет удовлетворять потребности пользователей посредством разработки программного обеспечения.

• Достижение бизнес-целей: каждый этап разработки может быть быстро сопоставлен с фактическими бизнес-целями с помощью BDD.

Как BDD выглядит в реальной жизни?

Фича: Поиск в Google    
  Как активный пользователь интернета, я хочу использовать Google, 
  чтобы узнавать что-то новое

  Сценарий: простой поиск в Google        
    Исходное состояние: браузер со страницей Google        
    При вводе фразы «панда» в поисковую строку        
    Отображаются результаты для «панда»

Что пошло не так? Почему организации не готовы перенять современные практики обеспечения качества?

Ниже я попытался рассмотреть несколько существенных моментов, которые я отметил, работая с клиентами и организациями.

Отсутствие QA лидера в организации

Некоторые компании не инвестируют в независимую команду QA.

Однако независимая команда QA с сильным руководителем имеет много преимуществ:

1. QA имеет свой собственный голос.

2. Команда QA может создавать глобальные практики обеспечения качества для нескольких продуктов или предложений, а также для различных окружений (Android, iOS, веб и т.д.)

3. Команда QA может разрабатывать общие инструменты и технологии для автоматизации и настройки CI/CD-пайплайнов.

4. Команда QA может писать отчеты и требования к статическому тестированию качества.

Этот список можно продолжать и дальше. Но это одни из самых важных задач, над которыми команда QA должна работать независимо от разработчиков, продакт-менеджеров и команды проектирования.

Установка, согласно которой разработчики несут ответственность за комплексный контроль качества

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

1. Как правило, разработчики обладают складом ума, направленным на созидание. Изначально им трудно что-то ломать, поэтому со временем у них развивается другой тип мышления, направленный на то, чтобы «ломать вещи».

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

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

Лидеры не хотят инвестировать в качество

В крупных компаниях часто можно услышать, что контроль качества — это обязанность каждого. Я полностью согласен. Так и есть. Но только после того, как приложение (после разработки каждой фичи и второстепенного/основного релиза) прошло через несколько регрессионных тестов и пробных запусков.

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

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

Недостаточно времени для инвестиций в технологии автоматизации

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

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

Если компания не инвестировала в автоматизацию и подход CI/CD к созданию, тестированию и релизу продукта, еще не поздно начать это делать прямо сейчас. Начинайте с малого, но начните.

Баланс между ручным и автоматизированным тестированием

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

Другие организации считают, что ключом к успеху является 100% автоматизация и что автоматизировать можно все. Но это неправда — ручные и другие интеграционные тесты так же важны, как и автоматизированное тестирование. Следует найти баланс между требованиями, подпадающими под ручное и автоматизированное тестирование.

Вклад команды QA часто недооценивают

В некоторых компаниях процесс контроля качества налажен. У них хороший охват тестовых сценариев и настройка процесса в CI/CD пайплайне. Но им может не хватать более активного взаимодействия внутри команды, из-за чего другие члены команды могут не понимать в полной мере вклад QA.

Отсутствие отчетности и обратной связи

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

Отсутствие полноценного пайплайна CI/CD

Самая важная часть QA — это, конечно же, само тестирование, но также важно организовать процессы для беспроблемного релиза фичей. Бывают случаи, когда фреймворк автоматизации не синхронизируется с пайплайнами CI/CD для запуска тестов после слияния чего-либо с основной веткой или подобных проверок, если это необходимо. Большинство платформ (например, Jenkins) дают возможность отправлять отчеты по электронной почте или в слаке. Это помогает повысить осведомленность и держать всех в курсе, если происходят какие-либо критические изменения.

Отсутствие интеграции тест-кейсов с Jira

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

Фокус на одном аспекте качества

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

• Тестирование пользовательского интерфейса (Web, Mobile, TV и т. д.)

• Тестирование API

• Тестирование производительности

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

• Тестирование БД

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

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

В заключение приглашаем всех желающих на открытое занятие по методам тестирования требований. На этом уроке:

• Изучим конкретные практики тестирования требований.

• Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований.

• Рассмотрим, как выстраивается процесс тестирования требований в Agile командах.

Зарегистрироваться можно по ссылке.