Про QA

Как сделать вакансию максимально недоступной для кандидатов? Небольшой кейс из LinkedIn. Рекрутер публикует вакансию Head of QA. Подробное описание, требования, условия релокации. В конце поста приглашение: «For questions or to apply, please contact me via direct message.» Казалось бы, все просто. Но есть нюанс. 🔒 Комментарии к публикации отключены. Задать вопрос под постом невозможно. 🔒 Личные сообщения тоже недоступны, если вы не в контактах рекрутера. Получается интересная воронка найма: 1. Увидел вакансию. 2. Захотел откликнуться. 3. Написать комментарий нельзя. 4. Написать в личку нельзя. 5. Отправляешь запрос на добавление в контакты и надеешься, что его примут. (Мой запрос на добавление в контакты к этому рекрутеру кажется уже пару недель висит 🤪) И все это ради возможности просто отправить резюме. Особенно забавно, что речь идет о вакансии Head of Quality Assurance. Мы в QA постоянно говорим о пользовательских сценариях, доступности, UX и проверке критических путей. А тут критический путь «кандидат → отклик» не проходит даже smoke-тест 😳 Интересно, кто-нибудь тестирует процесс отклика на вакансии перед публикацией? #QA #найм #LinkedIn #pro_qa #багивокругнас

Сегодня менти, с которой работаю в формате сопровождения (подготовка к интервью, аудит знаний, помощь с резюме, помощь в разборе вакансий, где-то заход в компании не на холодную и тп), получила оффер - что не может не радовать! На всякий случай уточню, а то бывает, что заходят с запросами доведения до оффера, оплата после получения, 1я зп в качестве оплаты (как у волков) и тп - таким не занимаюсь. Помогаю исключительно в формате почасовой работы. А кто говорит, что предоставляет гарантированный результат в плане трудоустройства - лукавит)) PS. у меня, кстати, пара мест на сопровождение появилось - сегодня-завтра повешу анонс на эту тему. #qa #pro_qa #ментор #наставник

|Критерий|RACI|RASCI|RAC-VS|RAPID| |---|---|---|---|---| |Основной фокус|Ответственность|Ответственность и поддержка|Проверка и утверждение|Принятие решений| |Отдельная поддержка|Нет|Да|Нет|Нет| |Отдельная верификация|Нет|Нет|Да|Нет| |Формальное утверждение|Не выделено|Не выделено|Да|Через Agree / Decide| |Финальное право решения|Не детализировано|Не детализировано|Не основной фокус|Да| |Сложность внедрения|Низкая|Низкая–средняя|Средняя–высокая|Средняя–высокая| ## 6. Что выбрать для QA и Engineering Management? Я бы ориентировался не на популярность модели, а на проблему, которую нужно решить. Ситуация 1. Непонятно, кто отвечает за качество релиза. Начните с RACI. Определите владельцев процессов, исполнителей и тех, кто должен участвовать в обсуждении. Ситуация 2. QA постоянно зависит от DevOps, разработчиков и инфраструктуры. Используйте RASCI. Она помогает зафиксировать обязательную поддержку и не превращать каждую зависимость в неформальную просьбу. Ситуация 3. Релизы требуют проверок, аудита и формальных разрешений. Рассмотрите RAC-VS. Она позволяет отдельно закрепить проверку соответствия требованиям и право утверждения. Ситуация 4. QA говорит «релизить нельзя», Product говорит «релизим», а решение зависает. Используйте RAPID. Зафиксируйте, кто оценивает риски, кто предоставляет данные, чьё согласие обязательно и кто принимает окончательное решение. ## 7. Можно ли комбинировать модели? Да. Более того, для крупных IT-организаций это часто разумнее, чем пытаться описать всё одной матрицей. Например: - RACI — для распределения ответственности между Engineering, QA и Product. - RASCI — для операционных процессов, зависящих от инфраструктуры. - RAC-VS — для процессов проверки и формального утверждения релизов. - RAPID — для решений о запуске, переносе релиза, принятии технического долга и выборе архитектуры. Главное — не пытаться внедрить все модели сразу. Начните с одного проблемного процесса. Опишите его участников и реальные полномочия. Проверьте, исчезла ли неопределённость. Если матрица существует только в Confluence и никто не использует её при работе, пользы от неё не будет. --- ## Вывод RACI отвечает на вопрос: кто делает и кто отвечает? RASCI: кто делает, кто отвечает и кто помогает? RAC-VS: кто делает, кто проверяет и кто утверждает? RAPID: кто рекомендует, кто согласует и кто принимает решение? Для QA-руководителя ключевой момент — ответственность за качество не равна полномочию принимать решение о релизе. QA может отвечать за тестирование, проверку критериев качества и информирование о рисках. Но решение о выпуске продукта может принадлежать совсем другой роли. И это нормально, если границы ответственности и полномочий определены заранее. А у вас в командах ответственность и право принятия решений формализованы или всё ещё работают по принципу «кто громче сказал, тот и решил»? #management #QA #QALead #EngineeringManagement #RACI #RAPID Отдельно для публикации в @pro_qa: я бы сохранил примеры из QA и релизного процесса — они делают различия между моделями конкретными. При этом стоит подчеркнуть, что RACI и RASCI широко распространены, RAPID имеет определённую методологию Bain, а RAC-VS — менее унифицированная модификация, которую нельзя подавать как единый общепринятый стандарт. Источники для проверки терминологии: [Atlassian — RACI](https://www.atlassian.com/work-management/project-management/raci-chart?utm_source=chatgpt.com), [Bain — RAPID Decision Making](https://www.bain.com/insights/rapid-decision-making/?utm_source=chatgpt.com).

