Качество — создание стратегии на 5

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

Но как сделать так, чтобы вся команда соответствовала качеству?

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

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

Создание и качество подготовки историй

Вопрос: Как команда решает, над какими историями работать?

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

Вопрос: Кто обрабатывает истории, чтобы подготовить их к разработке?

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

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

Вопрос: Как команда решает, кто над какой историей будет работать?

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

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

Вопрос: Как выглядит «Готово» для истории? Измеряется ли она соответствием всем критериям приемлемости в истории? Должен ли разработчик добавлять модульные тесты, прежде чем можно будет считать историю завершенной? Как узнать, что функция готова к тестированию?

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

Передача функций

Вопрос: Как история будет передана на тестирование?

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

Вопрос: Кто развертывает код в тестовой среде?

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

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

Вопрос: Кто будет проводить тестирование?

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

Создание плана тестирования

Вопрос: Кто будет создавать тест-планы? Как они будут созданы? Где будут храниться планы тестирования?

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

Что бы вы ни выбрали, это должно быть правильным для вашей команды и вашего продукта.

Вопрос: Кто будет писать автоматизацию тестирования?

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

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

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

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

Инструменты тестирования

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

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

Тестовое обслуживание

Вопрос: Кто отвечает за поддержание тестов?

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

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

Ошибки и технический долг

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

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

Вопрос: Как команда будет справляться с техническим долгом?

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

Релизы

Вопрос: Какое тестирование вы проведете перед релизом? Будет ли план регрессионного тестирования, который вся команда сможет выполнить вместе? Как насчет исследовательского тестирования?

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

Вопрос: Как будет распространяться программное обеспечение?

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

Техническое обслуживание

Вопрос: Как вы будете измерять успех релиза?

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

Вопрос: Как вы будете контролировать работоспособность вашего приложения?

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

Вопрос: Какие типы поведения вы должны искать?

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

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