#общее #рабочийпроцесс

Други, мы тут с великолепным @NeonAether поучаствовали в подкасте Деплой, поговорили про обеспечение качества, процессы тестирования, автоматизацию и просто лампово поболтали. Посмотреть, поставить лайки и написать комменты можно тут:
📱 Деплой
📱 Деплой (время такое 😅)
И конечно буду рада вашим впечатлениям, вопросам и комментам здесь 😊

Пользуясь случаем, рекомендую всем интересующимся присоединиться к полезному каналу Грамота от Кузьмича, где Саша ака @NeonAether делится опытом автоматизатора-джависта 🤖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Други, долго вынашивала в себе мысли про метрики, настала пора поделиться 😎
И сразу дисклеймер: метрики важны и нужны, как термометр и тонометр в аптечке. С помощью выстроенной системы метрик можно мониторить состояние производственной системы как в целом, так и отдельных её частей, например, качество продукта и процессов. Но тут есть парочка «но». Во-первых, важно понимать для каких целей метрики собираются и на что они влияют. Т.е. надо еще выстроить и поддерживать ту самую систему метрик, подходящую под ваши нужды. Во-вторых, когда метрики напрямую влияют на премии (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️⃣Роман Горбачёв в своём канале пишет про то, как люди проявляют себя через общение и наоборот — как с помощью общения менять себя к лучшему. Читаю Романа уже давно и это, на мой взгляд, один из лучших каналов про софт скилы, при чем не про ИТ, а вообще про жизнь.

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

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