#рабочийпроцесс #яжменеджер

Други, долго вынашивала в себе мысли про метрики, настала пора поделиться 😎
И сразу дисклеймер: метрики важны и нужны, как термометр и тонометр в аптечке. С помощью выстроенной системы метрик можно мониторить состояние производственной системы как в целом, так и отдельных её частей, например, качество продукта и процессов. Но тут есть парочка «но». Во-первых, важно понимать для каких целей метрики собираются и на что они влияют. Т.е. надо еще выстроить и поддерживать ту самую систему метрик, подходящую под ваши нужды. Во-вторых, когда метрики напрямую влияют на премии (KPI) — это не очень хорошая история, т.к. люди сознательно или не очень подбивают «результат под ответ», просто чтобы получить денег, что вполне естественно. Из-за этого метрики перестают показывать реальную картину. Как когда в детстве нагревали градусники в чашке чая, чтобы не идти в школу (кто так тоже делал, признавайтесь) 😅

Выражаю мои благодарности Наташе Руколь ❤️
Она одна из тех, кого я с гордостью называю своим наставником и кто сыграл большую роль в моём профессиональном развитии как менеджера. И именно она собрала очень крутой список, на который я опираюсь каждый раз, когда мне надо построить метрики.

Со временем у меня сформировался и мой список, надеюсь, он тоже будет вам полезен. Пишу я довольно размашисто, поэтому это будет серия постов по 1-2 метрики за раз. Первым эшелоном пойдут метрики для автоматизации тестирования (АТ). Здесь буду рассматривать метрики для всей пирамиды АТ, а не только для UI тестов. Поехали!

Группа метрик №1
Покрытия: кода, требований, ручных тестов, API и т.д.

1️⃣Расчет метрики на примере покрытия кода: ⁠Test Coverage (code) = (Покрытые строки кода / Все строки кода) * 100). В целом покрытие кода юнитами посчитать проще всего и, как правило, это считается инструментом статического анализа кода типа SonarQube.

2️⃣Покрытие требований посчитать сложнее, т.к. для этого необходима культура ведения атомарных требований. Если такое чудо есть, то считаем, что требование покрыто, если на него есть хотя бы 1 АТ (основной позитивный) или если на него есть два АТ (основные позитивный и негативный) - в зависимости от вашего подхода.

3️⃣Покрытие ручных тестов АТ посчитать, как правило, проще, т.к. тесты изначально если ведутся, то ведутся атомарно, иначе они просто неудобны. И соотношение тут, как правило, 1 к 1, но могут быть отклонения из-за особенностей автоматизации. Если есть хотя бы 1 АТ на мануальный тест, значит он считается покрытым.

4️⃣Покрытие API аналогично покрытию требований - хотя бы один позитивный (или один позитивный и один негативный) тест на один метод - значит метод покрыт АТ.

Плюсы метрик: можно верхнеуровнево понимать какой процент кода/требований/тестов/API покрыт АТ, выставить планку для себя и команды, например, покрытие API должно быть не менее 80%, а покрытие кода юнитами должно быть не менее 90% для новых фич. И если планка не выдерживается, это будет видно на метрике и можно будет углубиться внутрь в конкретном месте и посмотреть, что пошло не так, возможно вскроются какие-то проблемы.

Минусы метрик: для сбора некоторых метрик покрытия надо приложить много усилий и поддерживать культуру хранения артефактов (например, покрытие требований). Метрика показывает только цифры и в худшем варианте у вас будут красивые цифры, а внутри будет полный шлак. Например, планка в 80% покрытия API выдерживается, и вы даже не лезете внутрь, а на самом деле внутри тесты из серии проверка на статус-код 200 и всё. Поэтому метрики метриками, а залезать внутрь и проводить ревью всё равно надо 🤓

Меряете какие-нибудь покрытия у себя в проектах?

#яжменеджер #рабочийпроцесс

Други, пока еду на SQAшечку, есть время для следующей части про метрики. Напомню, что первый блок метрик - про автоматизацию (АТ - автотесты).
Группа метрик №1 тут.

Группа метрик №2:
Стабильность АТ.

