«Вы не успели все протестировать!» - на проектах я слышала эту фразу не раз.

Разработка задержала задачу - QA не успело. Требования изменились - сроки сдвинулись. Нашли много дефектов - снова виновато тестирование. Классика 😅

Но если QA не успевает, это часто симптом проблем в процессе, а не медленной работы тестировщиков.

Как это выглядит на практике?

Задачи передают позже договоренного срока. Требования уточняются уже во время тестирования. А из оценки просят убрать время на заведение багов, ретест и риски. Оставить только первичную проверку - и уложиться в прежний срок.

Но работа никуда не исчезает. Дефекты нужно заводить, исправления - проверять повторно, требования - уточнять. Если разработка задержалась, QA не может бесконечно компенсировать это ускорением.

Что я делаю в таких ситуациях?

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

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

Потому что убрать время из оценки можно. Убрать саму работу - нельзя.

Пример из практики.

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

Я запросила информацию сама. По каждому пункту были подтверждения. После эскалации вопрос закрыли.

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

Моя задача как QA Lead - отделять реальные ошибки от проблем процесса.

А если протестировать все в срок невозможно?

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

Мои принципы:

Работа QA - это не только проверка функциональности. Уточнение требований, заведение дефектов и ретест тоже должны учитываться в планировании.

Нельзя сокращать оценку, не понимая, куда переместится работа. Меньше времени - значит, нужно пересматривать объем проверок или сроки.

Релизные риски - общая ответственность. QA выявляет их, объясняет и фиксирует. Но последствия решения сократить проверки нельзя автоматически перекладывать на тестирование.

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

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

А как в ваших командах поступают, когда дата релиза не меняется, а времени на тестирование становится всё меньше?