В отличие от RACI и RASCI, здесь акцент не только на том, кто выполняет работу, но и на том, кто подтверждает её корректность. R — Responsible: выполняет работу. A — Accountable: отвечает за конечный результат. C — Consulted: консультирует в процессе. V — Verify (Проверяющий): проверяет, соответствует ли результат установленным требованиям и критериям. S — Sign-off (Утверждающий): формально подтверждает принятие результата или разрешает переход к следующему этапу. В этой модели V и S — принципиально разные роли. Verify ≠ Sign-off. QA может подтвердить, что функциональность соответствует требованиям, но не иметь полномочий разрешить её выпуск в production. ### Пример: релиз в production |Активность|QA Lead|Dev Lead|Security|Release Manager| |---|---|---|---|---| |Подготовка сборки|C|R|—|A| |Проверка безопасности|C|R|V|A| |Регрессионное тестирование|V|R|C|A| |Утверждение релиза|C|C|C|A, S| В последней строке Release Manager одновременно отвечает за решение и формально его утверждает. В организациях с обязательным независимым согласованием эти роли могут быть разделены. Преимущества: - Разделяет выполнение, проверку и утверждение. - Повышает прозрачность контрольных процедур. - Помогает избежать ситуации, когда исполнитель сам себе принимает работу. - Полезна для аудита и compliance. Недостатки: - Больше ролей и согласований. - Может замедлять процессы. - Избыточна для небольших команд и низкорисковых изменений. Когда использовать: в regulated environments, fintech, healthcare, enterprise, а также там, где требуются независимая верификация и формальное разрешение на релиз. _Нюанс: RAC-VS менее стандартизирована, чем RACI. В разных источниках и организациях состав ролей может отличаться. Перед внедрением нужно зафиксировать собственные определения._ --- ## 4. RAPID — модель принятия решений RAPID (Recommend, Agree, Perform, Input, Decide) — модель, разработанная Bain & Company для распределения ролей при принятии решений. В отличие от предыдущих моделей, RAPID фокусируется не на выполнении задач, а на том, как именно принимается решение и кто обладает финальным правом выбора. R — Recommend (Рекомендующий) Анализирует варианты, собирает данные и предлагает решение. A — Agree (Согласующий) Обладает правом обязательного согласования по определённым вопросам. Если согласие необходимо и не получено, решение нельзя просто провести в обход этой роли. P — Perform (Исполнитель) Реализует принятое решение. I — Input (Эксперт) Предоставляет информацию, оценки и рекомендации. Его мнение учитывается, но не является обязательным согласованием. D — Decide (Принимающий решение) Имеет окончательное право выбора и несёт ответственность за само решение. ### Пример: выпуск продукта с известными критическими дефектами |Роль|Участник|Действие| |---|---|---| |R|QA Lead|Оценивает риски и рекомендует перенос релиза| |A|Security Lead|Согласует решение, если затронуты обязательные security-требования| |P|DevOps / Release Team|Выполняет принятое решение| |I|Dev Lead, Support|Предоставляют оценки последствий| |D|Product Owner|Принимает финальное решение в пределах своих полномочий| Здесь важно: Product Owner не может отменить обязательное security-согласование только потому, что обладает ролью D. Преимущества: - Устраняет неопределённость в принятии решений. - Помогает избежать бесконечных согласований. - Отделяет экспертов от лиц с правом вето. - Подходит для сложных межфункциональных решений. Недостатки: - Требует чёткого определения полномочий. - Неправильное назначение Agree создаёт дополнительные блокировки. - Избыточна для повседневных операционных задач. Когда использовать: при принятии архитектурных решений, выборе технологий, определении стратегии тестирования, запуске продукта и управлении серьёзными инцидентами. --- ## 5. Сравнение моделей

