Очень интересно, только плакать хочется

это напоминалка, что если вы хотели на курс, то сегодня последний день можно вписаться по ранней цене:)

в прошлом году проводила эксперимент по непостановке целей, и он удался

не в том смысле, что я достигла чего-то огого, чего и не могла бы придумать, а в том смысле, что мне понравилось 🙂
это интересное исследование, а что же мне нравится, а куда мне хочется, а где мне интересно, а кто со мной резонирует. оказывается, если перестать соревноваться с голосами в своей голове, то получается лучше слушать себя. а если ещё отписаться от людей, чья достигаторская культура взращивает в тебе комплексы недостаточного достигаторства (“да я поздно начала”, “да у меня нет такой базы”), то нащупывается что-то по-настоящему твоё.

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

в общем, в новый год я вплыла с 2 целями: быть здоровой (очень нужно сейчас) и продолжать исследовать свои интересы. а они сейчас лежат в творческой зоне: ZenTest, курс для лидов (напоминалка, что ранняя цена действует до пятницы), шпаргалка по промптам для менеджерских задач, текстовый курс по процессам для самых маленьких.

с новым годом 🎄

расскажу немного про то, кому будет полезен курс «Искусство обеспечения качества»:

- тем, кто уже лидит, недавно или давно: будет возможность и структуризировать информацию, и вернуться к основам, чтобы ещё раз посмотреть на свои процессы. в каждом вебинаре будут задания, где можно отработать разные подходы в условиях симуляции, и шаблоны, которые можно забрать себе в работу, чтобы пробовать на реальном проекте то, что будем обсуждать.

- тем, кто «сам себе лид»: будет уделено много внимания построению процессов, в том числе будем обсуждать подходы, которые помогут быстро и малыми силами изменить процесс в лучшую сторону. также будем разбирать метрики, чтобы не пришлось тратить время на ненужные усилия. не всё из курса будет применимо в условиях, когда надо и тестировать, и улучшать процессы, но базу можно взять.

все материалы останутся у участников, к ним можно вернуться, если появится необходимость доразобраться потом в условиях работы. информация многоуровневая — и основы, и продвинутая работа с инструментами в условиях ограничений.

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

так что если вам актуально и интересно, форма записи тут, ранняя цена действует до 10 января. если нужна оплата частями или от юрлица, это возможно.

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

просто скажу спасибо вам, что были тут, что приходили на косультации и обучения, что читали и комментировали посты.

пусть впереди будет много интересного, а плакать хочется только от радости ✨

ну что, обновлённый курс “Искусство управления качеством” будет. старт группы в феврале, расписание пока формируется. в этот раз будет больше фокус на процессную часть, поэтому вебинаров по процессам будет 7 (и ещё бонусный воркшоп, как собственно эти процессы запихивать в реальность), по людям поговорим о самой базе: про команду и руководство, остальное будет в виде записей с прошлого потока + лаборатории для групповых работ по этим темам.
до 10 января действует скидка 10% на все тарифы, запись тут

о зрелости руководителя думала в разрезе всех своих работ

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

а можно делать вид, что понимаешь, и тогда со стороны как будто правильные вещи говорятся, но работа по факту строится с полным игнорированием факта этой разности. все эти попытки унифицировать и оценить по единой линейке разных специалистов (разных в том смысле, что сравнивать девелоперов с аналитиками, команды между собой и тп). рассказы, что «можно быть любым», но по факту надо соответствовать негласным обычаям и правилам (как мне однажды сказал один рекрутер — «нам нужен кандидат, у которого руки уже сломаны в нужных местах»). декларирование одних ценностей, а реализация совершенно других.

и в итоге, приходят неготовые люди: им говорят «можно быть собой», а потом измеряют их количеством закрытых тасок и скоростью чтения документации, и у всех разочарование.

а достаточно-то всего лишь обращать внимание на человека, разговаривать с ним и убрать размерную сетку перед глазами. впрочем, понимание, что все люди разные, к сожалению, идёт в комплекте с несовершенством мира и знанием, что незрелых менеджеров было, есть и будет много 🥲

продолжим про разные практики в рамках процессов, которые могут помогать нам достигать целей (а могут и мешать). предыдущие практики тут и тут

Risk-Based Testing
что это?
метод, где тестирование фокусируется на самых рискованных частях продукта, а менее рискованные зоны проверяются поверхностно или игнорируются. критичность и уровень риска определяются перед тестированием и зависят от ряда параметров, то есть не является константой.

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

где уместно:
- проекты с ограниченными ресурсами;
- сложные системы, где невозможно протестировать всё.
- проекты, на которых исторически не было тестирования, но надо откуда-то начать.

как кастомизировать:
- если команда небольшая: фокусируйтесь только на зонах, критичных для пользователей и/или бизнеса.
- если у тестировщиков недостаточно информации для оценки рисков: привлекайте другие роли к этой задаче.

Crowdtesting
что это?
тестирование продукта с привлечением внешних специалистов или реальных пользователей.

как применять:
- выберите платформу или способ для привлечения к тестированию.
- сформулируйте задачи для тестировщиков (например, проверить UX или кросс-платформенность или поисследовать определённые области приложения).
- анализируйте отчёты и сортируйте найденные баги.

где уместно:
- b2c-продукты с глобальной аудиторией;
- приложения, требующие проверки на разных устройствах.

как кастомизировать:
- если бюджет ограничен: фокусируйтесь на одной задаче (например, тестирование на мобильных).
- если нужна глубина: выделите сложные сценарии и предоставьте больше деталей.
- если тестирование регулярное: выстраивайте отношения с постоянной группой краудтестеров.

Bug Bash (совместный поиск багов)
что это?
тестировочный "хакатон", где вся команда участвует в поиске багов.

как применять:
- выберите цель (например, проверить новую фичу или наоборот пройтись по старой функциональности).
- установите ограничение по времени (2–3 часа).
- добавьте геймификацию: награды за найденные баги.
- зафиксируйте результаты и распределите задачи.

где уместно:
- перед крупными релизами;
- проекты с большим количеством изменений.

как кастомизировать:
- если команда небольшая: фокусируйтесь только на критичных зонах.
- если релизы редкие: используйте bug bash как финальную проверку.
- если времени мало: сделайте упрощённую версию с минимальными требованиями.

Аукцион багов
что это?
метод, где баги "оцениваются" в очках или баллах в зависимости от их критичности. команда совместно решает, какие баги "купить" (то есть исправить) в первую очередь.

как применять:
- создайте список багов с оценкой их влияния и сложности исправления.
- присвойте очки каждому багу, например:
1–3 очка для мелких;
5–10 очков для критичных.
- проведите встречу, где команда "торгуется" за баги, которые войдут в текущий спринт.
- выделяйте фиксированное время на работу с аукционными багами (например, каждая вторая пятница).

где уместно:
- команды с перегруженным багами бэклогом.
- команды с ограниченными ресурсами.