1️⃣% успешных тестов или Test Pass Rate
Считается как Количество успешных тестов / Общее количество тестов) * 100.
Такая метрика показывает качество кода и тестов для каждого прогона.
Может использоваться как квалити гейт в CI/CD (например, Pass Rate>95% и релиз автоматом катится на прод).
Однако, если тесты постоянно показывают 100% успешность это так же может быть тревожным сигналом. Например, тесты ложноположительны или они слишком простые и не затрагивают сложную логику.
Низкий же процент (примерно меньше 70) точно означает, что необходимо что-то исправлять: либо код очень забагованный, либо (что чаще) автотесты крайне не стабильные, ещё вероятно, что причина в окружении. В любом случае необходимо провести тщательный анализ. Если низкий процент успешности не повышать, то доверие к автотестам будет пропадать, а с ним и весь профит.

2️⃣Количество флаки тестов. Здесь нет простой формулы подсчёта, т.к. первоначально необходимо измерить каждый тест и определить его флаки рейт, т.е. процент фейлов теста по причинам, не связанным с багами функциональности.
Flaky rate (одного теста) = (Количество фейлов / Количество запусков) * 100.
Далее нам надо определиться, какие тесты мы будем считать "Flaky", т.е. пороговый Flaky rate, например, 5%. Т.о. количество флаки тестов - это сколько тестов имеют Flaky rate > 5%.
Так же иногда бывает полезно оценить % флаки тестов от общего числа АТ: (Количество флаки тестов / Общее количество АТ) * 100.

Пример:
У нас есть 100 АТ. 5 из них имеют Flaky Rate > 5% (нашего установленного порога). 5 флаки тестов из 100 - это 5%.

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

3️⃣Среднее время восстановления сломанных тестов.
Считается как среднее время по всем тестам: от получения фейла до прогона с положительным результатом в случае, когда АТ нуждался в починке/актуализации (т.е. падал не из-за бага системы).

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

А как вы меряете стабильность ваших АТ?

#яжменеджер #рабочийпроцесс

Други, SQA была как всегда великолепна! Лучшая конференция для тестировщиков! А пока я еду на Сапсанчике, пишу для вас следующую часть про метрики. Напомню, что первый блок метрик - про автоматизацию (АТ - автотесты).

В предыдущих сериях:
Группа метрик №1 (разнообразные покрытия).
Группа метрик №2 (стабильность АТ).

Группа метрик №3: производительность АТ.

1️⃣Среднее время прогона всех АТ или группы АТ (например, смоук, краткий регресс, полный регресс, группы АТ по функциональности и т.д.) за период времени.
Считается как Суммарное время прогонов / Количество прогонов.
Показывает насколько растёт в среднем время прогона, не пора ли его сокращать, например, за счёт параллелизации. Влезает ли, всё ещё, например, смоук в разумные рамки для пайплайна.
Хорошо бы иметь договоренности о среднем времени на разные виды прогонов и метрикой следить за соблюдением, вовремя предпринимая нужные меры.

2️⃣Среднее время выполнения одного теста в прогоне за N прогонов или за период.
Считается как Время выполнения каждого теста / количество тестов в прогоне.
Это по сути мониторинг: в хорошем состоянии тестов среднее время выполнения одного теста будет примерно одинаковым из прогона в прогон. Но если что-то пойдет не так, будут видны всплески или провалы, с которыми можно уже точечно разбираться.

3️⃣Среднее время выполнения каждого теста на протяжении N прогонов и топ N самых долгих АТ за прогон / за N прогонов.
Считается как Суммарное время прохождения конкретного теста за N прогонов / количество прогонов. Посчитать по каждому тесту и вывести топ наиболее долгих.
Эти два показателя идут вместе, потому что, на мой взгляд мониторить вообще каждый тест не имеет смысла, зато считать среднее время по каждому тесту и сигнализировать о топе самых долгих - будет полезно. Время по остальным тестам может пригодиться при точечных разборах проблем с конкретным тестом.
А сформированный топ медленных АТ - это фактически беклог для оптимизации. А если топ часто меняется, то это повод задуматься и проверить более детально, что происходит. Возможно стенд настолько нестабилен, а может есть другие причины.

