Стратегия тестирования в условиях Scrum: зачем она нужна и как построить

Артем Безручко — QA Engineer в Depositphotos. В тестировании он уже 5 лет, занимается как автоматизацией, так и ручным тестированием. Как Артем пишет в своей статье на DOU.UA, ему давно хотелось вынести тему тестовой стратегии на суд широкой публики. В основу его текста легли методы и активности, используемые тестировщиками его команды. Материал будет полезен для представителей всех технических направлений, особенно для лидов и тех, кто пока лишь задумывается о том, как построить процесс тестирования в продуктовой компании.

Photo by JESHOOTS.COM on Unsplash

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

Мне очень нравится подход Майкла Болтона. Он утверждает, что есть проверки, а есть тестирование. Автоматизация выполняет проверки и получает бинарный результат, а тестирование — это процесс, позволяющий получить развёрнутую информацию о продукте. Многие инженеры пытаются завести у себя на проектах автотесты, не совсем понимая, зачем они им. Большинство тестировщиков стремятся уйти в автоматизацию не из-за пользы для текущего проекта, а просто потому, что модно. И это проблема. Рассмотрим же, что такое тестовая стратегия и как такой подход поможет проекту.

Cтатья основана на моём докладе на online-конференции QA fwdays’20.

Стратегия тестирования: что это и чем она отличается от тест-плана

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

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

Тестовая стратегия как раз и описывает план подхода к тестированию в цикле разработки ПО. (Медленно и вдумчиво перечитайте предыдущее предложение). Разработка по гибкой методологии Scrum циклична. На основе этого принципа и будет строиться наша стратегия. Если провести аналогии с реальной жизнью, то тест-план — это подробная карта маршрута через территорию, а тестовая стратегия — компас, указывающий направление.

С терминами разобрались. Осталось понять, в чем беда скрама.

Waterfall никто не отменял, или Как мы докатились до Scrum

Все знают: вначале был Waterfall. Громоздкий, неповоротливый, длинный. С кучей документации и огромной инерционностью. И вот на смену ему пришел Scrum — легкий, гибкий и простой — в паре с Agile-манифестом, обещавшим разработке и бизнесу стратегию win-win. Берем спринты, нарезаем фичи и реализуем их за короткий промежуток времени. Потом следуют демо, ретро — и все по новой. На первый взгляд, гениально и просто. Но давайте остановимся на минутку и подумаем.

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

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

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

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

Теперь главный вопрос: как отдел тестирования помогает решать эти проблемы с помощью тестовой стратегии?

Рассмотрим лепестковую диаграмму, которая наглядно иллюстрирует, как наша команда чередует основные активности. Эту диаграмму я называю «шестеренкой тестирования»:

На окружности изображены шесть двухнедельных спринтов (приблизительно 3 месяца), каждый из которых условно разбит на 3 сектора: начало (1S — 1MS), середину (1MS — 1ME) и конец (1ME — 1E). Обозначены также уровни QA, QC, Testing и переходы между ними в разных временных рамках.

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

Ремарка. В Украине границы между должностями и обязанностями QA, QC и Tester бессовестно размыты. Это вносит дополнительный хаос в и без того сложные процессы разработки. Если повезет, я напишу на эту тему отдельную статью.

У большинства команд бывают критические периоды, когда проблемы начинают сыпаться со всех сторон: баги пролазят на прод, тестовые окружения перестают быть стабильными и консистентными, количество flaky-тестов растет, спринты не закрываются. И ты вроде делаешь все, что надо, но результата не видно. В таком случае приходится принимать решение, как быть дальше: поменять компанию или проявить характер и вырваться из порочного круга. Мы остановились на последнем варианте. Наша команда на тот момент состояла из 11 человек: 2 Node.js разработчика, 1 Front-end, 5 PHP Back-end и 3 тестировщика.

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

Начало спринта

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

Пойти в разведку

Выбрать средние и большие задачи. Нацелиться на их анализ и тестирование требований. Что это значит? Для начала основательно вчитаться в описание. Сформировать личные тезисы и мнение по тикету. После этого пойти к разработчикам, которые реализуют задачи, (или написать им) и получить от них ответы на следующие вопросы:

1. Что будет реализовано в тикете?

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

Пример: «Добавить на главную страницу новый баннер с недорогим платежным планом за $X,XX» — изначально поставленная задача. Но с момента ее создания изменилось видение, и Product Owner написал разработчику — в обход таск-трекера и всей команды, — что баннер нужно отображать только для Украины. Для девелопера это мелочь, всего одна строка в конфиге, а для остальной команды — неочевидные требования.

2. Зачем это делается? Какова бизнес-цель?

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

3. Что будет задето этой задачей?

На первый взгляд, простой вопрос. Но ответ на него иногда вскрывает настолько неочевидные связи, что задавать его стоит в протокольном порядке. У нас был случай, когда при добавлении нового типа подписки переставала приходить рассылка, будучи соотнесенной с другими платежными планами. А в случае с баннером (см. пункт 1) была нарушена логика трекинга поведения пользователя.

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

4. С какими сложностями есть вероятность столкнуться при тестировании и эмуляции?

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

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

5. Согласовать критерий качества приемки задачи

