Всем привет!

На этой неделе поговорим про метрики: что? как? и зачем?

И у меня для вас супер новость! ⬇️

В пятницу проведу прямой эфир с опытной тестировщицей, которая поделится своим опытом сбора и анализа метрик.
Эфир будет здесь специально для вас😘

И заранее подготовлю традиционную шпаргалку по метрикам.

А если есть вопросы по теме, пишите ⬇️

Итак, встречаемся завтра в 10.00 (Минск/Москва) на прямом эфире по теме Метрики

Записи прямого эфира про Метрики ⬇️
(видео и аудио форматы)

Настя, наша спикер на прямом эфире по метрикам, написала подробный комментарий, и такой замечательный, что я решила его вынести в канал, чтобы он точно не потерялся ⬇️

Не упомянула еще несколько важных моментов, о которых, судя по комментариям, было интересно послушать.
❗️Disclaimer: мой реальный опыт может не совпадать с вашим и вашей ситуацией. Как и те действия и проблемы, которые делали мы в команде могут не подходить вам. Делюсь на тот случай, если хотя бы одному тестировщику добавит идей как можно смотреть на метрики и их использовать!
➡️Как я упоминала на эфире, задача была сокращение баг-бэклога, уменьшение incoming rate (все баги), сокращение количества эскалаций с продакшена. Действий было много, вот только часть из них: анализа первопричин, пересмотр стратегий, создание тест стратегий перед планированием комплексной функциональности, где есть риски просадки по качеству, коммуникация с заинтересованными лицами о необходимости выделять ресурсы на исправление существующих багов, автоматизация и тд. Результат – баг-бэклог сократился на 65%, Incoming rate на 50%, продакшен - 80%
➡️Еще один реальный пример: метрика - время необходимое на регрессию, без ущерба качеству. Действия - пересмотр имеющихся тест кейсов и оптимизация, выделение кейсов под автоматизацию, оценка рисков и возможных зависимостей с другими командами, для оптимизации каждой отдельно взятой регрессии. Время с 5 дней на 3 тестировщиков сократилось до 1 дня на каждого максимум.
➡️Метрика % invalid Automation Failures. В качестве улучшения процесса выделили подгруппы возможных причин ложно-отрицательных результатов (например, когда падение было не из-за реального бага, а необходимости улучшить автоматизацию, стабильности окружения или влияния другой команды), при разборе тестов помечали падения специальным флагом. Построили графики и концентрировались на наиболее проблемных областях. Для каждой причины были конкретные шаги.
✅Sum up: В общем, разных примеров можно собрать много, это только часть из них. Но чтобы развеять мысли что это все делается налегке, и мы в команде только сидим и метрики собираем и анализируем - нет. К сожалению это мы делаем в любую свободную от других задач минуту. Но самое главное - это не забывать, что даже маленькие шаги и желание улучшить процессы, качество будут двигать вас в правильном направлении.

Те самые непонятные вопросы на собеседованиях

Всем привет!
Давно у нас не было рубрики ⬆️

О чем она и что будет, напомню, писала в этом посте

Общие рекомендации, как отвечать на такого типа вопросы здесь

Ну и мой ответ на первый вопрос есть
Второй вопрос и ответ на него вот

А новый вопрос сегодня такой:
Вы начинающий тестировщик на проекте. Работаете недавно и очень хотите себя хорошо показать. Поэтому в пятницу вечером задержались на работе, чтобы провести дополнительное исследовательское тестирование билда - релиз кандидата. Релиз намечен на утро понедельника, то есть на самое начало работы команды.
Все уже ушли домой - команда программистов, другие тестировщики. Ваш лид в отпуске, вернётся только в понедельник. ПМ на время релиза уехал к заказчику.
И вот вы находите критичный баг.
Что будете делать в этой ситуации?)

Ваши ответы и рассуждения пишите в комментариях⬇️

А свою версию я дам завтра 😘

#непонятные_вопросы

Те самые непонятные вопросы на собеседованиях – мой ответ

Итак, напомню вопрос-ситуацию:
Вы начинающий тестировщик на проекте. Работаете недавно и очень хотите себя хорошо показать. Поэтому в пятницу вечером задержались на работе, чтобы провести дополнительное исследовательское тестирование билда - релиз кандидата. Релиз намечен на утро понедельника, то есть на самое начало работы команды.
Все уже ушли домой - команда программистов, другие тестировщики. Ваш лид в отпуске, вернётся только в понедельник. ПМ на время релиза уехал к заказчику.
И вот вы находите критичный баг.
Что будете делать в этой ситуации?)

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

На что бы я обратила здесь внимание:
Первое, вы джун, то есть сами не можете принимать решение. (тут, конечно, ситуацию примеряйте на себя, если вы мидл или сеньор, ход рассуждений и ваших действий будет абсолютно другой)
Таким образом, нам нужно искать ответственное за важное решение лицо. Обратите внимание, как я усложнила ситуацию – ваш тест лид в отпуске, а ПМ уехал в командировку, то есть тоже недоступен. Но давайте здесь подумаем, как бы было в реальной жизни. Лид бы не ушёл в отпуск на время регрессионного тестирования и подготовки к релизу. Должен быть заместитель – обычно в команде есть опытные тестировщики, как минимум один, так что зам точно будет. Для начала к нему можно обратиться, сначала написать, потом и позвонить даже, ведь проблема реально серьезная – критичный баг.
Также хорошая идея была предложена Марией в комментариях – написать в общекомандный чат в мессенджере, то есть по максимуму оповестить всю команду, чтобы принимать решение всем вместе. И это самое первое, что нужно сделать – рассказать о проблеме.
Хотя до этого важно сделать ещё одно – убедиться, перепроверить несколько раз, что это действительно баг, что он серьёзный. А вдруг вы до конца не знаете требований? Просто криво стал билд? Или баг в фиче, которой реально никто не пользуется на проде и она будет удалена из приложения в следующем релизе, заменена на более удобную.

Так что порядок действий в этой ситуации такой:
1. Убедиться, что это точно баг, он критичный для данного релиза
2. Поставить в известность команду или человека, ближайшего к вам руководителя, например, зама тест лида – здесь зависит от проекта, как у вас принята коммуникация.
3. Создать подробный баг репорт в баг трекинговой системе, например, джире, или в месте, где у вас на проекте хранятся отчёты о дефектах.

Что точно не нужно делать в этой ситуации:
1. Писать напрямую (письмом или в менеджере) заказчику
2. Звонить ПМу или лиду, который в отпуске (только если вам не разрешили это делать)
3. Ничего не делать, просто уйти домой и ждать понедельника

Как вам мои рассуждения? Согласны? Что бы добавили или изменили?

P.S. добавлю #непонятные_вопросы во все посты на эту тему, чтобы легче было искать)