Пофилософствуем на тему, как QA может влиять на разработку фич. Поделимся мыслями и наработками о том, что тестировщик может предложить команде помимо своих мануальных способностей проверки задач.
А в чем собственно проблема? Зачем тестировщику проявлять еще какие-нибудь качества помимо качеств мануального тестировщика?
В этом неидеальном мире часто можно увидеть, как человек ответственный за качество, подключается только на последнем этапе разработки фичи. Только тогда, когда по мнению многих осталось совсем немного: протестировать задачу. В этом неидеальном мире такой подход приводит не всегда к качественному результату, да еще и шанс доставить фичу в срок резко уменьшается.
Так зачем переделывать задачу и факапить сроки, если можно предотвратить большинство ошибок? Есть один вариант: QA-инженер. Специалист который будет влиять на качество процессов и продуктов на каждом этапе работы над фичей и служить связующим звеном между всеми этапами и подразделениями. В итоге вы получите качественный результат.
*Что мы подразумеваем под “качественным результатом”?
Мы смогли решить проблему конечного пользователя и закрыли его потребность вовремя.
Мы добились адекватного соотношения затраченных ресурсов и пользы, которую принесли бизнесу.
Чтобы прийти к качественному результату, нужно, чтобы QA участвовал на каждом этапе разработки фичи при:
поиске оптимального подхода к реализации функционала;
утверждении дизайна интерфейса;
выставлении сроков.
Почему этим связующим элементом гипотетически должен стать QA?
Приведем несколько аргументов:
У QA хорошо прокачаны софт-скиллы.
QA – это адвокат пользователя в продуктовой команде, мост между продуктом и пользователем и самый частый пользователь в одном лице.
QA – последний оплот перед релизом, поэтому именно в его интересах минимизировать количество недоработок на ранних этапах. Получается, чем больше багов он предотвратит на старте, тем легче будет его жизнь на финишной прямой, и, как следствие, дешевле обойдется разработка бизнесу.
Если этого всего недостаточно, есть еще один аргумент: QA достаточно хорошо знаком как с технической стороной продукта, так и с “интерфейсной”. Короче говоря, он может подружить аргументы программиста, дизайнера и менеджера, если они не будут матчиться.
Давайте рассмотрим гипотетический процесс, на каждом этапе которого, предположим, участвует QA.Ремарка: это состояние идеального газа. Конечно, может быть много вариаций, в зависимости от специфики продукта, структуры компании и много чего еще.
История разработки одной фичи
Шаг 1. Знакомство команды разработки с новой фичей
На этом этапе фича еще может не иметь никаких очертаний. Задача QA – включить одну из своих субличностей “пользователь”, чтобы осознать всю его боль и неудобства и контрибьютить идеями совместно с другими членами команды. QA будет предлагать идеи на стыке дизайна, разработки и пользовательского опыта, чтобы помочь команде увидеть картинку чуть более цельно.
Зачастую это может поменять видение менеджера на то, как нужно решать проблему. Фича может приобрести совершенно другой вид.
Совет: Если таких обсуждений в команде нет или вы в них не участвуете, то подойдите и расскажите менеджеру как вы бы улучшили какой нибудь существующий функционал или функционал, который вы тестируете сейчас. Получив толковый фитбек от тестировщика по поводу фичи, менеджер возможно задумается, почему он не привлек вас раньше к этой задаче.
Шаг 2. Обсуждение UX/UI-решения
Это следующий этап жизненного цикла фичи. Теперь перед глазами у тестировщика есть дизайн. В это время команда разработки на второй круг шторма, потому что чем больше неизвестных определим, тем лучше будет итоговый результат.
Когда перед глазами у тестировщика есть UX/UI-решение, он может увидеть все белые пятна в пользовательских сценариях. Этот вклад QA позволяет выявить те места, где в будущем появятся “дополнительные требования”. Те самые "доп.требования", из-за которых часто сдвигаются сроки релиза. Надо зарелизить фичу в срок и минимизировать затраты бизнеса.
Будьте готовы к тому, что UX/UI-решение возможно придется переделать. Это может быть кнопка, текст на кнопке или вся фича целиком. Этап может повториться несколько раз, пока команда не придет к лучшему возможному решению.
Совет: Чтобы к QA начали прислушиваться, покажите пример улучшения фичи, которую сделали без QA на этом этапе и расскажите, что история могла сложиться иначе. Найдите, как можно улучшить какой-нибудь user story в какой-нибудь уже реализованной фиче или задаче, которую вы тестируете сейчас.
И еще один совет: разберите базовые вещи об UX/UI науке. Изучите простейшие критерии качественного интерфейса.
Шаг 3. Декомпозиция задачи и оценка сроков
На этом этапе не будет написано ни строчки кода, но будет выполнен один из самых важных и сложных этапов работы разработчика, от которой будет зависеть успех всей последующей работы над фичей.
Здесь происходит детальный разбор фичи: выявляются всевозможные требования, например, мобильных приложений к бэкенду, требования бэкенда к мобильным приложениям, формат общения между сервером и клиентом и куча других аспектов интеграции фичи.
Команда разработки детально разбирает требования аналитиков и менеджеров, декомпозирует задачи и выставляет сроки. Команда дает ответ, возможно ли сделать фичу в таком виде в желаемый срок.
Роль QA – проговорить еще раз каждую подзадачу с разработчиком и пропустить все это через тест-кейсы и user story. Найти оставшиеся подводные камни. Отловить нотки неуверенности в голосе разработчика, которые показывают, достаточно ли изучили задачу, чтобы выставлять срок.
Также QA нужно определить глубину и объем затронутого новым функционалом кода, который предстоит тестировать перед релизом.
Часто на этом этапе приходят всякие озарения по саб-таскам, а сроки становятся более предсказуемыми. Бросать такую огромную работу на разработчика нечестно, и круто, если он это делает в паре с QA, который дополняет картину мира и смотрит с другого ракурса.
Совет: QA надо качать технические скилы, чтобы лучше понимать разработчиков и быть с ними на одной волне. И в целом не помешало бы выстраивать дружеские отношения с разработкой, чтобы было к кому обратиться за более глубокими разъяснениями о том, как работает фича под капотом.
Шаг 4. Обсуждение подводных камни и поиск компромиссов
Команде из QA и разработчика нужно рассказать менеджеру обо всех найденных технических проблемах. Например, если поняли, что функционал не удастся реализовать в том виде, в котором предлагают дизайнеры, или если на это потребуется гораздо больше времени, чем предполагалось. А потом уже всем вместе (разработчик, QA, менеджер и дизайнер) прийти к решению, как поступить в этой ситуации:
увеличить ресурсы, например, выделить больше времени или добавить разработчиков в команду;
упростить функционал;
…ну, или смириться с реальностью.
Гипотетический результат от гипотетического внедрения этого подхода:
Сроки становятся более предсказуемыми.
Качество продукта повышается.
Стоимость разработки снижается за счет устранения ошибок и возможных доработок еще до начала процесса разработки.
Ну и несколько тривиальных советов QA-специалисту, который хочет быть полезен на каждом этапе работы над фичей:
Знать идею продукта, фичи.
Иметь представление о пользователе.
Иметь понимание, что бизнес хочет от пользователя.
Иметь понимание, что пользователь хочет от продукта.
Иметь понятия об UX/UI.
Иметь базовое понимание в программировании.