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

Други, пока еду на 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!
Заходите в бар-кемп, будет здорово!! 🤗

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

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

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

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

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

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

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

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

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

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

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

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

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

Други, продуктивной рабочей недели вам в этот прекрасный понедельник!
Сегодня принесла вам мой рекомендасьон. Все мы любим жизненные истории, особенно, хорошо поданные и пропущенные через призму богатого опыта. А если эти истории еще и из профессиональной области, то вообще крутота! 😎
Мало кто умеет по-настоящему круто писать такие истории и при этом не размазываться мыслью по древу (как я, например, аха-ха)). Поэтому, я особо ценю и с удовольствием читаю таких людей. Не могу не поделиться с вами моей недавней находкой: Тарас Сорока пишет очень жизненные истории. Взять, например, пост про странности некоторых менеджеров. В своей работе я, слава богам, не сталкивалась с такими мелко-мстителями и, кажется, что в IT сфере это редкость. Хотя, кто знает, может мне везло 🤔
Или еще пост про ведение CRM и обзвон клиентов. С этим наверняка многие сталкивались. А ведь, если задуматься, это один из критериев качества сервиса - то, как сотрудники используют внутренние приложения. А если приложение неудобное, долго грузится, сыпет багами и т.д., то закономерно им будут пользоваться неохотно и будут появляться вот такие казусы. Вот вам еще один аргумент в пользу улучшения пользовательского опыта даже во внутренних системах, где на это обычно забивают 😅
А с «болотистыми менеджерами» наверняка сталкивались если не все, то многие. Лично у меня к таким людям всегда двоякое отношение: с одной стороны «как можно так работать, за что ему вообще деньги платят», а с другой стороны есть некое восхищение что ли, «с такими навыками и подходами забраться в руководство и успешно там продвигаться и зарабатывать — это надо еще умудриться…».
В общем, рекомендую годноту! 😎
Пишите в комментах, какие интересные каналы с крутыми сторителингами нравятся вам, давайте делиться полезным!

#мемопауза
Вот вам еще полезного: шаблон роадмапы для любого проекта, пользуйтесь 😅

#ментор #наставник

Други! Предлагаю желающим свою консультационно-менторскую помощь. Это могут быть разовые консультации или серия менторских встреч по темам:
1️⃣ Мануальное тестирование для начинающих: обзор всё-обо-всём, конкретные темы по запросу, практическое применение теории и т.д.
2️⃣ Мок-собеседование для мануального тестировщика любого уровня: если вы не уверены в успехе прохождения собеседований, нужна развернутая обратная связь по итогам, чтобы подтянуть слабые места и т.д.
3️⃣ Процессы мануального и автоматизированного тестирования - построение с нуля, поддержка и обновление, обоснование для руководства и т.д.
4️⃣Начинающие лиды: разберем ваши проблемы и затыки, дам развернутую обратную связь, рекомендации и материалы.
5️⃣Другие темы по запросу (кроме технической стороны автоматизации) - пишите, обсудим.

💵Цена вопроса разовой консультации для моих дорогих подписчиков 5000 4000 за час. Обычно одна такая консультация занимает 2-3 часа.

Для серии менторских встреч цена договорная, пишите, обсудим.

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

👉 По вопросам и за подробностями пишите в комменты или в личку: @OlkaEr.

#мемопауза
В догонку к посту о том, что я узнала за 17 лет в QA 😅

#мероприятия
Появилось время походить по митапам, а тут такое интересное!
Если кто сейчас тут, надо увидеться! 😊

7. QA — это далеко не только баги, но и процессы! Видишь, что в команде что-то неудобно, долго, сложно – предлагай сделать лучше! И не просто предлагай, а победи демона «нормально же работаем».
Отчасти из-за этого пункта я в итоге и пошла по менеджерской стезе, потому что хотела больше влиять на процессы и побеждать демонов более эффективно 💪

