testengineer.ru

Домой Обучение Стратегия обеспечения качества и вопросы в процессе ее составления

Стратегия обеспечения качества и вопросы в процессе ее составления

Автор

Дата

Категория

Стратегия тестирования — это когда вся команда работает с прицелом на качество. Качество нельзя «оставлять тестировщикам» и только им, это общая цель тестировщиков и разработчиков.

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

Создание и груминг пользовательских историй (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 тысяч сотрудников, разрабатывающих софт для управления полетами. Так что нужно собраться и обсудить стратегию, подходящую именно вашей команде. А затем неукоснительно ее придерживаться.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

1 КОММЕНТАРИЙ

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

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

$1100*
медианная зарплата в QA в ноябре

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Последние комментарии