Вот знаете Феномен Баадера — Майнхоф? А вот недавно поймал такой кейс.

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

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

Если 2 варианта:
1. Бесконечно раздувать команду QA. Правда это вызовет проблемы с раздуванием ФОТ, простоем QA, так как поток задач хоть и равномерен, но бывают случае, когда делаются действительно масштабные проекты, больше нагрузки на лидов и ещё масса проблем.
2. Разгрузить QA и стараться всё максимально автоматизировать. Это вариант, который как раз сейчас используют в компании.

Примеры, как разгружаем в Skyeng:
1. Допустима практика dev-теста. Когда разработчик подхватывает задачу другого разработчика, пишет/переиспользует + дополняет новыми пунктами чек-лист и проверяет по чек-листу. Таким образом мы можем снимать нагрузку с QA в случае высокой нагрузки не теряя качества поставляемых решений на прод.
2. Expert QA пишут e2e. Это разгружает не только QA с расчётом, что чем больше качественных e2e-тестов будет в компании, тем меньше нужно будет QA заниматься непосредственной проверкой, но и позволяет разработке вносить изменения заранее находя основные проблемы в решении и потенциально очень помогает при изменении изменений в масштабе всей компании, как пример обновление Angular.
3. Высокое внедрение автоматизации и AI в процессы QA. Сейчас в компании есть решения, которые позволяют создавать задачи по исправлению бага на базе треда, собирать чек-лист проверок на базе изменений в задачах в один клик, автоматизация на рутинные действии.

В целом, об этом хорошо рассказывается в 13-15 главе книги, где очень показательно демонстрируется на походе. И прочитав 3 небольшие главы можно начать замечать довольно много интересных вещей и альтернативных вариантов решения проблемы ТОС