8. QA – как многорукий Шива, только не многорукий, а многоликий и не Шива, а…. ну вы поняли 🤪
Будучи в роли QA инженера я поняла, что надо уметь переключать сознание и смотреть на своё приложение с разных точек зрения: с инженерной, как разработчик; с бизнесовой, как заказчик; с пользовательской, как юзер; с точки зрения инженера поддержки и т.д. Это необходимо, чтобы учесть все нюансы и проверить то, что действительно важно.
В роли лида я учу этому подрастающее поколение и ищу таких инженеров, которые могут так переключаться.

9. Время — штука, которой никогда нет. Исходя из принципов тестирования, этот процесс может быть бесконечным, если будут бесконечные время и ресурсы. А такого добра не бывает никогда, поэтому надо хорошо уметь в приоритезацию и креатив и даже пробудившись среди ночи суметь ответить на популярный в собесах вопрос «что делать, если релиз завтра, а на регресс надо 3 дня?».

10. Любовь к QA — это когда ты в своей стихии!
17 лет, и я уже не просто часть цирка, а его весёлый режиссёр. Руководить командой, настраивать процессы и видеть, как всё работает — это мой драйв, мой кайф и моя гордость!

11. Бонусный: QA лид — это когда ты одновременно Шерлок Холмс, нянька и немного злодей из комиксов 👻

А какой ваш топ того, что вы узнали за энцать лет в своей профессии?

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

Привет, други!
Сейчас, в период поиска нового прекрасного места приложения своих сил (спасибо всем, кто откликнулся на предыдущий пост!!), появилось время порефлексировать. А тут еще и на Пикабу поднялась волна «Что я узнал за энцать лет в профессии» (привет пикабушникам). Вот я и задумалась – а что я узнала за свои 17 лет в QA и получился довольно объёмный, аж на два поста, мой топ 10 (даже 11) 😎

1. Терпение — это когда ты уже не орёшь чаечкой, а идёшь заваривать чаёк ☕️
Потому что баг, о котором говорила три спринта назад, что он критичный, а его посчитали минорным и пустили в прод, всплыл у пользователя и теперь вся команда на ушах.
Потому что три созвона наложившихся на время обеда – не беда.
Потому что твой тестировщик хочет повышения, но ничего для этого не делает и только ноет, а ты спокойно выслушиваешь и рекомендуешь что делать и так по кругу.
Потому что на собесы приходят недоджуны с не очень горящими глазами и запросами сеньоров, но не все ведь такие!

2. Детали — это ловушка для перфекционистов, в которой кроется дьявол.
Поехала вёрстка? Ссылка не того цвета? Реальность абсолютно расходится с макетом и требованиями? И вот ты уже три часа доказываешь, что это баг, а не фича, чтобы не получилось, как в п.1. Внимание к мелочам — это когда ты видишь баг там, где остальные видят "нормально же". А еще сюда же бонус – профдеформация! У тебя теперь есть суперспособность видеть баги вообще везде так, что создаётся впечатление, как будто они тебя преследуют 🪲

3. Коммуникация — это искусство не прибить никого и сделать так, чтобы команда работала слажено и на одной волне.
Суметь объяснить разработчику, что его код сломал критичную функциональность, несмотря на его "у меня же всё работает" – это порой виртуозное искусство.
А в качестве лида надо поддерживать мотивацию команды даже в условиях полной жопы вокруг — мой новый уровень дипломатии. Я теперь не просто переговорщик, а еще иногда и террорист, и заложник в одном лице 🥷
А ведь еще и собеседования, и 1-1 и еще много видов коммуникаций и все разные и интересные! И каждый раз что-то новенькое, не соскучишься!