А как вы мониторите производительность ваших АТ?

#саморазвитие #общее #синопсис

Други, сегодня, в день труда, только для вас подборка полезностей за последнее время (все ссылки так же добавлены в табличку полезностей, пользуйтесь 😎):

1️⃣Корректируем резюме QA инженера - неплохие рекомендации для резюме джуна, да и не только джуна 🤓
2️⃣Выложили записи докладов с конференции SQA days 35, мой личный топ-3:
👉 Боря Мошнин сравнил стабильность долгой работы в одной компании и карьерную мобильность при работе в разных компаниях со всеми плюсами и минусами
👉 Володя Кочегаров очень интересно рассказал про опыт внедрения и использования ChatGPT для генерации тест-кейсов и много чего еще.
👉 Лёша Пименов круто рассказал про управляемые эволюционные изменения при управлении командой
👉 Остальные доклады тоже были очень круты, программный комитет как всегда на высоте! Каждый может среди докладов найти что-то цепляющее и полезное. Пишите в комментах, какие ваши топ-3 👇
3️⃣Доклад Антона Тациенко с конференции DUMP (2024) "QA лиды и среды их обитания" - про то, кто такие QA лиды, чем занимаются и как можно проявить инициативу, чтобы продвинуться в сторону QA лида.
4️⃣Жиза ИТ руководителя - один из каналов, которые я регулярно читаю, потому что люблю труЪ стори 😅
5️⃣Роман Горбачёв в своём канале пишет про то, как люди проявляют себя через общение и наоборот — как с помощью общения менять себя к лучшему. Читаю Романа уже давно и это, на мой взгляд, один из лучших каналов про софт скилы, при чем не про ИТ, а вообще про жизнь.

Делитесь вашими ценными находками, пополним нашу табличку полезностей!

С праздником вас и хорошего качественного отдыха! 🍻

#яжменеджер #рабочийпроцесс

Други, продолжаем тему метрик (да, я еще не всё сказала 😅)
В предыдущих сериях:
👉 Метрики, применимые только к автоматизации:
1️⃣Группа метрик №1 - разнообразные покрытия.
2️⃣Группа метрик №2 - стабильность АТ.
3️⃣Группа метрик №3 - производительность АТ.
👉 Метрики, применимые ко всем процессам тестирования и обеспечения качества:
🐞Группа метрик №4 - качество кода исходя из количества дефектов.

Группа метрик №5: качество тестовой модели (и ручных и авто тестов)

🐝 Эффективность тестов для обнаружения багов.
Измеряется в процентах исходя из общего количества тестов (ручных или автоматизированных или всех вместе или по какому-то одному модулю - в зависимости от ваших целей) и общего количества тестов, к которым привязаны обнаруженные баги:
Тесты с найденными багами / Общее число тестов * 100%
Метрика хороша для мониторинга на длинных дистанциях и в совокупности с другими метриками.
Например, можно смотреть, что из релиза в релиз у нас примерно одинаковый процент эффективности тестов и при этом примерно одинаковый процент пропущенных в прод багов - значит стабильность. А если процент эффективности тестов падает, при этом багов в проде не увеличивается, возможно стоит пересмотреть состав тестов, например, убирать из постоянного прогона тесты, которые не обнаруживают багов уже долгое время. Интересно, читает ли кто-то мои трактаты, маякни в комменты, если прочитали. Хуже ситуация, если процент эффективности тестов падает, а количество багов в проде растёт - это сигнал о том, что тесты стали менее пригодными и их надо пересматривать и изменять/увеличивать покрытие.

🪰 Кол-во/процент заскипанных тестов.
Здесь также речь идёт о любых тестах - ручных или автоматизированных, суть одна.
Можно считать в абсолютных значениях (10 из 100 тестов скипаются) или в процентах (10% тестов скипаются) - это как вам удобнее.
Заскипанные тесты / Общее количество тестов в прогоне * 100%
Скипать тесты можно по разным причинам, но важно, чтобы со временем эти тесты возвращались в строй или отмирали как ненужные, соответственно, процент заскипанных тестов должен стремиться к нулю, но точно не расти. Если количество пропущенных тестов будет расти, то доверие к этим тестовым прогонам будем падать.

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

