Управление тестированием

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

Наш проект представляет собой систему дистанционного обучения (LMS, Learning Management System), которой пользуются более 7 миллионов человек в разных странах мира. В системе 1000+ веб-страниц и порядка 10 000 тест-кейсов.

Сейчас в проекте работает около 15 команд разработки со стороны заказчика в Норвегии и со стороны Аркадии в России. Я присоединилась к проекту 8 лет назад в качестве QA; последние 2 года я работаю в качестве QA lead, участвуя в оптимизации процесса тестирования.

Что входит в понятие оптимального процесса

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

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

Процесс разработки в целом:

a) Подход к разработке, удовлетворяющий нужды команды
Мы работаем, используя Scrum и спринты продолжительностью 3 недели. Перед спринтом проходит презентация его целей и формируется набор требований для данного спринта. Далее идет планирование, на котором мы оцениваем все задачи и определяем набор задач, который войдет в спринт. По окончании спринта проходит Sprint review, на котором мы демонстрируем все выполненные задачи и анонсируем достигнутые цели. Такой подход для нас является оптимальным: за спринт мы успеваем сделать достаточное количество новой функциональности и при этом исправить и протестировать определенное количество багов от конечных пользователей на такие баги выделяется 10% времени спринта.

Состав команды: team lead, разработчики, тестировщики. Соотношение разработчиков к тестировщикам в наших командах 3:1. Такое соотношение дает возможность достигать цели спринта равномерно нет периодов, когда кто-то из участников процесса простаивает: пока разработчики делают какое-либо изменение, тестировщики создают или обновляют тест-кейсы, относящиеся к этому изменению; когда разработка закончена, тестировщики проверяют изменения, а разработчики либо переходят к следующим задачам спринта, либо помогают в тестировании (это бывает необходимо при тестировании масштабных изменений).
Product Owner определяет цели и требования в начале каждого спринта и принимает в конце. Также у каждой команды есть Scrum Master, который помогает решать возникающие проблемы.

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

b) Четкие требования и хорошее планирование
Для того, чтобы планирование не затянулось, а спринт не стал провальным из-за неизвестных ранее деталей и трудоемких дополнительных изменений, добавленных уже в процессе спринта, мы стараемся брать в спринт только изменения с достаточно ясными и четкими требованиями. Если область проекта, которая касается изменений, неизвестна команде, или в течение планирования возникает много вопросов, на которые Product Owner не может дать ответов, команда может взять в спринт задачу на изучение данной области либо задачу на исследование, результатом которого становятся четкие требования или даже некий прототип.

c) Ретроспективы
Работа над ошибками тоже важна. Это касается как спринтов, так и релизов. Случается, что мы что-то не успеваем, или приходится работать сверхурочно, чтобы успеть в срок например, при необходимости дотестировать релиз (а это дополнительные расходы, которых компании хотелось бы избежать в дальнейшем). Поэтому мы проводим ретроспективы, на которых обсуждается, что было хорошего и плохого в спринте или релизе, и вырабатываются меры для избежания таких ошибок в дальнейшем.

d) Поддержка со стороны менеджмента
Иногда возникают вопросы или ситуации, которые невозможно разрешить на уровне команды нужно менять процесс или привлекать к решению менеджмент компании. Очень важно видеть, что тебе хотят помочь и готовы поддержать в такой ситуации. У нас в компании с этим все хорошо это касается как Аркадии, так и менеджмента со стороны заказчика. Все вопросы обсуждаются и всегда находится решение, удовлетворяющее все стороны.

