В прошлом уроке мы научились расставлять приоритеты тестирования по рискам: где риск выше, туда идёт больше внимания. Но риски определены на старте, а само тестирование растягивается на дни, а то и недели. Как понять, что происходит с тестированием прямо сейчас, на середине пути — идём по расписанию тест-плана (глава 13.1) или уже отстаём, и не найдено ли внезапно слишком много критичных дефектов? Для этого нужны три связанных инструмента: мониторинг, контроль и метрики.
Чему научишься за этот урок:
— различать мониторинг (наблюдение) и контроль (действие на основе наблюдения);
— называть, какие метрики отслеживают ход тестирования и что каждая из них показывает;
— по сценарию с конкретными цифрами предлагать обоснованное управленческое решение.
Мониторинг: что отслеживаем
Мониторинг тестирования — это регулярное отслеживание того, как идёт процесс, без принятия решений в этот же момент. Тестировщик или тимлид смотрит одновременно на несколько вещей: сколько тест-кейсов выполнено из запланированных, сколько дефектов найдено и с каким severity (глава 6.6), и укладывается ли команда в расписание, зафиксированное в тест-плане (глава 13.1). Сам по себе мониторинг ничего не решает — он просто даёт актуальную картину.
Контроль: действие на основе данных
Контроль — это следующий шаг: управленческое решение, принятое НА ОСНОВЕ данных мониторинга. Если видно, что тестирование отстаёт от расписания или найдено аномально много критичных дефектов, кто-то должен отреагировать — пересмотреть сроки, добавить в команду ещё одного тестировщика или эскалировать риск (глава 13.3), если он выходит за рамки того, что закладывали на старте. Разница проста: мониторинг — это НАБЛЮДЕНИЕ, контроль — это ДЕЙСТВИЕ по итогам наблюдения. Без мониторинга контролировать нечего — решение не на чем основывать. Без контроля мониторинг бесполезен — команда видит проблему, но ничего не меняет.
Метрики: конкретные цифры
Метрики — конкретные измеримые показатели, на которые опирается мониторинг. Самые частые:
- % выполненных тест-кейсов от запланированных. Показывает объём сделанной работы, но НЕ показывает её качество.
- Число открытых дефектов по severity (глава 6.6). Особенно важны дефекты с высоким severity — они сигналят о рисках для релиза.
- Тренд числа новых дефектов день ото дня. Растёт или падает: если находки не иссякают к концу цикла, это тревожный сигнал, что тестируемая область сложнее, чем ожидали.
- Покрытие требований (глава 5.8). Какая доля требований действительно проверена тест-кейсами, а не просто предполагается покрытой.
Важная оговорка: метрика без контекста может ввести в заблуждение. «100% тест-кейсов выполнено» звучит обнадёживающе, но ничего не говорит о том, сколько из них провалились — 100% выполненных и 40% проваленных одновременно возможны, и это совсем не тот сигнал, который слышится в «100%».
МОНИТОРИНГ (наблюдение) -> собирает МЕТРИКИ (% выполнено, дефекты по severity, тренд, покрытие) -> метрики формируют повод для КОНТРОЛЯ (решение) -> контроль меняет сроки/ресурсы/риски и снова возвращается к мониторингу
Пример на нашей платформе
Команда тестирует раздел «Оплата курса» перед релизом — по тест-плану на это заложено пять рабочих дней. К середине цикла (после третьего дня) метрики показывают: выполнено 35% тест-кейсов вместо ожидаемых по расписанию 60%, и уже найдено четыре дефекта с высоким severity — заметно больше, чем на аналогичных релизах обычно находят за весь цикл. Само по себе отставание по проценту выполнения — повод для контроля: пересмотреть расписание или добавить ресурс. Но всплеск дефектов высокого severity — более тревожный сигнал: он может означать, что раздел технически сложнее или сырее, чем закладывали в оценку рисков (глава 13.3). Разумное решение по контролю здесь — не просто добавить тестировщика на оставшиеся дни, а сначала эскалировать находку тимлиду и обсудить, не стоит ли сдвинуть дату релиза, пока часть найденных дефектов не будет исправлена и перепроверена.
Совет: если метрики на середине цикла выглядят тревожно, не жди конца тестирования, чтобы среагировать — тогда решение по контролю принимать уже поздно. Мониторинг тем и полезен, что даёт сигнал заранее, а не постфактум.
Итог:
— мониторинг — регулярное наблюдение за ходом тестирования (выполнение, дефекты, расписание), без немедленного решения;
— контроль — управленческое действие на основе данных мониторинга: пересмотр сроков, добавление ресурсов, эскалация риска;
— метрики (% выполнения, дефекты по severity, тренд находок, покрытие требований) дают цифры, но без контекста могут ввести в заблуждение — важно смотреть на комбинацию показателей, а не на один изолированный процент.
Контрольный вопрос. Что из перечисленного — пример мониторинга, а не контроля?
Подсказка: Мониторинг — это только наблюдение, без принятия решения.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. В чём ключевое отличие контроля от мониторинга?
Подсказка: Вспомни короткую формулу из урока: одно — это глагол «наблюдать», другое — глагол «действовать».
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. К какой из трёх областей урока относится конкретный измеримый показатель «процент выполненных тест-кейсов от запланированных»?
Подсказка: Это не наблюдение и не решение, а именно число, на которое наблюдение опирается.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Почему показатель «100% тест-кейсов выполнено» сам по себе может ввести в заблуждение?
Подсказка: Вспомни разницу между тем, что работа СДЕЛАНА, и тем, что она сделана УСПЕШНО.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие из перечисленных примеров относятся к метрикам хода тестирования (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Метрика — это измеримое число, а не субъективное ощущение.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Одним словом: регулярное наблюдение за ходом тестирования, без принятия решений в этот же момент, называется ______.
Подсказка: Это первое из трёх понятий урока, разобранное в первом разделе.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тимлид каждый день смотрит отчёт: сколько тест-кейсов выполнено, сколько дефектов найдено, — но пока ничего не меняет в планах. Как одним словом называется то, чем сейчас занят тимлид? Ответь одним словом.
Подсказка: Само по себе разглядывание цифр без принятия решения — это ещё не действие.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Метрики середины цикла показывают: тестирование раздела «Оплата курса» отстаёт от расписания тест-плана (глава 13.1) на два дня. Тимлид принимает решение добавить в команду ещё одного тестировщика на оставшиеся дни. Как одним словом называется такое управленческое решение? Ответь одним словом.
Подсказка: Это уже конкретное действие, предпринятое на основе данных, а не просто наблюдение.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях, почему в уроке проведена чёткая граница между мониторингом и контролем, а не используется одно общее слово «отслеживание» для обоих понятий.
Критерий приёмки: указано, что мониторинг — это только наблюдение/сбор данных, а контроль — управленческое действие на основе этих данных; объяснено, что без разделения легко спутать «увидеть проблему» с «решить проблему», и решение может не последовать вовремя; упомянуто, что оба понятия связаны, но выполняют разные роли в цикле.
Подсказка: Вспомни совет из блока с советом про то, что решение нужно принимать не постфактум, а вовремя.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Команда тестирует раздел «История обучения» перед релизом, по тест-плану заложено четыре рабочих дня. К середине второго дня метрики показывают: выполнено 20% тест-кейсов вместо ожидаемых по расписанию 45%, найден один дефект с высоким severity (блокирует открытие раздела на мобильных устройствах) и три дефекта с низким severity. Предложи, какое решение по контролю логично принять, и обоснуй его, опираясь на конкретные цифры из сценария.
Критерий приёмки: решение явно опирается на отставание от расписания (20% против ожидаемых 45%) и/или на дефект с высоким severity; предложено конкретное управленческое действие (пересмотр сроков, добавление ресурса, эскалация риска команде разработки — глава 13.3), а не общая фраза «нужно что-то сделать»; обоснование логически связывает цифры сценария с предложенным решением.
Подсказка: Сравни фактический процент выполнения с ожидаемым по расписанию и обрати внимание, что один из дефектов блокирует часть функциональности.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Мониторинг и метрики помогают понять, что происходит ВНУТРИ цикла тестирования. Но рано или поздно цикл заканчивается, и нужно подвести черту: собрать итоговый отчёт и явно сообщить статус — команде и людям, далёким от технических деталей. Об этом — в следующем, завершающем главу уроке.
