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

Други, 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 часа больше, чем Даша. И было так не всегда, а началось пару месяцев назад. Это повод аккуратно разобраться - это Васе стали попадаться задачи такие большие или с Васей что-то случилось.
Главная мысль в том, чтобы смотреть метрику именно вдолгую, а не сравнивать затраты времени на задачу А с затратами времени на задачу Б.

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

#общее

Други, мой испытательный срок в Ламоде завершён 🥳 и я возвращаюсь к стезе написания статей и выступлений на конфах уже с новым лейблом 💪
Первая статья уже вышла, мы собрали реальные кейсы от реальных тимлидов, сдобрили их рефлексией и советами и получилось круто и полезно! 🤓

#саморазвитие #яжменеджер

В этот Шуфутино-жабий день принесла вам еще полезного 🐸

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

1️⃣ Книга "Мама, я тимлид" - лёгкая, простая, небольшая книга для общего представления о работе менеджера, сложностях и вызовах, с которыми сталквается каждый начинающий лид.
2️⃣ Белая книжная полка менеджеров от Стратоплана, которая когда-то начиналась с книги "Как стать менеджером в ИТ". Именно с этой книги началось моё погружение в мир менеджмента.
3️⃣ Черная книга менеджера. Внимание, ненормативная лексика, очень специфическая подача материала. Я эту книгу не читала, но Стратоплан уважаю, поэтому не могу не добавить сюда
4️⃣ Книга "Джедайские техники" от Макса Дорофеева. Не про тимлидство, но про организацию своего времени. Самая крутая книга про личную эфективность, тайм менеджмент и всё, что с этим связано. Крайне полезно для любого менеджера.
5️⃣ Доклад Лёши Петрова о профилировании сотрудников, который я когда-то засматривала и пересматривала. Лёше мой поклон 🤗
6️⃣ Статья про обратную связь от эксперта Я.Практикума. Структурировано, кратко и ёмко. Статья, от которой можно отталкиваться в теме про обратную связь.
7️⃣ Доклад Антона Тациенко про QA лидов. Антон очень здорово раскрыл тему, весьма полезно для начинающих лидов или тех, кто подумывает двинуться в ту сторону.
8️⃣ Подкаст "Переработки и их влияние на эффективность". Когда ты становишься лидом, тема переработок (своих и сотрудников) становится еще актуальнее.
9️⃣ Доклад Марины Куликовой "Ты теперь QA lead, что дальше?". Марина отлично дополняет предыдущие материалы и раскрывает тему становления QA с еще одной точки зрения.
1️⃣0️⃣ Статья про идеальное соотношение – сколько тестировщиков нужно команде проекта? Ведь в задачи лида может входить не только управление уже существующими сотрудниками, но и дизайн новых команд, а как это правильно сделать? С чего начать? Статья мне очень понравилась, там есть и жизненный опыт, и путь, и разъяснение почему и как пришли к такому решению. Решение не является серебряной пулей, но для этого вопроса таких пуль и не бывает 😅
1️⃣1️⃣ Бонус: Доклады с конференции TeamLeadConf - здесь можно найти доклады на те темы, которые в работе лида вас сейчас интересуют. Мне кажется, на этой конференции были раскрыты всевозможные аспекты менеджерства с разных сторон и точек зрения. Крайне полезный пополняемый источник.

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