как кастомизировать:
- если багов слишком много: фокусируйтесь только на новых или бизнес-критичных ошибках.

#процессы

ну и расскажу нормально про ближайший тренинг

Тренинг по проведению аудита процессов тестирования

Когда: 10-11 декабря, в 18.00 мск. Длительность встреч: 1,5-2 часа.
Формат: Вебинар в Zoom с теорией и практическое занятие с симуляцией аудита в группах.
Контент: Цели, этапы аудита, подходы к сбору информации, инструменты формирования и анализа гипотез. Разберём классический подход к аудиту и подход через эвристики тестируемости Баха. На практике разберём инструменты 5 почему, диаграмма Исикавы, causal loop diagrams.
Практика: В рамках симуляции аудита будет описание проекта с набором данных по метрикам. В группах под контролем тренера будет анализ проблемных мест, проверка гипотез, выработка рекомендаций. В конце проведём разбор нескольких решений.
В результате: Теоретические подходы, практика в группах, шаблон плана аудита, список метрик для оценки процесса, описание техник и инструментов, гайд под вопросам для аудита тестируемости. Сертификат о прохождении на русском или английском по желанию.

Варианты участия:
- Только текст. Все текстовые артефакты (шаблон, метрики, техники, гайд), конспект теоретического материала после проведения тренинга. 5000 руб. / 50 евро
- Стандарт. Вебинар, практическое занятие в группах, после — запись вебинара, конспект теории, текстовые артефакты. 10000 руб. / 100 евро. Осталось 2 места.
- Индивидуальный разбор. То же, что в стандарт + мой разбор самостоятельно проведённого аудита в течение недели после тренинга (задание то же, что для групп). 15000 / 150 евро. Осталось 1 место.

Запись тут

Очень интересно, только плакать хочется pinned «пришло время для нового поста в закрепе 🙂 Привет! Меня зовут Наталья Петровская. Я Head of QA, Engineering manager в процессе переосмысления своей карьеры. Управляла командами тестировщиков до 50 человек с разными профилями в матричной структуре. Умею строить…»

пришло время для нового поста в закрепе 🙂

Привет!

Меня зовут Наталья Петровская. Я Head of QA, Engineering manager в процессе переосмысления своей карьеры. Управляла командами тестировщиков до 50 человек с разными профилями в матричной структуре. Умею строить процессы обеспечения качества на проектах разного размера, сложности и длительности. Люблю кастомизировать практики под конкретную ситуацию и не верю в универсальные решения и правильные ответы.

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

Выступаю на конференциях онлайн и оффлайн на русском и английском, участвую в ПК SQA Days, где помогаю отбирать и готовить доклады (курирую секции Тест менеджмент, Страт менеджмент, Soft skills, ко мне можно прийти с вопросами по докладам). Посмотреть записи выступлений можно тут.

Пару лет админила сообщество QA Sisters, но в прошлом году жёстко выгорела и перестала. Придумала и дважды провела QA Sis Conf, где выступили почти 50 прекрасных женщин.

Вместе с Олей Артемьевой делаю клуб бережного саморазвития для тестировщиц ZenTest, где мы много рефлексируем и ищем то, что нам подходит, а также боремся с FOMO в части развития карьеры.

Веду этот канал о своей работе в формате старого-доброго жж, хотя стараюсь периодически писать и полезное.
Немного тегов канала: #процессы #онбординг #метрики

Из нерабочего — пою в хоре и сольно, танцую на каблуках, экспериментирую с живописью маслом, читаю книжки, люблю цветочки (и стараюсь их не угробить), веду канал своей кошки.

ну и небольшой анонс ZenTest

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

цена 1500р/15е, остальные подробности и запись тут

разбор полезных практик для процессов продолжим чуть позже, а пока вечно актуальное — про поиск баланса и профилактику выгораний.

как лидам помочь команде сохранять баланс и не выгореть? без «команда — это семья» (кто-то ещё верит в это?), без опеки, без гиперконтроля.

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

1. границы — это святое
не дёргайте людей в нерабочее время, если только офис не затопило. хотите, чтобы сотрудники отдыхали? начинайте с себя: не пишите им в выходные и не переносите совещания на поздний вечер.

2. отпуск — это отдых, а не смена фона для работы
отпуск — значит отпуск. просить кого-то быть «на подхвате» или отвечать на письма с пляжа — путь к выгоранию. организуйте работу так, чтобы человек мог отключиться на 100%.

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

4. не невротизируйте с немедленными ответами
заведите правило: не ждать ответа на письма и чаты сразу же. не нужно создавать ощущение, что все в любой момент должны бросить текущую задачу и отвечать на вопросы. дайте людям работать в потоке.

5. гибкость — не привилегия, а норма
дайте людям возможность работать, когда они максимально продуктивны. кто-то лучше работает с утра, а кто-то после обеда. если это не мешает результату, почему бы и нет?

6. не превращайте переработки в норму
переработка — это не признак «вовлеченности», а сигнал о том, что объём работы чрезмерен. следите за дедлайнами, планируйте нагрузку и не сгружайте всё на одного человека.

7. хобби и жизнь за пределами офиса — это важно
заведите традицию делиться увлечениями. например, пятиминутки на дейликаз, где можно рассказать, что нового кто-то выучил, куда сходил, что попробовал. покажите, что жизнь — это не только работа.

8. если люди боятся понедельников, разберитесь почему
синдром «страшного воскресенья» у команды — тревожный звоночек. чаще всего это из-за перегрузок, проблем в коллективе или ощущения, что их труд недооценен. обращайте внимание, какое настроение в команде по понедельникам и пятницам, какие мемы люди постят во флудилку. поговорите с людьми и начните решать проблему точечно.

всё это — не про «быть хорошим лидом», и не про дешёвую популярность (в какой-нибудь из следующих серий поговорим, что делать с собственным начальством, которому пофиг на ваш баланс), а про создание среды, где люди работают с удовольствием. если команда выгорает, выгорает и результат.

продолжим про #процессы рассказом про разные практики, которые используются для построения тестирования и обеспечения качества

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

3 амиго
что это?
практика, где аналитик (или ПО), разработчик и тестировщик обсуждают фичу до начала разработки. их задача — вместе разобраться в требованиях и заранее продумать сценарии тестирования.

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

как применять:
соберите "3 амиго" на этапе планирования фичи.
обсудите:
- что фича должна делать;
- как её будут разрабатывать и тестировать;
- какие могут быть риски или ограничения.
- зафиксируйте результаты: требования, тест-кейсы, возможные проблемы.

где применять:
- проекты с гибкой разработкой (agile, kanban);
- команды, где часто возникают проблемы с требованиями или сценариями.

как кастомизировать:
- если команда маленькая: объедините роли — разработчик и аналитик могут выполнять часть задач тестировщика.
- если у команды нелюбовь к митингам: проводите обсуждения асинхронно (например, в документах с комментариями).
- если время ограничено: фокусируйтесь только на самых сложных или критичных фичах.

