Привет, Хабр! Меня зовут Ксения, я руководитель отдела QA в компании ISPsystem. О том, как я собирала команду, можно почитать в моей предыдущей статье.
Сейчас в нашем отделе 14 человек. Чем шире становится команда, тем больше ожиданий на нее возлагается относительно качества продуктов. Это очень холиварная тема, так как от компании к компании меняется набор задач и обязанностей QA, поэтому и ожидания у всех разные.
Кто же отвечает за качество продуктов и каким образом QA-инженеры могут на него влиять? Я опросила лидов, проджектов и продактов всех команд нашей компании об ожиданиях от QA. В своей статье хочу поделиться итогами опроса и подсветить, в каких моментах ожидание и реальность не совпадают. А еще — рассказать, как результаты опроса помогли найти точки роста для нашего отдела.
Кто такой QA
Как я уже говорила, обязанности и задачи QA-специалиста могут разниться от компании к компании — все зависит от принятых процессов. Где-то роль QA-инженера может совмещаться с другой ролью, например системного аналитика или специалиста техподдержки. А где-то сотрудники могут заниматься исключительно приёмочным тестированием, что характерно для роли обычного тестировщика. Я расскажу, чем занимается отдел QA в нашей компании. Но для начала кратко опишу принятые у нас процессы и на каких этапах к ним подключаемся мы.
Сейчас у нас три продукта. Как и во многих компаниях, у наших продуктов есть дорожная карта и бэклог. В соответствии с ними мы ставим цели на квартал. Внутри каждого квартала — набор фич, которые необходимо реализовать. Каждая фича декомпозируется на небольшие задачи, укладывающиеся в двухнедельный спринт.
Требования
Для каждой фичи мы составляем требования и описываем их в специальном документе. Еще в них зачастую описываются архитектурные решения, а также UX-требования. На их основании QA-инженер составляет артефакты для приемочного тестирования и чек-лист для первичного тестирования разработчиком. Как правило, чек-лист включает в себя проверку основной функциональности фичи.
Например, если задача заключается в добавлении нового текстового поля в форму редактирования какой-либо сущности, то в чек-лист для разработчика будут добавлены следующие пункты: проверить, что поле существует, отображается в соответствии с прототипом, доступно для ввода и обрабатывает данные корректно. При этом проверки не учитывают различные условия, например статус сущности.
Более глубокие проверки будут проводиться уже на приемочных тестах.
Думаю, вы понимаете, что цена ошибки, обнаруженной на ранних этапах, невысока, так как не требует трудозатрат на написание кода, ревью и тестирование. Поэтому QA-специалисты подключаются к задаче на этапе проработки требований, чтобы подсветить возможные риски, выявить непроработанные нюансы и кейсы.
На рисунке изображен примерный график роста трудозатрат на исправление ошибки в соответствии с этапом, на котором она выявлена. На графике видно: чем позже мы находим ошибку, тем более дорогим становится ее исправление. Например, для исправления ошибки, найденной на этапе разработки, потребуются только правки разработчика. Для ошибок, найденных на этапе приемочного тестирования, потребуется время тестировщика на локализацию, повторную сборку стенда с обновлениями и их проверку. А исправить ошибки, найденные после релиза, не получится без привлечения технической поддержки — для взаимодействия с клиентом и локализации ошибки.
После составления требований переходим к этапу разработки. Его мы не будем рассматривать подробно: QA-инженеры в нем напрямую не задействованы. Иногда на этом этапе тоже могут выявляться недоработки в требованиях, и мы подключаемся к обсуждениям. Также нас привлекают, если возникают вопросы относительно реализации фичи и ее тестирования. Перейдем к следующему этапу.
Приемочное тестирование
Каждая фича проходит этап приемочного тестирования, без которого она не уходит клиенту. Перед этим разработчики проводят тестирование по чек-листу, который мы для них готовим. Если проверка пройдена успешно, фича уходит на приемку. Чаще всего в этом процессе задействованы непосредственно QA-инженеры, но иногда разработчики тоже подключаются к процессу. Мы выявляем проблемы, ошибки, несоответствия требованиям, проверяем их исправление и выдаем вердикт — рекомендуем фичу к релизу или нет.
Предрелизное тестирование
После того как все фичи прошли приемку, они собираются в общую релизную ветку. Наступает этап предрелизного тестирования.
Предрелизное тестирование у нас в компании — это своего рода набор дымовых тестов. Он содержит основные пользовательские сценарии. Количество таких проверок может расти и меняться по мере разрастания продукта или изменения потребностей клиента, поэтому артефакты для таких проверок мы постоянно поддерживаем в актуальном состоянии.
Также периодически меняются наборы тестов, условия и преднастройки для их выполнения во избежание эффекта пестицида.
Эффект пестицида заключается в том, что при длительном выполнении одних и тех же проверок в какой-то момент они перестанут выявлять ошибки.
На текущий момент две команды из трех проводят предрелизные проверки, покрытые автотестами: DCImanager и VMmanager. В третьей команде — BILLmanager — они полностью ручные.
Ответственность за выпуск релиза лежит на QA-инженерах: мы запускаем тесты, проводим проверки и даем заключение, готов ли релиз к выпуску. Выпускать или не выпускать, решают лиды и проджекты.
Итак, резюмируя, основные задачи QA в нашей компании:
Анализ требований и выявление неточностей и недоработок.
Составление тестовых артефактов.
Приемка и аппрув фич.
Поддержание в актуальном состоянии пула предрелизных проверок, их выполнение и аппрув релизов.
Конечно же, это не полный список задач. Помимо этого QA-инженеры пишут автотесты, внутреннюю документацию по фичам, презентуют фичи и делают много полезного для продуктовых команд. Я лишь перечислила то основное, что влияет на качество продукта.
Ожидания от QA-инженера
С задачами разобрались, но каковы же ожидания продуктовых команд и бизнеса от работы QA-инженеров? Мне было интересно разобраться в этом вопросе и выявить точки роста для нашего отдела, поэтому я опросила лидов, проджектов и продактов команд. Ответы коллег по многим вопросам совпадали. Я резюмировала их и собрала в таблицу.
Первый вопрос звучал так: «Какие текущие проблемы продукта хочется решить за счет тестирования?»
Ответ | Реальность |
Хочется значительно улучшить качество продуктов | QA-инженеры могут подсветить проблемы, предложить улучшения, определить количество и приоритет ошибок, но качество продукта зависит от деятельности всей команды |
Сократить количество ошибок | QA-инженеры не могут напрямую сократить количество ошибок, они их не исправляют |
Уменьшить жалобы клиентов | Тут тоже QA-инженеры не могут напрямую повлиять на количество жалоб клиентов |
По сути, все ответы сводятся к одному: повышение качества и уменьшение ошибок. Несомненно, QA-инженеры влияют на качество продуктов — они подключаются на ранних этапах разработки как раз для того, чтобы сделать фичу качественно. Мы формируем тестовые артефакты, оптимально распределяя проверки, чтобы убедиться в работоспособности фичи и отловить максимальное количество ошибок на тестировании. Но это не означает, что число ошибок сократится. Скорее наоборот: количество ошибок в бэклоге будет расти.
Приведу пример собранной статистики по предрелизным проверкам:
Желтая кривая — количество ошибок, найденных за один прогон предрелиза, а голубая кривая показывает, сколько из них было исправлено. По статистике, примерно 50% найденных нами ошибок исправляются до релиза. На это влияет приоритет: ошибки с невысоким приоритетом, как правило, уходят в бэклог.
Для уменьшения ошибок необходимо выделять достаточное количество времени до релиза на их исправление, учитывая возможные риски. Также для этого полезно проводить технические спринты и уменьшать технический долг. Когда в продукте есть болезненный модуль, требующий переработки или рефакторинга, не стоит откладывать его в долгий ящик, иначе ошибки продолжат концентрироваться именно в нем.
Важно понимать, что QA-специалисты при составлении артефактов опираются на основные сценарии, но 100% покрытие всех возможных кейсов невозможно физически. Порой их количество может составлять тысячи проверок, и в таких случаях мы используем различные техники тест-дизайна, специальные подходы из теории тестирования, чтобы сформировать оптимальный набор тестов.
Следующий пункт моего опроса: «Чего сейчас не хватает в процессе тестирования?»
Ответ | Реальность |
Автоматизации регрессов | Очень верное замечание. Автоматизации нам действительно не хватало |
Четкой оценки времени тестирования | Этот пункт также верен, и его мы взяли в проработку |
Конечно, отсутствие автотестов и возможности запускать их на каждый фикс очень неблагоприятно сказывается на всем продукте. Мы рискуем выявить ошибки лишь на этапе предрелизных проверок, а это значит, что их исправление будет стоить дороже.
Этот пункт мы взяли в работу. Так у нас появились выделенные автоматизаторы, и автотесты активно развиваются. Уже сейчас мы запускаем их при приемке фич и при проведении предрелизного тестирования. Наша цель — покрыть все предрелизные проверки автотестами и тем самым снизить количество рутинной работы. Также автотесты позволят повысить скорость обнаружения ошибок и выпускать релизы быстрее.
С оценкой времени на тестирование проблемы действительно были. Культура оценки времени сейчас активно прививается повсеместно в компании, не только в сфере QA. По-прежнему сложно бывает давать оценку QA-специалистам на ранних этапах, когда еще не до конца ясно, в каком объеме внедряемая фича затронет продукт. Но с фичами, требования которых описаны, все гораздо проще. Мы накидываем крупноуровневый чек-лист, оцениваем каждый пункт по нему, закладываем риски. По мере нарастания опыта мы все чаще попадаем в оценку.
И еще один вопрос: «Что нужно улучшить в процессе тестирования?»
Ответ | Реальность |
Сократить продолжительность тестирования без потери качества. Порой тестирование занимает больше времени, чем разработка | Реальность такова, что тестирование и правда может занимать больше времени, и это нормально. Невозможно сократить продолжительность, не пожертвовав чем-то |
Разберем этот пункт подробнее. Представьте, что продукт — это лабиринт, который проходят разные пользователи. Но вход и выход у него не один, их множество. У пользователей разные потребности, разные настройки, разное понимание интерфейса. Соответственно, и путь свой они проходят по-разному.
Давайте представим, что голубой круг — это фича или исправление. До него можно дойти тремя путями из трех разных входов. Фиолетовые круги — это пути лабиринта, по которым дальше может идти клиент к конечной точке.
Глядя на лабиринт, мы видим, что фича одна, а входов и выходов, то есть путей, по которым может идти пользовать, несколько. Если все они важны, то пренебрегать тестированием даже одного из них нельзя, иначе качество продукта пострадает. Стало быть, и количество проверок может увеличиваться кратно количеству возможных путей. Поэтому зачастую и получается так, что тестирование занимает больше времени, чем разработка.
Задача QA-инженера при составлении артефактов учесть все голубые и фиолетовые стрелки, которые следуют к фиче и от нее, а также все возможные преднастройки пользователя, чтобы оптимальным образом распределить тесты.
Тут мы учитываем требования и первоначальные потребности клиента. Если количество тестов большое, то прибегаем к применению различных техник тест-дизайна, о которых я говорила выше. Все это нацелено на то, чтобы выпустить фичу в лучшем качестве. Мы не тестируем все подряд, но стараемся учесть по максимуму.
QA-инженеры в наших командах достаточно гибкие. Мы, конечно, мечтаем об идеальных продуктах, но иногда наши мечты разбиваются о суровую реальность (и сроки). Бывает, что один из путей не так важен на старте фичи. Тогда мы понижаем приоритет этого пути, а проверки сокращаем до минимальных — с договоренностью, что после релиза мы их добьем. Но, думаю, вы понимаете, что в таком случае мы не можем знать наверняка, насколько забагованным будет этот путь. А значит, мы рискуем качеством.
Выводы и заключение
Ожидания от работы QA могут быть противоречивы, а порой не совпадают с реальностью. Работа QA не всем очевидна, ведь ее результаты чаще всего невозможно пощупать (за исключением метрик, но это тема для отдельной статьи). Объемы мыслительных процессов по поиску оптимальных проверок для покрытия нашего «лабиринта» тоже не видны. Поэтому необходимо понимать, чего ожидают конкретно от вас, и стараться доносить, какие из этих ожиданий вы можете удовлетворить, а какие от вас не зависят.
Если вы лид или руководитель команды тестирования, то рекомендую проводить подобные опросы регулярно. Выносить из них важные задачи и опровергать некорректные ожидания. А также в динамике следить за тем, как ожидания меняются с течением времени.
