Про QA
Відкрити в Telegram
В этом канале делюсь всяческими полезностями про QA, интересными историями и помогаю коллегам и компаниям в качестве ментора и консультанта. Для связи: @qa_advisor
Показати більше1 046
Підписники
-124 години
Немає даних7 днів
-830 днів
Завантажуємо дані
Схожі канали
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
листопад '26лист '26
листопад '26
+1
в 0 каналах
жовтень '26
+7
в 0 каналах
Get PRO
вересень '26
+14
в 0 каналах
Get PRO
серпень '26
+10
в 0 каналах
Get PRO
липень '26
+5
в 0 каналах
Get PRO
червень '26
+10
в 0 каналах
Get PRO
травень '26
+12
в 0 каналах
Get PRO
квітень '26
+30
в 0 каналах
Get PRO
березень '26
+52
в 0 каналах
Get PRO
лютий '26
+17
в 0 каналах
Get PRO
січень '26
+13
в 0 каналах
Get PRO
грудень '25
+12
в 0 каналах
Get PRO
листопад '25
+23
в 0 каналах
Get PRO
жовтень '25
+37
в 0 каналах
Get PRO
вересень '25
+31
в 0 каналах
Get PRO
серпень '25
+24
в 0 каналах
Get PRO
липень '25
+31
в 0 каналах
Get PRO
червень '25
+37
в 0 каналах
Get PRO
травень '25
+73
в 0 каналах
Get PRO
квітень '25
+69
в 0 каналах
Get PRO
березень '25
+123
в 0 каналах
Get PRO
лютий '25
+86
в 0 каналах
Get PRO
січень '25
+176
в 0 каналах
Get PRO
грудень '24
+34
в 0 каналах
Get PRO
листопад '24
+55
в 1 каналах
Get PRO
жовтень '24
+109
в 0 каналах
Get PRO
вересень '24
+341
в 0 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 09 листопада | 0 | |||
| 08 листопада | 0 | |||
| 07 листопада | 0 | |||
| 06 листопада | 0 | |||
| 05 листопада | +1 | |||
| 04 листопада | 0 | |||
| 03 листопада | 0 | |||
| 02 листопада | 0 | |||
| 01 листопада | 0 |
Дописи каналу
| 2 |  Как сделать вакансию максимально недоступной для кандидатов?
Небольшой кейс из 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 #багивокругнас | 200 |
| 3 | Сегодня менти, с которой работаю в формате сопровождения (подготовка к интервью, аудит знаний, помощь с резюме, помощь в разборе вакансий, где-то заход в компании не на холодную и тп), получила оффер - что не может не радовать!
На всякий случай уточню, а то бывает, что заходят с запросами доведения до оффера, оплата после получения, 1я зп в качестве оплаты (как у волков) и тп - таким не занимаюсь. Помогаю исключительно в формате почасовой работы. А кто говорит, что предоставляет гарантированный результат в плане трудоустройства - лукавит))
PS. у меня, кстати, пара мест на сопровождение появилось - сегодня-завтра повешу анонс на эту тему.
#qa #pro_qa #ментор #наставник | 354 |
| 4 | |Критерий|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). | 2 |
| 5 | В отличие от 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. Сравнение моделей | 2 |
| 6 | # 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) — вариант распределения ответственности, который отдельно выделяет проверку результата и формальное утверждение. | 2 |
| 7 | Немає тексту... | 10 |
| 8 | Человеческий фактор, или баги бывают не только в IT 🙈
Получаю заказное письмо из суда. Внутри - официальное решение об изменениях в компании, о существовании которой я впервые слышу.
Печать, подпись, номер дела, срок обжалования. Все на месте)
Как истинный тестировщик с аналитическим мозгом начинаю расследование: сверяю данные, нахожу несоответствие в номерах дел, отправляю запрос в суд.
Через 20 минут (невероятная скорость!) приходит ответ: помощник судьи просто положил документ не в тот конверт 😂
Человеческая ошибка. Бывает. Хорошо, что ничего серьезного)
Попросили уничтожить письмо.
Root cause: human error.
Impact: один озадаченный получатель.
Resolution: признали ошибку, исправят отправку.
Preventive actions: неизвестны.
Bug status: Closed. Cannot reproduce. 😁
Мораль:
Можно автоматизировать процессы, но пока человек участвует в системе, тестирование остается актуальным.
#qa #pro_qa #багивокругнас #human_error | 492 |
| 9 | Интересно ли вам, если буду не просто рассказывать про темы с курса СТО, а делиться материалов по ним (книги, статьи, свои мысли)? Всяко полезно будет для лидов/менеджеров/хэдов. | 539 |
| 10 | Недавно завершился 1й модуль курса СТО в Стратоплане, про которыц я недавно писал.
Сам формат очень понравился: 5ч+5ч в сб и вс и так два раза - те за месяц получилось 20ч интенсивного обучения. Теории в меру и достаточно много работы в мини-группах 5-6 человек (3 сессии за один день).
Основной блок был про роль CTO, работу со стратегией, приоритетами, взаимодействие с бизнесом и принятие решений в условиях ограничений и конфликтующих интересов. Для меня эта часть была особенно полезной - много вещей получилось разложить по полочкам и сразу примерить на реальные рабочие ситуации.
Отдельный блок был посвящен сложным переговорам: подготовке, BATNA/WATNA, поиску интересов сторон, MESO, работе с давлением, встречным предложениям, эскалации и деэскалации. Было интересно, хотя эта часть для меня оказалась заметно сложнее - здесь недостаточно просто понимать теорию, навык появляется именно через практику.
Практики вообще было много, если сравнивать с другим онлайн обучением: кейсы, переговорные тренировки, работа в мини-группах, разбор результатов и обратная связь. За счет этого модуль воспринимается не как набор лекций, а как полноценная тренировка.
Еще один большой плюс - группа. Большая часть участников сами действующие CTO или руководители сопоставимого уровня, поэтому обсуждения получаются предметными, а нетворк сам по себе представляет большую ценность.
В итоге от первого модуля остались очень хорошие впечатления. Основная часть зашла особенно сильно, переговорный блок оказался сильно сложнее, но именно поэтому хочется его дальше прокачивать.
#qa #pro_qa #cto #стратоплан | 534 |
| 11 |  #qa #pro_qa #ai | 462 |
| 12 |  Каким меня видит мой Chat GPT 😎
#qa #pro_qa #ai #me | 485 |
| 13 | Ваша реакция, когда вам отказывают по вакансии с комментарием "у вас очень сильный опыт и для командной работы это может быть рискованно"?
Печально наблюдать, когда компании не хотят (или "не умеют готовить") сильных кандидатов и набирают "В-игроков". При этом в случае найма линейных сотрудников - это еще имеет смысл (когда уже есть А игрок и надо ему подобрать команду из В игроков), но в случае лидов/менеджеров/хэдов - это прям зашквар, имхо.
А вы что думаете по этому вопросу?
#qa #pro_qa #найм #overqualified | 616 |
| 14 | С начала этого года пару раз откладывал, но наконец-то созрел и выделил время под курс СТО в Стратоплане.
Отправил заявку, выполнил тестовое задание, прошел вступительное собеседование, получил пачку материалов для старта.
Сам курс состоит из 2-х частей - курс Основа с большим кол-вом информации по управлению и собственно курс СТО.
Про программу детально писать не буду, но кому интересно - посмотрите на сайте с описанием курса: https://stratoplan-school.com/cto/
Но планирую по итогам каждого модуля делать небольшой статус-отчет "что было интересное и полезное" не только для себя, но вдруг кому тоже полезным окажется.
#pro_qa #qa #cto #stratoplan | 597 |
| 15 | 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 | 673 |
| 16 | Немає тексту... | 498 |
| 17 | Если вы используете BrowserStack и/или следите за рынком, то наверняка видели новость про AI агента Test Companion.А кто-то возможно уже его попробовал.
Если такие люди есть среди читателей - расскажите плиз "как оно"? И действительно ли золотые горы таковыми и являются.
#qa #pro_qa #ai #browserstack #test_companion | 432 |
| 18 | Немає тексту... | 460 |
| 19 |  Сегодня в #OTUS на курсе QA Lead стартует новый поток 2026-07.
Еще не поздно подключиться, тк первые 2 лекции обзорные и спокойно смотрятся в записи.
Подробно про сам курс можно прочитать здесь: https://otus.ru/lessons/qa-lead/
Из интересных нововведений - добавили отдельный модуль про AI в тестировании.
Ну и в качестве бонуса 10% скидка от меня - DANILOVV10
#qa #pro_qa | 493 |
| 20 | Решил все новости про AI / LLM в QA перенести в отдельный канал, чтобы здесь не засорять эфир - тк порой там дофига всего (я бы сказал каждый день что-то новое - все читать и анализировать никакого времени не хватит, поэтому у меня на жто отведено всего несколько часов в неделю - разобрать новости про ИИ и тестирование, которые мне агенты собирают. А самое вкусное буду постить в @qa_ai_news
#qa #pro_qa #qa_ai @ai #llm #qa_ai_news #ai_news | 424 |