Shift-Left testing
что это?
тестирование начинается ещё до написания кода: тестировщики подключаются к ревью требований, планированию архитектуры и делают тест дизайн на ранних этапах.

как применять:
- проводите ревью требований с командой (например, на встречах 3 амиго).
- определите критерии готовности для задач (definition of ready).
- делайте тест-дизайн и тест-анализ до или параллельно с разработкой.
- автоматизируйте тесты и запускайте их как можно раньше, внедряйте автоматизированные quality gates.

где уместно:
- проекты, где исправление багов на поздних этапах слишком дорого обходится;
- команды с быстрым ритмом разработки;
- проекты с чувствительным TTM.

как кастомизировать:
- если команда маленькая и вы только начинаете: начните с участия тестировщика в планировании спринтов.
- если нет автотестов: начните с unit-тестов, внедряйте их постепенно, начиная с критических зон.
- если требования постоянно меняются: фокусируйтесь на обсуждении рисков и критичных сценариев.

Zero Bug Policy
что это?
жёсткий, но эффективный подход: никаких багов в backlog-е. если баг найден, он либо исправляется сразу, либо отклоняется как нерелевантный.

цель:
снизить количество "залежавшихся" багов и фокусироваться на качестве текущей работы.

как применять:
- выделите время в спринте для исправления багов.
- установите критерии: какие баги критичны и требуют немедленного исправления, а какие можно закрыть.
- не бойтесь отклонять баги, которые не влияют на пользователей или бизнес.

где уместно:
- небольшие команды, где можно оперативно исправлять ошибки.
- проекты с высоким темпом и формализованными требованиями к качеству.

как кастомизировать:
- если багов уже слишком много: примените zero bug policy только к новым багам, постепенно очищая старый backlog.
- если команда перегружена: введите понятие "порогового количества багов" (например, не больше 10 в трекере).
- если заказчик требует сохранять все баги: архивируйте неактуальные, чтобы они не мешали работе.

продолжение ниже

начало ^

Exploratory Testing
что это?
тестировщик изучает продукт без заранее написанных сценариев, пытаясь найти проблемы на основе опыта и логики.

как применять:
- выберите цель (например, проверить UX новой фичи).
- выделите время на исследование (обычно 60–90 минут).
- фиксируйте находки: баги, идеи для улучшений, странности.

где уместно:
- перед релизами, чтобы проверить продукт глазами пользователя;
- проекты с большой функциональностью, где не всё покрыто формальными тестами.

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

Shift-Right Testing
что это?
практика, где тестирование выполняется (как минимум частично) после релиза: анализ поведения системы и пользователей на продакшене.

как применять:
- внедрите канареечные релизы: выкатывайте обновления на небольшую часть пользователей.
- используйте feature toggles, чтобы включать и отключать фичи на проде.
- настройте мониторинг и алерты для ошибок и аномалий.

где уместно:
- b2c-продукты с широкой аудиторией;
- проекты, где сложно воспроизвести реальные условия на тестовых средах.

как кастомизировать:
- если аудитория небольшая: проводите ручное тестирование на продакшене перед масштабным релизом.
- если нужно больше данных: интегрируйте аналитику пользовательского поведения.

Continuous Testing
что это?
тесты запускаются автоматически на каждом этапе разработки: от коммита кода до релиза. это часть CI/CD pipeline.

как применять:
- автоматизируйте unit-тесты для проверки базовой логики.
- настройте запуск функциональных и интеграционных тестов при каждом изменении кода.
- подключите e2e тесты для проверки работы приложения перед релизом.

где уместно:
- проекты с регулярными релизами (например, SaaS или мобильные приложения);
- команды, которые хотят ускорить разработку.

как кастомизировать:
- если команда не готова к полной автоматизации: начните с простых smoke-тестов.
- если pipeline сложный: добавляйте автоматизацию постепенно, начиная с самых критичных зон.
- если релизы редкие: запускайте тесты только для крупных изменений.

Dogfooding
что это?
практика, где команда сама использует продукт, который разрабатывает, чтобы понять его слабые стороны.

как применять:
- предоставьте команде доступ к продукту как пользователям.
- определите реальные сценарии использования (например, тестировщики оформляют заказы, если это e-commerce).
- собирайте фидбэк от команды: что неудобно, что не работает, что вызывает вопросы.

где уместно:
- внутренние инструменты или продукты, которые команда использует сама;
- стартапы, где важно понимать продукт "изнутри".

как кастомизировать:
- если продукт используется командой ежедневно: введите отдельные "дни фокусного использования", чтобы искать конкретные проблемы.
- если команда не является целевой аудиторией: подключайте внешних пользователей к dogfooding.
- если продукт технический: предоставьте команде тренировочные сценарии для освоения системы.

все эти практики — не что-то, что нужно всем и везде, но в нужном контексте они могут улучшить #процессы.

ну и напоминалка про тренинг по аудиту. сегодня последний день ранней цены, осталось всего 3 места на стандартный тариф. поисследуем, какие у нас есть проблемы и можно ли их решить какими-нибудь известными практиками.

продолжим про #процессы

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

ниже пошаговая инструкция-шпаргалка, за что хвататься, если непонятно, как начать.

шаг 1: начните с цели — как и с анализом существующих процессов
первый вопрос, который нужно задать: зачем вам тестирование?

например:
если цель — сократить баги на проде, процесс нужно построить вокруг решения проблемы, откуда они там вообще берутся.
если цель — ускорить релизы, фокус будет на скорости выполнения работы, уменьшении бутылочных горлышек и сокращении feedback loop.

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

шаг 2: выделите критичные зоны продукта и приоритетные риски, которые нужно покрыть
тестировать всё подряд — невозможно. начните с того, что для вашего продукта важно.

примеры:
почти везде критично всё, что связано с авторизацией, оплатой и прямым использованием приложения в рамках основных функций (в магазине купить, в навигаторе найти адрес и построить маршрут, в видео-плеере посмотреть видео).

совет: составьте список ключевых пользовательских сценариев (например, "пользователь добавляет товар в корзину"). эти сценарии станут основой вашего тестирования.

шаг 3: выберите минимальные практики
не перегружайте процесс с самого начала. начните с базового набора, решающего основную цель в рамках критических областей

например:
smoke-тесты
ручное тестирование ключевых фич
минимальная документация (чек-листы или простые таблицы)
unit-тесты

совет: не тратьте время на сложные тест-кейсы или отчёты, пока процесс не отлажен, не стройте “вечные” конструкции там, где надо быстро добиться успеха.

шаг 4: впишите тестирование в процесс разработки
тестирование не должно быть отдельной чужеродной фазой. оно должно быть встроено в цикл разработки.

