Как защитить PROD от багов и себя от стресса
Мне этот мир абсолютно понятен
Привет, Хабр! Меня зовут Иван, я инженер по ручному и автоматизированному тестированию (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 и DOR.
Definition of Ready — это критерии готовности взять задачу в разработку, то есть DOR это условия, при выполнении которых задача может упасть в спринт. Команда сама выбирает критерии и придерживается их. Например: аналитика написана, есть точные тех.требования и т.д.
Definition of Done — это критерии завершения задачи, то есть условия после которых выполненная задача переходит в тестирование к QA.
Третий риск: Frontend и Backend выполняют задачи не синхронно
Под синхронным выполнением задачи я подразумеваю, что задачи на фронте и на бэке будут выполняться как минимум в одном спринте. Почему это критично? Как я описал выше, тех.требования имеют свойства корректироваться на этапе разработки и если один разработчик взял задачу в одном спринте и подкорректировал реализацию на своей стороне, то второй разработчик может выполнить задачу по устаревшим требованиям.
Риск зависит от взаимодействия разработчиков между собой и умением договорится, но если ваш процесс в команде не отточен, то необходимо озвучить действия при изменении тех.требований. Для QA это будет критичным в актуализации тест-кейсов и тестировании фичи. Разработчик выполнил задачу 2 недели назад и теперь необходимо вспомнить почему тут так, а тут вот так.
Четвертый риск: Тестирование
Само тестирование может быть некачественным из-за человеческого фактора. Пропустил ошибку т.к. не написал тест-кейс по этой функциональности или не проверил негативные тесты. Недостаточно времени было на тестирование. Не было документации вовсе.
Данный риск зависит от самого инженера по тестированию, но описанные выше риски могу напрямую влиять на качество тестирования и ответственность ложится уже на вас.
Защитить себя и ваше время помогут вышеупомянутые DOR и DOR. Необходимы критерии при которых задача берется в тестирование и критерии завершения тестирования. Например в задаче описаны все изменения требований, в задаче есть описание и ссылка на требования по которым можно актуализировать ТК. Критериями завершения будет обновленные тестовые кейсы и зафиксированный результат работы новой фичи. Критерии зависят от вашего опыта и команды тестирования.
На доске спринта обязательно должна быть колонка Test в которой находятся задачи связанные с изменением программы — их необходимо протестировать. Не все задачи необходимо складывать в эту колонку, т.к. вы не перепроверяете работу за разработчиками, а проверяете работу ПО (программы).
Пятый риск: Релиз (Поддержка)
Данный риск зависит от четвертого, т.к. вы можете обнаружить ошибку только при регресс тестировании, а это значит мало времени уделено тестированию. В этот риск я бы добавил момент, когда вы выкатились на пром, но заказчику не нравится что-либо.
Тут ответственность не лежит на QA, но есть случаи когда пытаются найти виноватых и им можете стать вы. Именно по этому вам необходимо придерживаться шагов выше и не забывать про приемочное и системное тестирование, которое зафиксирует, что мы выкатили именно то, что ожидалось.
ЗАКЛЮЧЕНИЕ
В этой статье я привел пять рисков, но в зависимости опыта и проекта в котором вы работаете их может быть больше или меньше. При написании я ориентировался на свой опыт и буду благодарен, если вы дополните или поправите мою информацию.
QAtoDev — канал о ручном и авто тестировании
