- Пользовательские истории
- Процесс разработки
- Передача на тестирование
- Тест-план
- Инструменты
- Поддержка тестов
- Баги и технический долг
- Релизы
- Пострелизное обслуживание
Стратегия тестирования — это когда вся команда работает с прицелом на качество. Качество нельзя «оставлять тестировщикам» и только им, это общая цель тестировщиков и разработчиков.
Как вся команда сосредоточится на качестве? Напишет стратегию обеспечения качества. Это будет документ, согласованный всей командой. Нечто вроде контракта, описывающего как софт разрабатывается, тестируется и выпускается командой. Обсудим некоторые вопросы, которые могут возникнуть в процессе.
Создание и груминг пользовательских историй (user stories)
Как команда решает, с какими историями работать?
Решение может приниматься как всей командой, так и единолично — владельцем продукта (product owner-ом). Есть и третий вариант: приоритеты может расставлять кто-то вне команды, например, заказчик.
Кто проводит груминг историй, кто готовит их к разработке?
Или вся команда сообща, или только разработчики. В идеале, должны принимать участие владелец продукта (product owner), бизнес-аналитики, разработчики и тестировщики.
Процесс разработки
Как в команде решают, кто работает над историей?
Чаще всего разработчики выбирают себе истории, размещенные на борде, самостоятельно; или же, истории распределяются между программистами исходя из их компетентности в разных областях разрабатываемого продукта. В некоторых командах тестировщики вполне способны работать с простыми историями, например менять текст или стили на странице.
Что значит отметка «Сделано» (Done) на истории?
Она ставится, когда выполнены все критерии, описанные в истории. Как понять, что задачу можно передавать на тестирование в QA-отдел? В большинстве случаев считается что разработчик должен сам провести некое базовое тестирование, проверяя работоспособность своего кода.
Перевод задачи на тестирование
Когда задачу можно передавать на тестирование?
В некоторых командах разработчик просто меняет статус у задачи на «Готова к тестированию» (Ready for Testing) и просто переносит в соответствующую колонку на борде. В других проводится формальная церемония передачи; разработчик презентует разработанный в рамках user story функционал и дает советы по тестированию.
Кто организует тестовую среду?
Вопрос, о котором порой забывают, но с которым нужно обязательно определиться. Если разработчики думают, что залить код в тестовую среду это обязанность тестировщиков, а тестировщики думают, что разработчики уже все подготовили, то тестировщики начинают работать и только тогда видят, что нужных изменений нет; на поиск виновных и исправление уходит время.
Кто проводит тестирование?
В некоторых командах разработчики могут сами протестировать простые истории, что ускоряет разработку. Более сложные задачи все-таки должны быть на плечах экспертов QA-отдела.
Создание тест-плана
Кто пишет тест-план?
Каковы детали? Где будут храниться эти планы? Есть команды, в которых предпочитают не заморачиваться, пишут очень мало документации, в том числе формальных планов. В других командах работает сложнейшая система управления тест-кейсами, где скрупулезно документируются абсолютно все тесты. А между этими крайностями — большинство команд. Все зависит от продукта.
Кто пишет автотесты?
В большинстве случаев разработчики пишут юнит-тесты, а тестировщики — API-тесты и UI-тесты. Случается, разработчики пишут юнит-тесты и API-тесты, а тестировщики только тесты интерфейса. Лучшей практикой является, когда разработчики и тестировщики разделяют ответственность за создание API- и UI-тестов. Тогда разработчики принимают участие в разработке тестов, а тестировщики — следят за их выполнением.
Кто делает тесты безопасности, производительности, доступности и user-experience?
В крупных компаниях есть специально выделенные роли тестировщиков безопасности и производительности. В маленьких стартапах с единственной командой которая «обо всем», тестировщики занимаются в том числе и указанными вещами.
Инструменты
Какие инструменты применяются в ручном и автоматизированном тестировании?
Правильные инструменты — уже полдела. Разработчики предпочитают работать с инструментами, которые используют те же языки программирования, на которых пишется продукт — меньше приходится «переключать контекст».
Поддержка тестов
Кто отвечает за поддержку тестов в годном состоянии?
Автоматизированные тесты, написанные на скорую руку, быстро теряют актуальность. Замена всего одного слова на странице может заставить такие тесты упасть. В идеале, применяют метод «ты наделал, ты и исправляй», то есть тесты исправляются человеком, который их писал. Если так не получается, надо стараться чтобы в команде было много людей, знакомых с написанными тестами, и способных быстро их исправить.
Баги и технический долг
Как исправляются баги?
Они обсуждаются разработчиками и тестировщиками, сортируются по важности всей командой, записываются в бэклог, чтобы потом к ним вернуться? Хорошая практика — исправлять баги как можно быстрее после обнаружения — пока разработчик не успел забыть контекст.
Как команда решает проблему технического долга?
Команда может предварительно договориться в каждом спринте посвящать некоторую часть времени техническому долгу. В некоторых командах принято передавать технический долг свободному разработчику, у которого закончились задачи на спринт.
Релизы
Какое тестирование выполняется перед релизом?
Выполняется ли регрессионное и исследовательское тестирование? Кто его проводит? В некоторых командах за несколько дней до релиза все принимают участие в таком тестировании. Оно позволяет найти трудноуловимые баги.
Как софт уходит на релиз?
В некоторых компаниях есть специальный релиз-менеджер, который занимается релизом. В других все делают рядовые члены команды. Очень помогает CI/CD: софт автоматически деплоится и автоматически проверяется автотестами. Такой подход экономит время и усилия.
Обслуживание
Как понять, что релиз прошел успешно?
После релиза софта о нем забывают. Или стараются забыть. А в это время пользователи начинают работать с софтом… Как оценивать качество выпущенного продукта? Можно вести учет багов, о которых сообщают клиенты, или мониторить логи.
Как будет отслеживаться работоспособность приложения?
Желательно вести мониторинг ошибок — лучше узнать о них до того, как их найдут сами пользователи.
***
Стратегия обеспечения качества, естественно, будет отличаться в стартапе из 10 человек, разрабатывающих развлекательный чат, и компании из 10 тысяч сотрудников, разрабатывающих софт для управления полетами. Так что нужно собраться и обсудить стратегию, подходящую именно вашей команде. А затем неукоснительно ее придерживаться.