как это сделать:
договоритесь о Definition of Ready: когда тестировщик подключается к работе над фичей?
обозначьте критерии окончания тестирования: так все будут понимать, что именно вы планируете делать в рамках каких задач.
планируйте тестирование в рамках цикла: если команда работает в спринтах, то интегрируйте тестирование в них же; если релизными циклами, то проверьте, что в цикл влезает то, что вы запланировали.

совет: обсудите с командой и менеджментом, как тестирование будет вписано в существующий ритм работы и надо ли его как-то адаптировать (спойлер: скорее всего надо).

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

примеры инструментов:
bug tracker — чтобы фиксировать баги (например, Jira).
TMS — даже Google Sheets подойдёт для начала (но если есть возможность, то лучше сразу что-то более адаптированное).
инструменты отчётности / сбора статистики — хотя бы в рамках bug tracker / TMS.

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

шаг 6: постепенно развивайте процесс
процесс тестирования — это не что-то статичное. он будет меняться вместе с продуктом и вашим пониманием ситуации.

как развивать процесс:
анализ проблем, анализ метрик, вот это всё, что делается в рамках аудита собственного процесса
цикл деминга для внедрения изменений

совет: каждые 2-3 месяца пересматривайте процесс: что работает, а что нет.

готово, вы великолепны!

ну и основной совет: главное — начать. процесс будет развиваться, когда вы поймёте, что работает, а что нет.

ps. на тренинг внезапно осталось совсем немного мест, поэтому если вы думали попозже, то может быть уже не в этот раз. группа будет камерная, чтобы комфортно было работать.

продолжим про декомпозицию процесса тестирования

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

декомпозиция процесса — это разбиение его на ключевые элементы, которые выполняют свои уникальные задачи. это поможет работать с каждым элементом по отдельности и как с частью системы.

примеры таких элементов:

1. цели тестирования
первая и самая важная часть — зачем вы вообще тестируете продукт?

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

цель может быть разной:
- минимизировать баги на проде;
- ускорить релизы;
- проверить гипотезу (например, для mvp);
- улучшить пользовательский опыт.

2. сценарии и типы тестов, подходы к тестированию
вопрос: какие тесты вы проводите и зачем? как эти тесты матчатся с заявленной целью и решают проблемы?

примеры типов и подходов:
- функциональные. проверка, работает ли продукт по требованиям.
- регрессионные. убедиться, что новые изменения не сломали старый функционал.
- нагрузочные. оценка производительности под высоким трафиком.
- exploratory. исследование продукта для поиска неожиданных багов.
- shift-left. тестирование максимально приближенное к началу разработки.
- shift-right. тестирование сдвинутое за релиз.
- автоматизация. на всех уровнях от юнитов до ui-ных е2е.

3. место тестирование в sdlc
вопрос: как тестирование вписано в общий процесс разработки? оно с ним гармонично или выбивает всё из колеи?

примеры:
- тестирование интегрировано во все фазы sdlc. например, тесты запускаются автоматически при каждом коммите, требования проходят qa ревью. требуется высокая синхронизация с командой разработки.
- в конце паровоза. команда проверяет готовые фичи перед релизом/в конце цикла.

4. документация
вопрос: как вы фиксируете, что и как тестировать, и что и почему не тестировать?

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

5. инструменты и автоматизация
вопрос: какие инструменты используются для тестирования? почему именно они? как они помогают достичь целей тестирования?

примеры:
- tms. где хранятся и трекаются тесты, как устроена общая работа с ними.
- автоматизация и её инструменты и подходы. что, как и на каком уровне автоматизируется.
- инструменты оптимизации. как организована работа с БД, API, моки, стабы и прочее.
- CI/CD. как организован запуск и анализ тестов.

6. команда и роли
вопрос: кто отвечает за тестирование? а за качество? а знают ли они об этом?

примеры:
- выделенная команда QA;
- shared-responsibility — тестируют все (разработчики, аналитики, QA);
- внешний тестировщик или краудтестинг.

7. метрики и фидбэк
вопрос: как оценивается эффективность тестирования? имеет ли это отношение к целям из первого пункта? а к процессу работы?

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

#процессы

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

на интервью лидов часто встречается вопрос “как выглядит идеальный процесс тестирования?” так, как его описывают в учебниках? так, как вас научили на проекте, где всё работало? идеальная документация, полное покрытие тестами, баги фиксятся мгновенно...

звучит прекрасно, правда? в реальности, конечно, никакого идеального процесса просто не существует. не потому что нельзя писать документацию хорошо или не копить бэклог багов. просто “что такое хорошо” везде будет разным.

и для меня идеальный процесс тестирования (и чего угодно ещё) — это подходящий процесс. тот, который работает именно в ваших условиях: с вашими дедлайнами, командой и продуктом.

главное понять: процесс тестирования — это не статуя. его нельзя высечь один раз и любоваться вечно. он гибкий, меняется вместе с контекстом и требует регулярной настройки.

поэтому основной вопрос: а как понять, что ваш процесс подходит под текущие условия?

процесс тестирования — это как одежда: в жару вы не наденете шубу, а в дождь не выйдете в сандалиях. так же и с тестированием: подход зависит от проекта, команды и целей.

вот три типичных примера:

- proof of concept. забудьте про формальности: цель — проверить гипотезу, а не гарантировать идеальное качество.
- стартап на стадии mvp. минимальное тестирование: smoke и несколько регрессий. зачем? чтобы быстро доставлять продукт, не утонув в документации.
- крупный корпоративный проект. тут без проработанных тест-кейсов, чётких процессов и автоматизации никуда. иначе хаос.

процесс тестирования всегда зависит от контекста. более того, что подошло на старте проекта, может стать тормозом через год.

дальше поговорим, как декомпозировать процесс для анализа, как построить процесс с нуля, как анализировать его и адаптировать под разные проекты.

#процессы

о важности бытия собой

иногда работы требуют от нас чего-то, чего мы не готовы им в данный момент дать. очень важно это вовремя отловить, оценить и решить для себя, надо ли пересмотреть свои возможности и приоритеты, или не надо. честность с собой в вопросе «зачем мне это надо» всегда мне помогала решить, хочу ли я сейчас продолжать прикладывать усилия и что я от этого собираюсь получить. так у меня минимизируются всякие «не ценят мой вклад», потому что в первую очередь я решаю, зачем этот самый вклад мне самой. и даже выгорев сто раз, я вижу ценность в своём опыте и чувствую кайф и гордость за свои свершения.

но в определённой точке пространства и времени становится очевидно, что лучше просто отойти и не делать то, чего делать не собиралась. и в этом тоже кайф, и это тоже ощущается как победа, когда выбираешь себя, а не чьи-то ожидания (пусть даже ожидания себя самой в прошлом).

я хотела саббатикал, и, ура, он у меня таки будет! и будут силы на всякие штуки, которые пылятся в заметках и черновиках, и скорее всего будет перезапуск обновлённого лидского курса.

и я проведу-таки тренинг по аудиту процессов, который обкатала на TestCon. программа и страничка на сайте появятся чуть позже, а пока есть возможность записаться со скидкой.

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

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

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

и насколько я, оказывается, привыкла уже к запросам по менеджменту, и как, оказывается, взрывается мозг, когда надо смотреть на запрос в другой перспективе. впрочем, спустя минут 10 в моей голове всё разложилось по полочкам, маркетинговая база всплыла по ключевым словам, варианты «как сделать нормально» и «как обойтись подручными средствами» стали формулироваться.

в итоге менти довольна, я в шоке:) классный опыт, спасибо Оле за доверие и эту возможность🤍

#менторинг

есть штуки, которые «господи зачем я в это ввязалась», а потом такой кайф. этот воркшоп по эффективности процессов был ровно таким: сначала немного непонятно и нервно, потом у всех вскипел мозг, а потом все азартно клеили стикеры, искали ресурсы и гениально опитимизировали.

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

начало ^

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

эффективность стратегии работы с рисками (цель: уменьшать количество рисков, про которые мы не знаем)
в условиях аутсорса главное, что интересует бизнес с обеих сторон — соблюдение сроков и непревышение бюджетов. для того, чтобы с этими показателями работать со стороны обеспечения качества, стоит вкладываться в хороший менеджмент рисков и правильную их коммуникацию.

количество и серьёзность багов найденных клиентом (цель: лучше меньше и/или минорнее)
важной метрикой становится обратная связь от клиентов, которая может выражаться в проценте закрытых проектов, которые были приняты без доработок или процент задач, в которых заказчик доволен качеством с первого раза.

тестовое покрытие по критическим фичам (цель: 100%)
фокус на тех компонентах, которые для клиента являются критичными. здесь важно следить за тестовым покрытием именно по этим частям системы, потому что сбои в них могут стоить гораздо больше, чем баги в менее значимых местах.

среднее время реакции на инциденты после релиза (цель: попадать в ожидания)
скорость решения инцидентов от клиента напрямую влияет на удовлетворённость клиента. метрика помогает оценить, насколько эффективно работает команда с этой частью процесса.

вывод
выбор метрик зависит от того, какова цель и специфика компании. стартапы сфокусированы на скорости и минимизации критичных проблем, продуктовые компании на стабильности и долгосрочном качестве, аутсорс – на удовлетворении клиента при ограниченных ресурсах. каждое направление требует своего подхода к метрикам, и важно не забывать пересматривать их по мере изменения ситуации.

предыдущие посты про метрики
1, 2, 3

на этом пока про метрики закончу, но если есть вопросы, пишите, распишу дополнительно.
главный вывод всех этих полотен текста: не считайте ради цифр. метрики — это просто инструмент. если вы понимаете, как извлечь из него пользу, она будет, если нет — не будет.

#метрики

метрики качества для стартапов, продуктовых компаний и аутсорса

настраивать метрики под специфику бизнеса – это важный момент, который многие упускают из виду. не бывает универсального набора метрик, который идеально подойдёт всем. стартап, продуктовая компания и клиентская разработка (аутсорс) требуют разных подходов, потому что цели и ресурсы у них совершенно разные.

дисклеймер: ниже приведены только примеры, они не применимы для любой компании в вакууме, а даны как отправная точка, о чём можно подумать, когда собираете свой набор метрик.

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

Количество багов с приоритетом Critical+ на проде (цель: тренд не должен расти)
важнейший показатель для стартапа – это отсутствие серьёзных сбоев в проде. критичные баги, влияющие на бизнес, – это красный флаг. важно следить за трендом: если он растёт, нужно принимать меры.

Test reliability: процент багов на демо/проде, некоррелирующих с проведёнными тестами (цель: тестировать то, что нужно)
эта метрика показывает, насколько тестирование отвечает реальным потребностям пользователей продукта. если баги на проде не связаны с тем, что тестировалось, значит, что-то идёт не так с процессами или тестовым покрытием.

Time to test (цель: тренд не растёт или падает)
время на тестирование должно либо оставаться стабильным, либо уменьшаться. для стартапа важно сохранять гибкость и не тратить слишком много времени на проверки, которые могут тормозить релизы. если время на тесты растёт, возможно, это сигнал к тому, чтобы оптимизировать процессы.

продуктовая компания
в продуктовой компании ключевая цель – это стабильность и улучшение качества в долгосрочной перспективе. здесь важно отслеживать и процессы, и результат. вот несколько метрик, которые помогут удерживать баланс:

Test coverage + requirements traceability quality (цель: высокое покрытие требований + высокое качество покрытия относительно требований)
тестовое покрытие можно отслеживать по-разному: от процента фичей, протестированных до выхода в прод, до степени покрытия тестами различных уровней (юнит, интеграционные и т.д.). важно, чтобы команда чётко определила, что для них значит "протестировано", и следила за этим.

% of Declined issues (цель: невысокий, тренд не растёт)
важно не только находить баги, но и следить за тем, насколько они релевантны. declined баги (дубли или "работает как задумано") не должны превышать 10% от общего числа. если их больше, это может сигнализировать о проблемах с требованиями, их пониманием командой или коммуникацией внутри команды. или о том, что наш беклог не очень хорошо себя чувствует и в нём сложно что-то найти.

% of Requirements reviewed before development start (цель: стремиться к 100%)
ещё одна важная метрика – это то, как требования проходят ревью перед началом разработки. чем раньше выявляются проблемы, тем лучше.

Эффективность оценки трудозатрат (цель: растёт или не снижается тренд попадания в эстимейты по задачам тестирования)
оценка трудозатрат – важный элемент в долгосрочном планировании. если фактические затраты сильно отклоняются от планируемых, нужно пересматривать подход к оценке или декомпозиции задач.

Backlog health (цель: делать хорошо, плохо не делать)
эта метрика (даже комплекс метрик) отслеживает, насколько здоров ваш бэклог и насколько легко вам планировать на будущее. сюда входит количество актуальных задач, сколько из них требуют дополнительной проработки, сколько давно не обновлялись. это позволяет вовремя удалять устаревшие задачи и оставлять в приоритете актуальные фичи.

продолжение ниже

#метрики

как построить работающий онбординг-план и не сойти с ума

в том году писала пост с подходами к добавлению информации в онбординг-план, а сегодня добавлю немного практических рекомендаций

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

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

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

полезно также получать фидбек не только от самого сотрудника, но и от его коллег: наблюдают ли они, что новенький задаёт правильные вопросы, уверенно действует и постепенно набирает обороты.

важно помочь новому сотруднику понять, что он(а) сделал(а) задачу
важно научить новичков проверять себя. один из простых способов — попробовать объяснить задачу самому себе или представить, что вы рассказываете её другу, далёкому от вашей работы. если объяснение звучит логично и понятно, значит, задача усвоена. если в какой-то момент начинаете запинаться или терять нить, стоит вернуться к деталям и пересмотреть их.

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

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

не забывайте декомпозировать большие задачи на мелкие шаги
большие задачи часто могут пугать новичков. поэтому любой сложный таск лучше разбить на несколько мелких шагов. вместо общей инструкции «разберись с проектом», предложите конкретные шаги:
- получи все необходимые доступы,
- изучи документацию,
- проверь основне митинги в календаре,
- выполни небольшую задачу,
- созвонись с лидом или ментором

так каждый шаг будет восприниматься как небольшая победа, и новому сотруднику будет легче справляться с информационной нагрузкой.

геймификация: как сделать онбординг интереснее
кто сказал, что процесс адаптации должен быть скучным? добавьте в него немного игры, например, предложите небольшой квест: «получите все доступы за один день» или «выполните три задачи без ошибок — получите бейдж “мастер первой линии”». такие челленджи не только добавляют мотивации, но и делают процесс адаптации менее напряжённым.

продолжение ниже
#онбординг

возвращаюсь с продолжением постов про метрики

баланс метрик: оцениваем процессы и результаты

в предыдущих постах (1, 2) я уже немного поговорила о том, как важно выбирать правильные метрики, чтобы не просто собирать цифры ради цифр, а действительно понимать, что происходит в вашем проекте. но есть одна важная тема, которую я ещё не затронула, – это баланс между метриками, которые оценивают процессы, и теми, которые оценивают результаты.

почему это важно? давайте разбираться.

если вы слишком увлечены только процессными метриками, вы можете упустить из виду главное – что вы на самом деле создаёте и насколько это ценно. да, важно знать, как идёт процесс, но если в конечном итоге приложение работает плохо или пользователи недовольны, то все эти красивые цифры теряют смысл.

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

вот несколько примеров того, как можно сбалансировать процессные и результативные метрики, избегая фокуса только на количестве и времени:

1. процент багов, невыпущенных в прод (процесс) + удержание пользователей (результат)
- если ваше приложение хорошо протестировано и багов в прод утекает немного, но пользователи приложением не хотят пользоваться, то стоит повнимательнее посмотреть, а чего они хотят. а если баги на проде растут, а пользователи остаются с вами, возможно, вы можете снизить требования к тестированию и увеличить, например, скорость доставки фичей.

2. уровень вовлеченности команды (процесс) + стабильность команды (результат)
- следите за тем, насколько команда вовлечена в проект: участвуют ли все в обсуждениях, предлагают ли идеи. высокий уровень вовлеченности обычно коррелирует с низкой текучестью и стабильностью команды, что в свою очередь отражается на качестве продукта. или нет, если вовлечённость сопровождается слишком высокой нагрузкой и люди, выгорая, уходят.

3. процент выполнения спринта (процесс) + качество релиза (результат)
- завершить спринт на 100% – это, конечно, здорово, но если при этом качество релиза оставляет желать лучшего, то вся эта гонка теряет смысл. важно следить за тем, чтобы спринт завершался не только вовремя, но и с достойным результатом.

4. скорость проведения регрессии (процесс) + количество багов на проде (результат)
- быстро тестировать — хорошо, но если после релиза всё равно появляются баги, нужно задуматься, насколько эффективен этот процесс и как его можно улучшить.

5. качество код-ревью (процесс) + процент отклонённых релизов на этапе тестирования (результат)
- если код-ревью проводится тщательно и качественно, это должно снижать количество ошибок, которые потом выявляются на этапе тестирования. отклонение релизов из-за серьёзных багов – хороший индикатор того, насколько качественно выполнены код-ревью.

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

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

⚡️ Как принять решение, что протестировано достаточно и можно завершить тестирование?

Как всегда, нет варианта "просто проставить галочки в чеклисте, который придумал кто-то более опытный". Скорее есть облако критериев, которые мы можем учитывать при принятии такого решения.

В августе я сделала вебинар на эту тему. Пока готовила вебинар - сделала майнд мапу, в процессе вебинара немного дополнила, потом перевела на английский, еще чуть-чуть причесала и решила поделиться.

Важно: это не "to do list", это список направлений для подумать, который я структурировала в соответствии со своим чувством прекрасного.

🔣Майнд мапа тут🔣

Пара мыслей, которые высказывали участницы вебинара и которые прямо хочется зафиксировать:

1️⃣ Принятие решений такого рода - это не просто про тестирование, это еще и про личностный рост: развитие умения опираться на себя и прокачка смелости принимать решения.

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

что такое exit criterion в тестировании и как их найти (смотрите ниже отличный пост и чеклист от Даши Супруновой)

вижу непонимание этой темы часто даже у лидов, и на самом деле это не удивительно. момент, когда нужно остановиться, вызывает вопросы. вдруг мы что-то упустили? вдруг надо ещё раз всё перепроверить? а ещё разочек на всякий?

но дело в том, что тестирование — это не про то, чтобы «найти всё». исчерпывающее тестирование невозможно, и баги будут в любом продукте, как бы нам этого ни хотелось избежать. здесь важнее понять: сделали ли мы достаточно, чтобы чувствовать себя уверенно?

и вот тут вступают в игру критерии окончания тестирования. они помогают ответить на главный вопрос: когда можно с уверенностью сказать, что мы готовы? когда пора признать, что не надо стелить ещё соломку. и хорошо бы их где-то зафиксировать хотя бы для себя.

да, ошибки могут быть, но обычно проблема даже не в этом — а в том, что мы не готовы к их появлению. задача тестирования и обеспечения качества не в том, чтобы гарантировать полное отсутствие ошибок (к сожалению или к счастью), а в том, чтобы минимизировать риски и сделать так, чтобы команда и заинтересованные стороны знали обо всём, что может пойти не так.

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

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

вечная тема сегодня всплыла в чате менторов WiT: как выбрать тему для выступления на конференции?

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

начнём с основного — выбирайте то, что по-настоящему интересно вам самим. когда вам действительно важна тема, это считывается аудиторией и создаёт вовлечённость. я, например, всегда выбираю темы, которые меня лично вдохновляют или уже зудят 🙂 в этом году я рассказывала о тестировании требований, личном бренде, метриках, и готовлю доклады про тестирование в эпоху AI и построение процессов с нуля. ни один из этих докладов не содержит какого-то "секретного знания", но это синтез опыта, взглядов и ценностей, и такой подход, по моему опыту, лучше резонирует у слушателей.

как же понять, что будет интересно аудитории? вот несколько способов:

- исследование аудитории. поговорите с коллегами, устройте небольшой опрос среди знакомых в профессиональной сфере. узнайте, что их волнует и что сейчас вызывает больше всего вопросов.

- анализ программы конференций. изучите программы прошедших и будущих конференций в вашей сфере. какие темы выбирают организаторы? что сейчас входит в топ обсуждаемых вопросов?