Один из удивительных законов Мерфи применительно к разработке ПО формулируется так: «Все, что может быть понято двояко, будет понято двояко». Именно поэтому у нас инженеры проговаривают основные пункты приемки фичи, чтобы исключить возможные разночтения. Очень важно, чтобы сотрудники находились в одном контексте и имели единую систему координат и точку отсчета при работе над задачей.

6. Есть ли у разработчика пожелания и советы по тестированию задачи?

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

7. Подготовить альфа-версию чек-листа.

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

8. Проверить описание задачи в Jira и исправить или дополнить на основе полученной информации в вышеперечисленных пунктах

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

Закрыть долги

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

1. Кейсы, не записанные в TestLink или другой тест-трекер

Всегда найдется сьют, который следовало бы проапдейтить, или функционал, для которого не созданы тест-кейсы.

2. Несозданные тикеты на автотесты

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

3. Пропущенные статьи в Wiki

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

4. R&D

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

Середина спринта (тикеты непосредственно берутся в тестирование)

Рабочие дни идут, и вот таски планомерно заполняют столбик «Тестирование». Следующие действия качественно влияют на процесс, поэтому я настоятельно рекомендую именно такой порядок активностей.

Перед началом любых действий по задаче, которая требует тестирования, нужно перечитать описание и повторно переговорить с разработчиком (кратко). Цель — уточнить, одинаково ли все участники понимают задачу, а также убедиться, что ничего не изменилось, не встретились «подводные камни», которые внесли поправки.

Затем следует провести тест-дизайн, углубив анализ задачи на основе альфа-версии чек-листа, написанного ранее.

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

  • разбить объект на модули и логические составляющие;
  • обозначить связи с другими модулями системы;
  • выделить smoke-набор для TestLink/Wiki.

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

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

На техниках и подходах к ручному тестированию я останавливаться не буду. Надеюсь, все читатели прекрасно ими владеют.

Заведение отчетов об ошибках

Хочу обозначить два полезных момента:

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

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

По завершении тестирования тикета остается выделить кейсы для автотестов, оформить кейсы в TestLink и завести статью в Wiki.

Конец спринта

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

Назначенный человек оценивает работу в спринте по следующим пунктам:

  1. С какими проблемами столкнулись, как их решали?
  2. Что нового узнали о работе системы? Нужно ли это документировать?
  3. Какие новые фичи зарелизены? Нужно ли закрывать их автотестами?
  4. Формирование задач для отдела тестирования на основе предыдущих пунктов.

Активности над спринтами

В описанном выше режиме проходит неделя (спринт, месяц — подставим сюда любой временной отрезок). Гладкая и выверенная схема начинает сбоить. И это нормально, ибо нет ничего вечного. Самое время примерить роль QA в широком смысле этого слова.

На следующем планировании один человек из отдела тестирования берет на себя задачу под названием «Пересмотр тестовой стратегии».

Таск включает следующие разделы:

1. Анализ проделанной работы за квартал/полгода

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

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

2. А не глупости ли мы делаем?

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

3. Сбор метрик по команде и проблемам

В этом пункте источником информации выступает таск-трекер. Собираем численные показатели:

  1. Баги от пользователей, относящиеся к нашей команде.
  2. Баги от пользователей, относящиеся ко всей компании.
  3. Баги, найденные тестировщиками нашей команды.
  4. Задачи, назначенные на отдел тестирования.
  5. Задачи, выполненные отделом тестирования.

4. Укрепление положительных активностей

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

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

Вторая такая активность — создание расширения для Google Chrome, которое в пару кликов приводит тестового пользователя в состояние готовности к тестированию.

Обычно для создания предусловий требуется от 1 до 5 минут, а благодаря приложению это делается в 3-4 клика за 10 секунд. Вроде не так уж и много, но в течение дня это экономит от 30 минут до часа. При масштабировании на всех тестировщиков профит заметно ощутим.

5. Анализ сохраненных знаний, систематизация

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

Photo by Startaê Team on Unsplash

6. Чего не хватает отделу тестирования в целом?

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

Пример. Depositphotos использует много платежных систем для удобства пользователей по всему миру. Естественно, для Бразилии нужны одни провайдеры платежей, а для Канады — совсем другие. Налоги, которые платят пользователи в той или иной стране, записываются в отдельный налоговый сервис, а уже по нему компания предоставляет отчеты в соответствующие органы.

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

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

7. Пересмотр тестовой стратегии

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

8. Проверка знаний команды, выделение личных векторов развития

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

Результат применения тестовой стратегии

Что решает такой подход?

  1. Теряется минимум знаний о работе системы.
  2. Формализуются процессы и подходы. Снижается шанс любого сотрудника допустить ошибку.
  3. Понижается порог входа для нового сотрудника.
  4. Уменьшается bus-фактор.

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

Каждый 13-й баг находит пользователь (показатель >10 — хороший). Количество оформленных багов показывает тенденцию к уменьшению, а количество проблем пользователей стабильно. На основе этого можно предположить, что кастомеры находят проблемы спустя длительное время после релиза фичи. Уменьшение количества найденных багов говорит о том, что больше проблем выявляется на этапе анализа требований и более плотного взаимодействия разработки с тестированием. Ну, или это признак ухудшения работы команды тестирования.

Задачи, выполненные инженерами тестирования и назначенные на отдел

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

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

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

Выводы

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

Хочу дать несколько небольших советов тем, кто решит делать что-то подобное в своей команде.

Будьте последовательными

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

Будьте системными

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

Будьте профессиональными

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх