Роль и контекст

Короче говоря, я QA лид. Отвечаю за обеспечение и контроль качества сразу на нескольких проектах в компании IT Test. А это значит, что пребывая к контексте десятка имеющихся у нас в портфеле проектов, я выстраиваю процессы тестирования, анализирую связанные с качеством инциденты, развиваю компетенции тестировщиков и, в целом, делаю всё, чтобы QA активности были прогнозируемыми результативными. 

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

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

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

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

Такие вопросы наравне со множеством иных мне приходится ежедневно решать в ходе своей деятельности.

И данный формат работы требует специфического подхода к обеспечению качества, когда само понимание качества от проекту к проекту начинает варьироваться.

На помощь здесь мне приходят, во-первых, метрики. Те же самые, с которыми работает большинство лидов QA: метрики дефектов, метрики тестового покрытия, выполнения тестов, релизного качества и та метрика, о которой мы далее поговорим более детально — метрика эффективности команды.

Ну а, во-вторых, моему управлению обеспечения качества помогает постоянная работа с профессиональным ростом сотрудников. Именно о том, как эти два явления — моя работа с профессиональным ростом и метрика эффективности сосуществуют, — я бы и хотел здесь рассказать.

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

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

• точность эстимейтов;

• отклонение факта от оценки;

• количество задач без оценки;

• количество просроченных задач;

• количество завершённых задач за период;

• время прохождения задачи через процесс;

• время от постановки задачи до завершения;

• загрузку специалистов;

• количество возвратов задач на доработку.

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

• Планировать спринт или релиз. Если QA-задачи оценены реалистично, команда понимает, какой объём проверки можно выполнить в доступное время.

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

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

• Повышает прозрачность работы QA. Ещё раз заострим своё внимание на этом пункте. Руководитель, проектная команда и заказчик видят, сколько времени занимает проверка разных типов задач и почему отдельные активности требуют больше ресурсов.

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

Однако при таком точном и тонком конфигурировании загрузки специалистов возникает очевидная проблема: общая точность оценки зависит от постоянно изменяющегося контекста проекта, и ответственное за саму оценку лицо (обычно — моё), вынуждено постоянно «держать руку на пульсе» проекта, заблаговременно прогнозируя и корректируя эстимейты. Что в условиях наличия десятка разнообразных живых проектов становится невозможным.

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

Проблема, которую необходимо было решить.

На проектах возникали типовые проблемы:

• тестировщики забывали проставлять оценки. Задачи груммились, разработка давала какие-то оценки, проводилась какая-то декомпозиция, но тестирование оценивалось по остаточному принципу или… 

• …оценки давались формально. Например, как процент от времени разработки. Само по себе время разработки действительно может являться одним индикатором сложности задачи, но практика показывает, что не существует линейной зависимости времени тестирования от времени разработки. А потому… 

• …фактическое время выполнения часто отличалось от планового. Последствия этого были очевидными: сдвигались сроки релизов, специалисты оказывались перегружены, не выходили своевременно на проекты или у них случался простой;

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

• Сложные задачи оценивались без декомпозиции. Масштаб иных задач серьёзным образом сказывался на степени отклонения от эстимейта вследствие изобилия краевых сценариев, подлежащих проверке, или комбинаторных взрывов. 

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

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

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

Начнём с того же, с чего я начал обучение наших специалистов — с очевидного. Очевидно, что мы не сможем дать точную оценку работ по тестированию, если объект тестирования нам принципиально не знаком и мы не знаем, как к нему подступиться. Давайте я просто приведу здесь примеры заголовков задач с разных наших досок по разным проектам.

«Добавление страницы управления заявками в админ панель». «Pop‑up для удержания юзеров desktop». «Реализовать блок „Еще кейсы“ на странице проектов (1920px)».

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

Соответственно первый тезис, каковой озвучили мои тестировщики, когда я задал вопрос: «Что вам нужно для точной оценки задачи?», звучал как: «Ознакомиться с этой задачей». Знать объект тестирования. И иметь опыт работы с ним. 

Совершенно справедливая мысль, однако, во‑первых, ситуация, где мы в деталях знаем тестируемых объект, чтобы дать точную оценку, случается далеко не всегда, а во‑вторых, даже имея представление об объекте, мы всё равно часто ошибаемся в оценке.

Почему?

Именно вокруг этого вопроса я построил всё наше обучение.

Причины, почему мы ошибаемся в оценке:

1)Туман требований

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

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

— Если от тестировщиков требуют точной оценки, они должны требовать точных требований. Любые неясности, неопределённости и противоречия должны быть зафиксированы и устранены до этапа оценки. Это является одним из критериев выработанных нами DoR (Definition of Ready)

— Точные требования не всегда возможны. Мы часто участвуем в пресейлах и тендерах, где нам на оценку представляются только очень абстрактные пожелания заказчика. В этом случае мы осуществляем вилочные оценки, строим гипотезы и оцениваем не столько проект, сколько эти самые множества сформулированных «если». А неточность оценки фиксируем, как риск с временным диапазоном.

2) Игнорирование сопровождающих работ в оценке

Здесь мы вновь говорили о том, что тестирование — это никогда не только выполнение тестов. Подготовка окружения, доступов и данных может иногда затянуться на часы, каковые тоже должны быть учтены в оценке: отдельно те часы, которые потратят непосредственно тестировщики, и отдельно те часы, которые могут стать простоем в ожидании необходимой среды, сборки или доступов.

Но здесь мы вновь касаемся критериев входа. А что насчёт критериев выхода? Любому тестировщики известно, что проведение проверок является лишь одним из критериев. Среди прочих критериев присутствует фиксация итогов тестирования, в которые входят:

• очевидно, оформление отчётов о дефектах;

• формулировка заключения о готовности фичи к релизу;

• описание выполненных проверок (в виде чекистов или тест-кейсов);

• фиксация информации об окружении;

• изложение наблюдений о поведении, не являющихся явными отклонениями;

• изложение информации об изменении в тестовых артефактах.

В нашей компании на уровне общекорпоративного регламента принято написание такого отчёта после каждой выполненной тестировщиками задачи, что, по нашим наблюдениям, серьёзнейшим образом повышает транспарентность QA процесса и, как результат, общее качество релизов. Однако формирование данного отчёта тоже занимает время. Каковое тоже должно быть учтено. Соответственно, в данной секции я обучал тестировщиков отдельно закладывать время на отчётность при выставлении эстимейтов.

3) Недооценка дефект-циклов

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

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

4) Недооценка из-за комбинаторных взрывов

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

Что делать в таком случае?

Оптимальными решениями «лечения» отклонений от оценки задач мы вывели обязательный и заблаговременный вывод критериев приёмки, рациональное ограничение тестирования с помощью участвующего в проекте аналитика или PM’a, который примет на себя ответственность за выбранные критерии. В ситуациях же, когда комбинаторный взрыв неизбежен, но мы всё равно обязаны осуществить как можно более полное тестирование, к оценке необходимо применять множитель сложности задачи.

5) Недооценка из-за когнитивных искажений

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

Рассматриваемые нами решения борьбы с недооценкой из-за субъективных когнитивных искажений стали следующие:

— Оценка по методологии PERT (Program Evaluation and Review Technique), где даётся не одно единственное число, а разброс оценок, каждая из которых должна получить собственное обоснование и на основе которых должно быть выведено число, наиболее приближенное к истине

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

— Коллективное планирование. Ещё один довольно очевидный, но оттого не теряющий актуальности способ избежать ошибок планирования и приблизить оценку к более объективной. 

6) Недооценка из-за неучтённых регресса/приёмки

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

В условиях срочных проектов мы не располагаем такой роскошью, как регулярные новые релизы с предсказуемыми по количеству и длительности регрессам. И потому планировать такие типы тестирования становится необходимо, исходя из проектных потребностей и возможностей. И здесь нам сильно помогает наша собственная TMS. Как компания, специализирующаяся на тестировании, изначально мы создали систему управления тестированием DoQA для личных нужд хранения и организации тестовой документации. Сегодня, уже доступная всем потребителям, данная система продолжает наилучшим образом удовлетворять моим менеджерским потребностям.

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

7) Недооценка из-за недостаточной декомпозиции

Ещё одно из сделанных нами наблюдений заключалось в том, что качество проседало в тех задачах, которые описывали очень крупные функциональные модули, на тестирование которых уходило более восьми часов. Из скоупа в этом случае зачастую выпадали те или иные проверки, а из внимания тестировщиков — ряд деталей, содержащих по итогу дефекты. Решением здесь стало, во-первых, заблаговременная оценка задачи, и, во-вторых, её разбиение на атомарные с выделением отдельных критериев приёмки в рамках каждой из них. С выведением таковых правил оформления задач, точность оценки каждой из них существенно выросла, как и общее качество тестирования.

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

— При постановке задач на тестирование важно не только указывать, что тестировать, но и то, что мы исключаем из скоупа. Это подход, который называется риск-ориентированным тестированием, позволяет рационально распределить ресурсы и не раздувать оценки.

— Сама оценка тоже должна входить в оценку. Мысль актуальная, скорее, в контексте планирования спринта или проекта, как такового, чем в контексте оценки ресурсов для выполнения отдельной задачи. Однако наш опыт подсказывает, что грамотное стратегическое планирование с проставлением эстимейтов тоже является ресурсозатратной процедурой.

— Никто не работает 8 часов непрерывно. Исследования показывают, что из восьми-часового рабочего дня лишь шесть часов тратятся наиболее эффективно. Как следствие, остаток времени мы рассматриваем, как некоторый резерв.

— Точная оценка работ по тестированию возможна только при сочетании у ответственного за оценку менеджерских навыков, навыков тестирования и знания продукта. Некоторые менеджерские навыки мы открывали как раз в рамках данного обучения. Навыки тестирования у всех наших специалистов, что само собой разумеется, более чем развиты. И остаётся им только максимально включаться в собственные проекты, чтобы внутрипроектный контекст был для них ещё одним из ориентиров в оценке.

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

Что же по итогу?

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

Проведённый воркшоп и установленные на нём правила позволили нам с моей командой синхронизировать подходы к работе с эстимейтами, благодаря чему начала по-настоящему работать и указанная метрика… Но вот честный итог: системно это заработало не везде — и причина не в людях. Здесь мы мы снова касаемся главной особенности работы QA в нашей компании, а именно их разделения между аутсорс и внутренними проектами. 

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

Таким образом на аутсорсе и внутренних проектах, где у меня есть прямой менеджмент, инструмент работает. Я вижу метрику, могу требовать оценки, разбирать отклонения на ретро. Там это живёт и вполне себе работает.

На аутстаф-проектах, где я точка экспертной поддержки, а не руководитель — не работает. Я могу провести обучение, объяснить, показать. Но я не могу встроить это в ежедневную рутину чужой команды. 

А как вы работаете с оценкой времени на тестирование? Присутствует ли в ваших процессах эта метрика и разбираете ли вы от неё отклонения?