# RACI, RASCI, RAC-VS, RAPID: кто отвечает, кто делает и кто принимает решения? Одна из частых проблем в управлении командами — размытая ответственность. Задача есть. Исполнители есть. Встречи проводятся. Но когда что-то идёт не так, выясняется, что: - Все думали, что решение принимает кто-то другой. - Несколько человек считали себя ответственными за результат. - Согласование превратилось в бесконечную цепочку обсуждений. - Человек, который должен был принимать решение, вообще не участвовал в процессе. Для решения подобных проблем существуют модели распределения ролей и ответственности: RACI, RASCI, RAC-VS и RAPID. Разберём, чем они отличаются, когда какую использовать и как применять в IT, разработке и QA. --- ## 1. RACI — базовая модель распределения ответственности RACI (Responsible, Accountable, Consulted, Informed) — матрица, которая определяет роли участников в конкретных задачах или процессах. R — Responsible (Исполнитель) Тот, кто непосредственно выполняет работу. Исполнителей может быть несколько. A — Accountable (Ответственный за результат) Тот, кто несёт конечную ответственность за результат и обладает полномочиями его принять. Рекомендуется назначать одного A на каждую задачу. C — Consulted (Консультант) Эксперт, чьё мнение необходимо получить перед выполнением задачи или принятием решения. Коммуникация двусторонняя. I — Informed (Информируемый) Тот, кого нужно держать в курсе результата или прогресса. Его согласование не требуется. ### Пример: выпуск новой функциональности |Активность|QA|Dev|Tech Lead|PM| |---|---|---|---|---| |Разработка|I|R|A|C| |Тестирование|R|C|I|A| |Исправление дефектов|C|R|A|I| |Решение о релизе|C|C|C|A| _В примере PM отвечает за релиз, но в другой организации эта роль может принадлежать Engineering Manager или Release Manager._ Преимущества: - Простая и понятная модель. - Убирает дублирование ответственности. - Помогает выявить задачи без владельца. - Подходит для большинства процессов. Недостатки: - Не выделяет вспомогательные роли. - Не описывает механизм принятия сложных решений. - Часто путают Responsible и Accountable. Когда использовать: для распределения ответственности между командами, описания процессов разработки, тестирования, релизов и управления инцидентами. --- ## 2. RASCI — RACI с выделенной ролью поддержки RASCI (Responsible, Accountable, Support, Consulted, Informed) — расширение RACI, добавляющее роль Support. S — Support (Поддержка) Тот, кто помогает исполнителю выполнить задачу: предоставляет инструменты, инфраструктуру, данные или выполняет вспомогательную работу. Важное отличие: - Responsible непосредственно отвечает за выполнение работы. - Support помогает её выполнить. - Consulted предоставляет экспертное мнение. ### Пример: автоматизация тестирования |Активность|QA Auto|DevOps|QA Lead|Dev| |---|---|---|---|---| |Создание автотестов|R|S|A|C| |Настройка CI/CD|S|R|C|A| |Подготовка тестовых данных|R|S|A|C| |Анализ падений тестов|R|S|A|C| Здесь DevOps может обеспечивать инфраструктуру, но не отвечает за качество и содержание автотестов. Преимущества: - Лучше отражает реальную командную работу. - Разделяет исполнение и техническую поддержку. - Особенно полезна для кросс-функциональных процессов. Недостатки: - Дополнительная роль усложняет матрицу. - Support иногда превращается в неопределённую категорию «все, кто помогает». - Есть риск размыть границу между R и S. Когда использовать: при работе QA, DevOps, SRE, инфраструктурных и платформенных команд, когда выполнение задач зависит от нескольких специализаций. --- ## 3. RAC-VS — модель с явной проверкой и утверждением RAC-VS (Responsible, Accountable, Consulted, Verify, Sign-off) — вариант распределения ответственности, который отдельно выделяет проверку результата и формальное утверждение.

