Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Но как добиться того, чтобы за качество отвечала вся команда? Один из способов – это создание стратегии качества. Стратегия качества – это документ, с которым согласна вся команда. Это контракт, описывающий, как будет разрабатываться, тестироваться и выпускаться качественное ПО. В этой статье я обсужу ряд вопросов, на которые нужно дать ответы, создавая стратегию качества.

Создание и груминг сторис

Как команда решает, над какими сторис работать? Это может быть решение всей команды, или только менеджера продукта. Или же за приоритезацию отвечает человек, не включенный в команду.

Кто занимается грумингом для подготовки сторис к разработке? Это может быть команда или часть команды. В идеале в груминге должны участвовать как минимум менеджер продукта, разработчик и тестировщик.

Процесс разработки

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

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

Передача фич в тестирование

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

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

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

Создание тест-плана

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

Кто будет писать автотесты? В некоторых командах разработчики пишут юнит-тесты, а тестировщики пишут API и UI-тесты. В других коллективах разработчики пишут юнит и API-тесты, а тестировщики – UI-тесты. Даже лучше, если и разработчики, и тестировщики отвечают за создание и поддержку API и UI-тестов. В этом случае разработчики могут поделиться своим опытом в управлении кодом, а тестировщики – опытом в понимании, что нужно тестировать.

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

Тест-инструменты

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

Поддержка тестов

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

Баги и технический долг

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

Как команда решает вопрос технического долга? Есть ли у команды соглашение об отдаче определенной части технического долга в ходе спринта? У некоторых команд есть политика, при которой разработчик, которому не над чем работать, берет задачи по долгу из бэклога.

Релизы

Какое тестирование будет проводиться до релиза? Будет ли план регрессионного тестирования, который выполняет вся команда? Что насчет исследовательского тестирования? Одна знакомая высокопроизводительная команда совместно проводит исследовательское тестирование прямо перед релизом. Используя такой подход, они находят заковыристые баги и исправляют их до того, как они попадут в прод.

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

Поддержка

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

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

Обсудить в форуме