e) И, на мой взгляд, основополагающее это хорошая коммуникация. И то, что есть у нас в компании, для меня является одним из главных преимуществ комфортной работы доброжелательность, желание идти на компромиссы.
Это касается всех: и каждого члена команды, и Product Owner, и Scrum Master, и менеджмента компании, и многих других участников процесса. Все открыты для вопросов и обсуждений, разработчики советуются с тестировщиками в вопросах требований и вместе решают, как лучше (и с точки зрения разработки, и с точки зрения тестирования) сделать то или иное изменение. Product Owner, в свою очередь, постоянно на связи с командой, оперативно решает все вопросы и всегда старается идти навстречу в достижении целей спринта. Scrum Master всегда готов помочь: найти дополнительные ресурсы (тестировщиков/разработчиков, если они требуются для спринта или для релиза) или подсказать, как лучше организовать спринт по времени.

Процесс тестирования:

a) QA-стандарты (guidelines), относящиеся к написанию тест-кейсов.
У нас в проекте тест-кейсы являются основной детальной документацией по функционалу системы, поэтому им уделяется большое внимание. Для каждого изменения, сделанного командой, пишется новый тест-кейс или обновляется уже существующий.
Раньше, когда система была еще не такой огромной, тест-кейсы писались достаточно детальные, с различными конкретизированными шагами, но сейчас этот подход стал неприемлем на обновление таких тест-кейсов уходит очень много времени. Поэтому мы (QA leads) разработали стандарты, основным требованием которых является написание сценариев тестирования с ожидаемыми результатами вместо детально расписанных шагов в тест-кейсах.

b) QA-стандарты, относящиеся к тестированию в спринтах.
Чтобы каждая команда обеспечивала хорошее качество сделанных изменений, были разработаны стандарты тестирования в спринте.
Основа этих стандартов максимальное покрытие тестированием, куда входит:
Тестирование непосредственно сделанного командой изменения (функционал и при необходимости UI);
Тестирование системы после этого изменения с использованием чек-листа: это обязательные проверки, к которым относятся тестирование доступности для людей с ограниченными возможностями, проверка переводов, проверка существующих данных, тестирование с использованием специальных символов, проверки безопасности, тестирование изменений в мобильном приложении и другие проверки.

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

d) Использование автоматизированного регрессионного тестирования.
Создание автоматических тестов для регрессионного тестирования сильно облегчило жизнь команд теперь, если требуется проверить какую-то область после командных изменений, можно просто запустить регрессионные автотесты для нужной области системы (если данная область покрыта автотестами). Также, если какая-то часть системы была сломана изменениями команды, регрессионные автотесты это выявят.

e) Взаимовыручка тестировщиков, помощь разработчиков.
У нас не очень много тестировщиков (в среднем 1 тестировщик на 3 разработчиков), к тому же время от времени они отвлекаются от задач спринта на тестирование релизов, и времени на всё может не хватать.
В таком случае всегда находится кто-то из тестировщиков других команд с меньшей нагрузкой в текущий момент, кто может помочь. Найти такого тестировщика помогает QA lead или Scrum Master. Кроме того, разработчики могут помочь с тестированием изменений в спринте, если по ним уже написаны тест-кейсы.

f) Коммуникация между тестировщиками.
Для коммуникации используется чат в Microsoft Teams, в котором каждый может задавать вопросы и оперативно получать ответы, а остальные тестировщики при этом узнают актуальную информацию. Также у нас проходят ежемесячные QA-митинги, на которых тестировщики делятся друг с другом текущими задачами своей команды и могут обсуждать любые вопросы подход к тестированию и/или расположение тест-кейсов, касающихся незнакомой для тестировщика области; вопросы по релизу (состав будущей релизной команды, изменение сроков тестирования); дополнительные обязательные проверки, добавленные после пропуска критичного бага в релизе, и т.д.).

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

Чем хороши ежемесячные релизы и как мы к ним пришли: организация процесса тестирования во время релиза

Раньше у нас были квартальные релизы. При таких временных рамках к каждому релизу скапливалось достаточно много изменений, которые были сделаны командами. Такой объем изменений, безусловно, требовал регрессию перед релизом, поэтому для регрессии выделялся отдельный период времени, и к ней подключались все команды. Обычно это занимало около 2 недель, и в регрессии участвовали как тестировщики, так и разработчики команд.