- вопросы и обсуждения в сообществах. зайдите в профильные чаты, на митапы, посмотрите, что обсуждают коллеги. какие вопросы повторяются? что вызывает жаркие дискуссии?

теперь самое важное — сопоставьте это всё с вашими знаниями и интересами. для кого вы хотите выступить — для новичков или для опытных специалистов? какой формат вам подходит больше всего — доклад, мастер-класс, дискуссия? вы хотите дать прикладные инструменты или вдохновить людей? это поможет сфокусироваться и создать что-то, что будет полезно и интересно для обеих сторон.

и ещё, вот несколько вопросов для самоанализа, которые помогут выбрать направление:

- о каких своих проектах вам хотелось бы рассказать?
- какая тема вам настолько интересна, что вы могли бы говорить о ней часами?
- есть ли что-то в вашей профессиональной области, что вы хотели бы изменить или улучшить?
- с какими трудностями вы справлялись лучше других? чему могли бы научить коллег?
- какие проблемы в вашей работе или отрасли вас особенно задевают? что бы вам хотелось обсудить или помочь решить?
- что вам самим хотелось бы услышать на конференции в роли слушателя?
- какую ключевую идею вы хотели бы донести, чтобы слушатели взглянули на свои задачи иначе?
- есть ли пример успешного проекта, на основе которого можно построить выступление?
- какому формату вы отдаёте предпочтение: больше любите делиться конкретными методиками или вдохновлять историями?
- что сейчас в тренде в вашей области? и насколько вы готовы внести свой вклад в развитие этих идей?

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

как можно догадать по тишине в канале, сил у меня нет даже дописать уже почти готовый новый пост по метрикам, не то что делать что-то прям новое

рассказывала тут терапевтке объём своей нагрузки, она только печально качала головой и говорила, что неудивительно, что меня так прибило всякими жизненными пертурбациями. единственное, что поддерживает мою кукуху в это время, — делать то, что приятно самой, например, ZenTest, в котором мы в октябре будем говорить про кризисы всех мастей. позвала свою дорогую @sozdavat провести эфир, как поддержать себя в кризисе. и очень жду подборок от Оли Артемьевой на эту тему, мне это каждый раз удивительно, как у неё находится столько всего интересного.

в общем, если у вас есть кризис или запрос про него подумать, то запись тут, открыта до 5 октября.

а осмысленные посты появятся тут не раньше, чем я допишу сценарий 6-часового воркшопа в вильнюс 🥲

как вывести менеджера из себя зоны комфорта

как будто мы туда заходили

пережила первую неделю на новой работе. если учесть, что к прошлой смене работы у меня добавилась смена страны, то что там было в начале, я помню слабо. да, были новые люди, но процессы и суть работы были очень похожи на уже известное. помню, что было тяжело физически от количества упавших на меня людей (демотивированных), ревью (плохо спланированных), открытых позиций (без тех интервьюеров) и проблемных проектов (без комментариев). тяжело, но понятно.

а сейчас вроде и не тяжело, и не очень проблемно, но вообще по-другому. плюс техническая специфика даёт о себе знать: простенький в целом квест по изучению продуктов довёл меня до криков матом в пустоту. последний раз подобные задачи «разверни то, не знаю что, вот инструкция, но работает не всё» я делала году в 17-18, и уже благополучно забыла эти ощущения собственной непроходимости 🫠

впрочем, где наша не пропадала. как говорится «поплакали, покакали, и снова на позитиве». не родилось ещё такой технической задачи, которой я позволю меня побороть)

я тут в пересменке между работами влетела поделиться новостями короткой строкой

1. готовим сентябрь в zentest. поговорим о священной корове computer science, даст самочувствие — доделаю бота-шпаргалку. запись подробности в форме.

2. во вторник внезапно выступаю на куашной подлодке, поговорю про развитие без автоматизации. билеты на сезон ещё есть:)

3. стартует набор менторов и менти в WiT. очень советую туда начинающим менторам: много полезных материалов, куча опытных коллег, отличный нетворк. всегда не хватает менторов по инженерным специальностям, особенно для начального уровня. я в этом сезоне не пойду, но если вы женщина, у вас есть запрос, который можно решить в рамках 1-3 встреч, на тему, с которой я работаю (управление тестированием, выстраивание процессов качества в полном цикле, работа с командой, подготовка к выступлениям на конфах) и вы не можете сейчас оплатить стоимость сессии, то здесь в комментариях можно написать, что у вас за запрос и почему вы хотите ко мне. выбирать буду субъективно, начинать будем в ноябре, остальное расскажу тем, кого выберу.

4. ну и просто картинка в каких невыносимых условиях приходится писать посты⬇️

про сообщества и прочий нетворк

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

но когда ты уходишь в лидство и менеджерство, ты часто лишаешься и проф сообщества (инженерные вопросы всё менее актуальны), и коллег на месте (в лучшем случае будут лиды других направлений, но у вас разные контексты). возникает чувство изоляции, ты пробираешься на ощупь. выход здесь в принципе тот же: помнить, что лидерство — это просто другая профессия, и в ней тоже есть свои сообщества и периодика. есть сообщества при конференциях (тот же чат боль тимлида, ищется в поиске), есть более ламповые штуки типа lead sisters (если вам туда надо, напишите), есть каналы с полезностями и не только (>вы здесь<). в каналах с активными комментами, кстати, часто формируются свои небольшие сообщества. вот подборка разных каналов разных лидов и менеджеров, чтобы вы смогли выбрать полезные для себя

понимание себя как лидера

в одном из вебинаров я упоминала, что, прежде чем пытаться управлять командой, важно научиться управлять самой собой. но давайте будем честными: легко сказать, а вот как это сделать на практике? давайте разбираться.

почему это важно:
когда вы понимаете, в чём ваши сильные стороны, вы можете использовать их на полную катушку. а осознание своих слабостей помогает вовремя заметить, где нужно подстраховаться или делегировать задачи. лидерство – это не про идеальность, а про осознанность.

например, если вы склонны к прокрастинации (есть кто, кто не склонен?), понимание этого поможет вам заранее предусмотреть ловушки и построить свой день так, чтобы избежать их. осознание своих рабочих привычек – это как карта для путешественника: она не спасёт вас от всех трудностей, но точно поможет обойти некоторые ямы.

конкретные рекомендации:

- проведите самоаудит
выделите время на честную оценку своих сильных и слабых сторон. подумайте, как они влияют на вашу работу и взаимодействие с командой. если вы супер организованны, используйте это, чтобы систематизировать процессы. если, наоборот, не хватает структуры – возможно, стоит подумать о найме коллеги с такими скиллами.

- используйте тесты личности
тесты вроде MBTI или DISC – это не волшебная палочка, но они помогут вам лучше понять, как вы предпочитаете работать и взаимодействовать с другими. это особенно полезно, когда вы только начинаете и вам нужно найти подход к различным типам людей в команде. например, хорошо помнить, что если вы склонны к прямому стилю коммуникации, то это может ранить тех, кто привыкли общаться в более сглаженном формате.

