Привет, Хабр! Меня зовут Иван, я инженер по ручному и автоматизированному тестированию (Full Stack QA). В роли QA уже 2 года, веду телеграм канал о тестировании QAtoDev.

Сегодня хочу поговорить про баги на ПРОДе и о том, как защитить команду от них, ведь для реализации необходима помощь всей команды в восстановлении процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA.

Глава 1: МЕТОДОЛОГИЯ РАЗРАБОТКИ ПО

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

Этап 1. Идея

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

Интересный вопрос, кто же вносит идею в продукт?

Представляю вашему вниманию основные роли в ИТ команде:

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

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

Команда разработки - Фронтенд, Бэкенд, Тестирование и Поддержка являются механизмом, который превращает идеи в реальность с учетом спецификаций, тех. требований и своих профессиональных компетенций. На этапе разработки фронт и бэк могут корректировать спецификации после аналитика из-за неточных требований или с целью оптимизации продукта. При тестировании удобства использования QA может вносить новые идеи в продукт, согласуя их с аналитиком или владельцем продукта.

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

Этап 2. Аналитика

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

Этап 3. Разработка

Фронт и бэк берут задачи в спринт и приступают к работе. Как правило на бэке необходимо выполнить задачи в первую очередь и только поле фронт подтягивается к ответам с БД. Но бывают и исключения в виде реализации фронта с моками (заглушки), которые имитируют ответ с бэка и потом заменяются.

Этап 4. Тестирование

Самое интересное, это принять работу разработчиков и с уже написанными тест-кейсами и чек листами протестировать ПО. Тестовая документация пишется на этапе появления тех.требований от системного аналитика или владельца продукта. Тестовые кейсы с большой вероятностью уже устарели, т.к. на этапе разработки изменились требования. И поэтому при тестировании функционала мы изучаем корректировки спецификаций и обновляем наши тесты во время тестирования. Это Agile :)

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

Этап 5. Релиз (Поддержка)

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

К примеру есть локальный стенд DEV - стенд, где разработчики кодят и реализуют фичи. После изменения с DEV стенда заливают на тестовый стенд, где собственно тестирует QA из этапа 4. После успешного прохождения тестирования выполняется релиз всех изменений, но мы не можем сразу же внедрить изменения в конечный продукт, который уже используют клиенты. Поэтому мы переносим все изменения с тестового стенда на релизный и проводим регрессионное тестирование и проверяем все изменения в сервисе. У нас может быть несколько тестовых стендов, каждый из которых отвечает за проверку определенных аспектов продукта.

Глава 2: РИСКИ

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

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

Первый риск: Идея попадает к аналитику

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

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

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

В каждой команде бэк и фронт разработчики по разному реагируют на бизнес цели, тут важно узнать их мнение на этапе PBR (грумминга), где оценивается задача прежде, чем она берется в спринт. К этому времени уже будет написана первая версия тех.требований аналитиком, но подкорректировать ее будет не критично.

Второй риск: разработка по тех. требованиям

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

Пиши то - не зная что, реализуй так - не зная как.

Часто встречается и такая модель разработки - когда ответственность падает только на разработчика, минуя владельца продукта и аналитику. Это грустно и в таком случае помогут DOR и DOD.

Definition of Ready - это критерии готовности взять задачу в разработку, то есть DOR это условия, при выполнении которых задача может упасть в спринт. Команда сама выбирает критерии и придерживается их. Например: аналитика написана, есть точные тех.требования и т.д.

Definition of Done - это критерии завершения задачи, то есть условия после которых выполненная задача переходит в тестирование к QA.

Третий риск: Frontend и Backend выполняют задачи не синхронно

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

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

Четвертый риск: Тестирование

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

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

Защитить себя и ваше время помогут вышеупомянутые DOR и DOD. Необходимы критерии при которых задача берется в тестирование и критерии завершения тестирования. Например в задаче описаны все изменения требований, в задаче есть описание и ссылка на требования по которым можно актуализировать ТК. Критериями завершения будет обновленные тестовые кейсы и зафиксированный результат работы новой фичи. Критерии зависят от вашего опыта и команды тестирования.

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

Пятый риск: Релиз (Поддержка)

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

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

ЗАКЛЮЧЕНИЕ

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

QAtoDev - канал о ручном и авто тестировании