Сталкивались с такими метриками? Полезное?

#яжменеджер #рабочийпроцесс

Други, возвращаемся к теме метрик 🤓
В предыдущих сериях:
👉 Метрики, применимые только к автоматизации:
1️⃣ Группа метрик №1 - разнообразные покрытия
2️⃣ Группа метрик №2 - стабильность АТ
3️⃣ Группа метрик №3 - производительность АТ
👉 Метрики, применимые ко всем процессам тестирования и обеспечения качества:
🐞 Группа метрик №4 - качество кода исходя из количества дефектов
🐝 Группа метрик №5: качество тестовой модели

Группа метрик №6: Затраты на мануальное тестирование (прогнозирование и оптимизация)

⏳Среднее время ручного регрессионного прогона.
Измеряется в абсолютных величинах (часах, минутах и т.д.). Для удобного мониторинга отлично подойдёт формат графика, где по оси Х будут идти релизы, а по оси Y - затраченное на ручной регресс время. Туда же можно добавить линию тренда, чтобы лучше было видно куда всё движется - для удобства прогнозирования. Так же хорошо отображать вычисленное текущее среднее значение: Суммарное затраченное время / Количество релизов.
Тут главная проблема - откуда взять данные. Если вы логируете затраты времени, то будет проще. Если нет, можно попробовать вычислить по косвенным признакам, например, взять время, которое релизная задача проводит в статусе для проведения регресса или придумать еще какой-то способ.
Если у вас есть только ручной регресс, то затраты на него будут со временем увеличиваться и этими цифрами можно попробовать обосновать внедрение автоматизации или глобальную оптимизацию подхода к регрессу. На тему оптимизации есть прекрасная статья, которую написала чудесная тестировщица, с которой мне посчастливилось поработать - Ксюша Сергеева (привет тебе! 🤗).
Если у вас уже есть автоматизация, то по этой метрике можно сориентироваться насколько она вам помогает и вовремя предпринять нужные меры.

⏳Среднее время на прохождение одного мануального теста.
Измеряется в абсолютных величинах (обычно в минутах). Лучше всего выводить график и число, аналогично предыдущей метрике. Только по оси Y будет вычисленное среднее время на прохождение одного теста в рамках текущего регресса. А итоговое число будет - общее среднее время на тест по всем релизам.
При хорошем раскладе график должен стремиться к горизонтальной прямой, т.е. среднее время на 1 тест не должно сильно меняться. Но если вдруг происходят скачкИ, то это будет сигнализировать о том, что пора пойти разобраться.
А общее среднее время поможет вам оценить затраты на проведение регресса в зависимости от количества включенных туда тестов, что особенно важно при динамическом наполнении регрессионного скоупа.

⏱️Среднее время на тестирование задачи.
Можно просто вычислить, если вы логируете затраты времени на задачи. Можно также представить в виде графика, где по X будут задачи (или периоды времени), а по Y - затраты времени на задачи (или средние затраты на задачи в течение периода времени) и добавить еще вычисленное среднее значение.
Не кидайте сразу тапками, я понимаю, что все задачи разные и требуют разного времени и это выглядит, как вычислять среднюю температуру по больнице. Но давайте разберёмся! ✋
На длинных дистанциях такой показатель может помочь вам сориентироваться в верхнеуровневых оценках задач.
Для менеджера будет не лишним считать эту метрику в разрезе тестировщиков. К примеру, смотрю, что Вася тратит на задачу в среднем на 4 часа больше, чем Даша. И было так не всегда, а началось пару месяцев назад. Это повод аккуратно разобраться - это Васе стали попадаться задачи такие большие или с Васей что-то случилось.
Главная мысль в том, чтобы смотреть метрику именно вдолгую, а не сравнивать затраты времени на задачу А с затратами времени на задачу Б.

Есть у вас на проектах что-то похожее? Может что-то более экзотическое? Делитесь в комментах 👇