- рефлексия
заведите дневник наблюдений за собой. записывайте (или хотя бы отмечайте) свои реакции на стрессовые ситуации, успехи и неудачи. это поможет вам понять, что мотивирует вас, а что сбивает с пути. например, если вы замечаете, что лучше справляетесь с задачами после утренней пробежки – сделайте её частью своей рутины.

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

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

лидерство – это процесс, а не конечная цель. как сказал один мой деливери менеджер на мои страдания "я облажалась": "а с чего ты взяла, что у тебя должно было получиться всё и сразу".

были очень насыщенные первые полгода: работа, курс для лидов, тренинги, менторинги, выступление на паре конференций, организация куа сис конф, участие в пк sqa days, zentest, много всякого личного и по здоровью.

хотелось отдохнуть хорошо, думала, что смогу сентябрь-октябрь посвятить ничего неделанию, но в начале сентября новая работа, выступление на подлодке, в октябре 2 конференции (надо 2 полностью новых выступления подготовить ещё), в ноябре 2 тренинга. и я поняла, что в меня ничего не лезет больше, надо срочно снижать нагрузку 🥲 скорее всего, курса для лидов зимой не будет, как и нового по процессам. да и вообще пока приторможу по всем активностям, кроме уже запланированных.

продолжим нашу нерегулярную рубрику про работу с метриками

прошлый пост был про теорию «делайте хорошо, плохо не делайте», но всем всегда хочется чего-то более практического. к сожалению, как у типичного менеджера, у меня есть только один универсальный рецепт, как сделать правильно: пробовать и смотреть на результаты, учиться на ошибках и снова пробовать.

но давайте рассмотрим некоторое количество примеров с балансировкой количественных и качественных метрик, чтобы было чуть понятнее, о чём вообще речь.

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

вот несколько примеров, как это можно сделать:

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

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

3. скорость работы команды (например, lead time) + удовлетворённость команды
- скорость работы команды – важный показатель, но он мало значит, если команда при этом выгорает. если lead time хороший, но команда жалуется на перегрузку, это сигнал, что нужно пересмотреть процессы и распределение задач.

4. процент покрытия требований тестами + баланс матрицы трассируемости требований + тренд оценки ревью
- покрытие требований тестами – это основа качества, но важно, чтобы это покрытие было сбалансированным и отражало все ключевые аспекты. баланс матрицы трассируемости показывает, насколько требования охвачены тестами, а тренд оценки ревью помогает понять, как качественно эти тесты реализованы. все три метрики в связке (и ещё пачечка других)) дают понимание, насколько полно и качественно мы тестируем продукт.

5. количество багов на модуль приложения умноженное на коэффициент важности этого модуля
- не все баги одинаково полезны. если баг найден в ключевом модуле, это может иметь более серьёзные последствия, чем аналогичный баг в менее критичном компоненте. умножив количество багов на коэффициент важности модуля, можно получить более точную оценку того, насколько серьёзна проблема и куда стоит направить ресурсы в первую очередь.

все эти пары и комбинации метрик помогают получить более объёмную картину происходящего, вовремя замечать проблемы и находить баланс между различными аспектами работы. метрики – это не самоцель, а инструмент для улучшения процессов. пробуйте разные подходы, анализируйте результаты, учитесь на своих ошибках и корректируйте курс. так можно найти тот самый баланс, где все счастливы и проект движется в правильном направлении.

ну и фоллоу апом про умение в политику и договороспособность не могу не порекомендовать ближайший сезон тимлидской подлодки, посвящённый переговорам.

особенно там жду доклады про технические приёмы переговоров (у меня есть тенденция упираться в свою точку зрения, особенно в недостатке ресурсов) и про презентацию работы высоком начальству (делаю это скорее интуитивно, чем опираясь на какие-то принципы, так что уверена, что есть что хотя бы систематизировать ну или удостовериться, что и так всё делаю правильно).

отдельно собираюсь насладиться пятничными экспериментами над котятами живыми людьми, где участники будут практиковаться в прямом эфире 🙂

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

увидела интересный репост в канале Пустырник не поможет (его соавторка — моя одногруппница Нигяр, которая ушла с директорской позиции в саббатикал и сейчас ищет себя). репост тут, а пока расскажу пару историй на тему.

по моим наблюдениям, политика очень часто встречается уже на лидских позициях, особенно когда на проекте всё горит, надо искать баланс между хорошо и быстро и договариваться со всеми и примерно обо всём. очень часто я вижу, как молодые лиды (и особенно лидессы) выгорают в попытке сделать идеально, отстаивая принципы и имея жёсткую позицию. всегда на консультациях спрашиваю, можно ли что-то не делать, и насколько это действительно нужно. а ещё очень благодарна одной из менеджерок, с которой довелось поработать, которая говорила мне “Natalia, we do not need perfect results, we need good enough”. вот с тех пор я везде ищу это «достаточно хорошо», и это становится отличной переговорной позицией.

периодически с грустью вспоминаю другую историю, которая научила меня, что даже если ты отличный лид, тебя обожает команда, ты хорошо знаешь продукт, но совершенно не понимаешь конъюнктуру и за счёт этого не умеешь договариваться, ты проигрываешь человеку, которые в остальном хуже, зато в конъюнктуре как рыба в воде. потому что договариваться — это про поиск взаимной выгоды, про умение вовремя отступить, про говорить о том, что ты делаешь и как это влияет на общий результат. а ещё про ту самую политику, которая «ойфу я просто буду делать как хорошо, и все поймут». не поймут чаще всего, увы.

есть вещи, ценность которых начинаешь понимать только со временем. или с возрастом.

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

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

я знаю, что некоторые из тех, кто со мной общаются, считают, что я слишком много делаю или мало отдыхаю, но это не так:) я действительно достаточно много времени занимаюсь аккумулированием энергии до и после рывка. писала об этом тут и тут

август — отличный месяц для рефлексии о том, а как надо отдыхать, чтобы отдохнуть (сюрприз: всем по-разному). этому и посвятим августовский ZenTest. Оля как обычно написала подробнее, а я оставлю ссылку на запись. до 5 августа можно успеть вписаться, как раз в понедельник Оля проведёт эфир про лень :)

пост интересного опыта

так сложились обстоятельства, что на один день (вчера) сложилось небольшое (но неприятное) вмешательство под наркозом и вебинар про ai. и двигать оба было настолько геморно, что решила провести эксперимент на живых людях (то есть себе).

результат в целом удовлетворительный, во время вебинара даже перестало болеть (не до этого было), а пост-наркозный тупняк выражался только в забытых пару раз словах, но это со мной бывает и просто по жизни.

в общем, я оказалась устойчивее, чем предполагала, а это полезно про себя знать.