Через какое-то время для регрессии в процессе тестирования релиза стали использоваться автотесты. Не все тесты для регрессии были покрыты автотестами, что-то тестировалось вручную. В целом это сократило время тестирования регрессии, но из-за объемов системы полная регрессия все еще занимала много времени.

Весь цикл разработки выглядел примерно так:

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

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

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

Стабилизация включает в себя:

a) тестирование нового функционала, включенного в данный релиз каждой командой;
b) тестирование критичных областей это проверка основной функциональности главных областей системы (что, очевидно, занимает гораздо меньше времени, чем полный цикл регрессии);
c) тестирование багов, найденных в командных изменениях для данного релиза.

Весь цикл разработки теперь выглядит так:

Рассмотрим, что еще необходимо для подготовки к релизу.

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

Можно подумать, что 2 недели подготовки к релизу это слишком много, и на тестирование в спринте остаётся мало времени. Но обычно у тестировщика подготовка к релизу занимает 4-6 дней. Это зависит от:

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

Все тестировщики проекта (включая релизную команду) участвуют в тестировании стабилизации; тестирование конфигурации и непосредственно самого релиза делает только релизная команда.

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

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

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

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

И конечно, ни один релиз не обходится без возникающих проблем. Мы их решаем и разрабатываем план, как избежать их в дальнейшем. Вот некоторые, с которыми мы сталкивались в последнее время:

Проблема: иногда команды добавляют свои изменения в релиз в последний момент перед началом стабилизации, из-за этого стабилизация начинается позже, и обычно такие изменения содержат баги, потому что из-за спешки их могли не очень тщательно протестировать в спринте.
Решение: стараемся избегать добавления таких опасных изменений.
Проблема: баги находятся на этапе тестирования конфигурации на pre-production окружении. Это слишком поздно приходится исправлять и пересобирать релизный пакет.
Решение: после таких ситуаций мы обновляем критичные области на стабилизации.
Проблема: увеличение времени на тестирование релиза, что может быть причиной сдвига даты релиза.
Причинами увеличения времени могут быть следующие факторы:
a) сдвиг релиза в целом по каким-то веским причинам и тем самым больший объем командных изменений в релизе (время между релизами не месяц, а несколько месяцев),
b) нестабильная работа окружения для тестирования стабилизации или конфигурации,
c) конфигурационные баги окружения,
d) большое количество нетривиальных багов команды, найденных на стабилизации. Как правило, это интеграционные баги, связанные с изменением одной области разными командами.
Решение: в таких случаях мы стараемся успеть протестировать всё необходимое для релиза, даже если это требует участия в релизе все 2 недели или сверхурочную работу, так как релиз является более приоритетной задачей, чем задачи спринта.

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

Работа в условиях карантина: как обеспечить работу тестировщиков

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

В период пандемии, когда и Норвегия, и Россия отправили большинство населения на самоизоляцию, нам пришлось перейти на удаленную работу.

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

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

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

Единственная проблема, с которой мы столкнулись, сидя дома на удаленной работе в силу особенностей VPN невозможно было тестировать систему на командном окружении с телефонов/планшетов. Но эту проблему удалось обойти спасибо менеджеру проекта и IT-службе, которые нашли решение. Мы стали использовать прокси при подключении по домашней сети, и теперь можем тестировать на мобильных устройствах из дома.

Сейчас мы частично возвращаемся к работе в офисе, но часть компании продолжает работать из дома. И даже находясь в разных частях города, мы всё так же остаемся единой сплоченной компанией, которая продолжает работать в такое нелегкое время, с такими нерабочими условиями, когда дети и домашние животные требуют внимания, интернет тормозит и периодически пропадает, свет выключается, и столько отвлекающих факторов, что вообще не понимаешь, как же получилось в очередной раз поработать?!

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

Заключение

Подводя итог вышесказанному, хочется отметить несколько моментов:

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