Человеческий фактор, или баги бывают не только в IT 🙈 Получаю заказное письмо из суда. Внутри - официальное решение об изменениях в компании, о существовании которой я впервые слышу. Печать, подпись, номер дела, срок обжалования. Все на месте) Как истинный тестировщик с аналитическим мозгом начинаю расследование: сверяю данные, нахожу несоответствие в номерах дел, отправляю запрос в суд. Через 20 минут (невероятная скорость!) приходит ответ: помощник судьи просто положил документ не в тот конверт 😂 Человеческая ошибка. Бывает. Хорошо, что ничего серьезного) Попросили уничтожить письмо. Root cause: human error. Impact: один озадаченный получатель. Resolution: признали ошибку, исправят отправку. Preventive actions: неизвестны. Bug status: Closed. Cannot reproduce. 😁 Мораль: Можно автоматизировать процессы, но пока человек участвует в системе, тестирование остается актуальным. #qa #pro_qa #багивокругнас #human_error

Недавно завершился 1й модуль курса СТО в Стратоплане, про которыц я недавно писал. Сам формат очень понравился: 5ч+5ч в сб и вс и так два раза - те за месяц получилось 20ч интенсивного обучения. Теории в меру и достаточно много работы в мини-группах 5-6 человек (3 сессии за один день). Основной блок был про роль CTO, работу со стратегией, приоритетами, взаимодействие с бизнесом и принятие решений в условиях ограничений и конфликтующих интересов. Для меня эта часть была особенно полезной - много вещей получилось разложить по полочкам и сразу примерить на реальные рабочие ситуации. Отдельный блок был посвящен сложным переговорам: подготовке, BATNA/WATNA, поиску интересов сторон, MESO, работе с давлением, встречным предложениям, эскалации и деэскалации. Было интересно, хотя эта часть для меня оказалась заметно сложнее - здесь недостаточно просто понимать теорию, навык появляется именно через практику. Практики вообще было много, если сравнивать с другим онлайн обучением: кейсы, переговорные тренировки, работа в мини-группах, разбор результатов и обратная связь. За счет этого модуль воспринимается не как набор лекций, а как полноценная тренировка. Еще один большой плюс - группа. Большая часть участников сами действующие CTO или руководители сопоставимого уровня, поэтому обсуждения получаются предметными, а нетворк сам по себе представляет большую ценность. В итоге от первого модуля остались очень хорошие впечатления. Основная часть зашла особенно сильно, переговорный блок оказался сильно сложнее, но именно поэтому хочется его дальше прокачивать. #qa #pro_qa #cto #стратоплан