4. Технологии новые, а люди одинаковые и в то же время разные!
Flash умер, React родился, а кнопка "Купить" всё равно не работает, если кликнуть дважды. А разработчику всё еще надо доказать, что это баг (см. предыдущий пункт)!
Вообще в качестве лида я не очень успеваю следить за новыми технологиями и некоторые вещи узнаю от своих тестировщиков. И на встречах помимо прочего мы обсуждаем новинки: что-то я рассказываю, чем-то делятся инженеры. Это очень круто, когда твои тестировщики такие умнички! 🫶

5. Автотесты всё сами сделают, пока ты посидишь на шезлонге с коктейлем? Ха-ха и еще раз ха!
На заре своей карьеры, когда я узнала про существование автоматизации, я была уверена, что автотесты спасут мир. А потом поняла: пока ты пишешь автотест, другие 10 автотестов устаревают и их надо поддерживать. Абсолютно всё не автоматизируешь. Ручное тестирование никуда не денется в любом случае. Нужен правильный баланс, а для каждого проекта и команды этот баланс свой и надо его нащупывать. При чём баланс не статичен, он постоянно меняется в зависимости от миллиона параметров. Особенно важно думать про баланс, когда ты лид и надо и рыбку съесть…и косточкой не подавиться 😅

6. Ошибки — лучший учитель, но непростой… И чем больше людей под твоей ответственностью, тем выше цена ошибки.
Когда ты тестировщик, то самая большая ошибка - пропустить баг в прод. И вот твой баг уже звезда ретро!
Когда ты лид, то ошибки будут и в найме, и в построении процессов, и во внедрении изменений и в коммуникациях с командой/другими лидами. Последствия ошибок будут в потерях денег/времени/сил/хороших кадров.
Но, как и раньше — каждый косяк — это урок, за который хочется сказать "спасибо", но почему-то через зубы 😬

Други! Сегодня я к вам не с новыми идеями, и не с анонсами  конференций, и даже не с мемасиками 😅
Сегодня я в поисках нового прекрасного места работы! Три года в Спортмастере пролетели незаметно и за это время было много всего хорошего, но пора двигаться дальше! 😎
Если в вашей компании есть программа типа "приведи друга" и/или вы знаете, что есть вакансии QA менеджера/лида/хеда и т.п., буду весьма признательна за помощь в переправке моего резюме в нужные руки! Пишите в личку: @OlkaEr

Из рабочего четвергово-утреннего: "не костыль, а развитие функциональности!"

Минутка родственной рекламы 😊
Моя замечательная сестра в поисках нового места работы, если в вашей компании нужен продакт, проджект и иже с ними, закиньте резюмешку, мы будем признательны. Так же ссылочка на её 📱 linkedin

Вкратце от сестры:

Работаю в сфере управления проектами в IT.
Последние несколько лет я занимаюсь следующим:
· создаю лендинги/ мобильные приложения для ивентов
· придумываю и реализовываю функции геймификации и взаимодействия с аудиторией
· подключаю платежные системы, сервисы рассылки, платформы для онлайн-трансляций
· создаю аккредитационные центры деловых форумов (доработка и настройка ПО, создание личных кабинетов, администрирование баз данных, автоматизация рассылок, использование RFID технологий для систем контроля доступа)
· организовываю обучения по использованию ПО

Меня увлекло создание IT продуктов, потому что они делают бизнес-процессы более эффективными и упрощают организацию работы.

Мои сильные стороны:
· Опыт работы с Заказчиками: сотрудничала с компаниями (Авито, Philip Morris, ИКЕА, Adidas, Минфин и многими другими)
· Управление командами: распределенные проектные группы до 20 человек
· Финансовое управление: бюджеты до 100 млн. руб.
· Работа с подрядчиками: поиск, мотивация, контроль
· Проектная документация: составление брифов, планов работ, смет, требований, фич-листов, прототипов (Figma), Use Case и других артефактов.
· Методологии: Agile, Waterfall
· Английский язык: уровень B1.

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

Я открыта новым знакомствам и возможностям.
Со мной можно связаться в телеграмм: https://t.me/polonskaya_n.