#qa #pro_qa #ai

Каким меня видит мой Chat GPT 😎 #qa #pro_qa #ai #me

Ваша реакция, когда вам отказывают по вакансии с комментарием "у вас очень сильный опыт и для командной работы это может быть рискованно"? Печально наблюдать, когда компании не хотят (или "не умеют готовить") сильных кандидатов и набирают "В-игроков". При этом в случае найма линейных сотрудников - это еще имеет смысл (когда уже есть А игрок и надо ему подобрать команду из В игроков), но в случае лидов/менеджеров/хэдов - это прям зашквар, имхо. А вы что думаете по этому вопросу? #qa #pro_qa #найм #overqualified

С начала этого года пару раз откладывал, но наконец-то созрел и выделил время под курс СТО в Стратоплане. Отправил заявку, выполнил тестовое задание, прошел вступительное собеседование, получил пачку материалов для старта. Сам курс состоит из 2-х частей - курс Основа с большим кол-вом информации по управлению и собственно курс СТО. Про программу детально писать не буду, но кому интересно - посмотрите на сайте с описанием курса: https://stratoplan-school.com/cto/ Но планирую по итогам каждого модуля делать небольшой статус-отчет "что было интересное и полезное" не только для себя, но вдруг кому тоже полезным окажется. #pro_qa #qa #cto #stratoplan

24 августа ATSQA выкатили довольно существенное обновление своего глобальный списка инструментов тестирования и автоматизации В апдейте явно виден новый всплеск AI‑ориентированных решений для качества. В базе у них уже 642 инструмента в 25 категориях, включая отдельную секцию AI‑assisted testing, а свежий апдейт принес сразу 17 JSON‑утилит - от генерации и форматирования до валидации, сравнения и мокирования данных, что критично для data‑driven тестов и проверки AI‑систем на реалистичных сценариях. По сути ATSQA превращает свой список в «радар» по AI‑инструментам для QA: если раньше это была просто справочная витрина, то теперь это источник, по которому видно, как быстро рынок смещается в сторону автономного тестирования, интеллектуального анализа дефектов и агентных тест‑агентов. Полный список здесь: https://atsqa.org/tools #qa #pro_qa #ai_tools #qa_tools #ai

Если вы используете BrowserStack и/или следите за рынком, то наверняка видели новость про AI агента Test Companion.А кто-то возможно уже его попробовал. Если такие люди есть среди читателей - расскажите плиз "как оно"? И действительно ли золотые горы таковыми и являются. #qa #pro_qa #ai #browserstack #test_companion

Сегодня в #OTUS на курсе QA Lead стартует новый поток 2026-07. Еще не поздно подключиться, тк первые 2 лекции обзорные и спокойно смотрятся в записи. Подробно про сам курс можно прочитать здесь: https://otus.ru/lessons/qa-lead/ Из интересных нововведений - добавили отдельный модуль про AI в тестировании. Ну и в качестве бонуса 10% скидка от меня - DANILOVV10 #qa #pro_qa

Решил все новости про AI / LLM в QA перенести в отдельный канал, чтобы здесь не засорять эфир - тк порой там дофига всего (я бы сказал каждый день что-то новое - все читать и анализировать никакого времени не хватит, поэтому у меня на жто отведено всего несколько часов в неделю - разобрать новости про ИИ и тестирование, которые мне агенты собирают. А самое вкусное буду постить в @qa_ai_news #qa #pro_qa #qa_ai @ai #llm #qa_ai_news #ai_news