В прошлом уроке мы прошлись по всем семи разделам тест-плана, но один раздел намеренно оставили на потом — критерии входа и выхода. Пора закрыть этот пробел: разберём, как понять, что тестирование МОЖНО начинать, и как понять, что его МОЖНО считать завершённым. Заодно разберёмся, как вообще прикинуть объём предстоящей работы, прежде чем составлять расписание.
Чему научишься за этот урок:
— объяснять разницу между критериями входа и критериями выхода тестирования;
— по описанию ситуации определять, выполнен критерий входа или выхода или нет;
— называть способы оценки объёма тестирования.
Критерии входа: когда тестирование можно начинать
Критерии входа (entry criteria) — это условия, которые должны выполниться ДО того, как тестировщик приступит к работе. Без них легко потерять время впустую: тестировщик начинает проверку нестабильной сборки, находит десяток дефектов, а через час выясняется, что разработчик забыл выложить последнюю версию — и половина находок вообще не про ту сборку. Типичные критерии входа: сборка развёрнута на тестовом стенде и доступна; требования зафиксированы и прошли ревью (вспомните главу 4 — статическое тестирование и типы ревью); тестовые данные подготовлены (глава 1.6); тест-кейсы написаны и согласованы для той функциональности, которую предстоит проверять.
Критерии выхода: когда тестирование можно считать завершённым
Критерии выхода (exit criteria) — это условия, при которых тестирование можно закрыть и переходить к следующему этапу (например, к релизу). Типичные критерии выхода: все запланированные тест-кейсы выполнены; критичных по серьёзности (severity — вспомните главу 6.6) открытых дефектов не осталось; покрытие требований (глава 5.8 — «Покрытие: что считаем и зачем») достигло согласованного заранее уровня, например все условия тестирования из тест-анализа (глава 4.6) проверены хотя бы одним тест-кейсом.
Оценка объёма тестирования
Прежде чем расставлять критерии входа и выхода в расписание, нужно прикинуть, сколько вообще работы предстоит. Точной формулы нет, но есть три опоры, на которые можно положиться: количество условий тестирования, полученных на тест-анализе (глава 4.6) — чем их больше, тем больше тест-кейсов и времени потребуется; количество уже написанных тест-кейсов — если тест-дизайн (глава 5) уже сделан, оценка становится точнее; опыт с похожими задачами — если раньше уже тестировали похожую по сложности функциональность и известно, сколько это заняло времени, эту цифру можно использовать как ориентир. Это не точная наука, а обоснованная оценка: она не претендует на точность до часа, но остаётся куда надёжнее интуитивного «ну, дня три, наверное».
ДО начала КРИТЕРИИ ВХОДА тестирование идёт КРИТЕРИИ ВЫХОДА ПОСЛЕ
(готовность) -> - сборка на стенде -> (выполнение - все тест-кейсы -> (можно закрывать
- требования выполнены и переходить
зафиксированы, - критичных к релизу)
прошли ревью дефектов нет
- тестовые данные - покрытие требований
готовы на согласованном
- тест-кейсы уровне
согласованы
Пример на нашей платформе
Вернёмся к разделу «Отзывы о курсах» из прошлого урока. Критерии входа: раздел развёрнут на тестовом стенде; требования на форму отправки отзыва и шкалу оценки прошли ревью; подготовлены тестовые учётные записи с разными ролями (обычный ученик, ученик без завершённых курсов); тест-кейсы на позитивные и негативные сценарии ввода (глава 5) написаны и согласованы. Критерии выхода: все тест-кейсы по форме отправки, шкале оценки и отображению отзывов выполнены; открытых дефектов severity «критичный» или «высокий» (глава 6.6) не осталось; базовый чек по границам роли manual QA в безопасности (глава 12) пройден без находок. Оценка объёма: на тест-анализе для этого раздела получилось 6 условий тестирования — форма, шкала, отображение, длина текста, спецсимволы, роль ученика без курсов, — по опыту с похожим разделом «Комментарии к урокам» такой объём укладывается примерно в три рабочих дня одного тестировщика.
Частая ошибка новичка — считать критерием выхода «нашли 0 багов». Это нереалистично: чем дольше искать, тем больше шанс найти ещё один дефект, и по этой логике тестирование никогда не закончится. Критерии выхода — это не про отсутствие всех дефектов, а про допустимый ОСТАВШИЙСЯ уровень риска: команда сознательно решает, что оставшиеся некритичные дефекты приемлемы для релиза, а критичных не осталось.
Итог:
— критерии входа — условия ДО начала тестирования: готовая сборка, согласованные требования, подготовленные тестовые данные и тест-кейсы;
— критерии выхода — условия завершения: выполненные тест-кейсы, отсутствие критичных дефектов, достигнутый уровень покрытия требований, а не «ноль багов»;
— объём тестирования оценивают по количеству условий тестирования, количеству тест-кейсов и опыту с похожими задачами — это обоснованная оценка, а не точная наука.
Контрольный вопрос. Что такое критерии входа (entry criteria)?
Подсказка: Слово «вход» указывает на начало, а не на завершение работы.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Тестировщик хочет начать проверку новой сборки, но она ещё не развёрнута на тестовом стенде. Какой раздел тест-плана прямо про эту ситуацию?
Подсказка: Речь про условие, которое должно выполниться ДО начала тестирования.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Почему критерий выхода «нашли 0 багов» — плохая формулировка?
Подсказка: В уроке прямо объяснено, почему такая логика не работает практически.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какая из трёх опор, названных в уроке, помогает оценить объём предстоящего тестирования?
Подсказка: Вспомни главу 4.6 — там впервые появились условия тестирования как результат разбора требования.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие из перечисленных пунктов в уроке названы типичными критериями ВЫХОДА (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Последний вариант — это условие ДО начала работы, а не завершения.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как по-английски называются условия, при которых тестирование можно считать завершённым? Ответь двумя английскими словами через пробел.
Подсказка: В уроке этот термин дан в скобках сразу после русского названия.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Команда собирается тестировать раздел «Отзывы о курсах», но требования на форму отправки отзыва ещё не прошли ревью. Какой раздел тест-плана говорит, что тестирование в этой ситуации начинать рано? Ответь двумя словами.
Подсказка: Речь про условие ДО начала, а не про завершение работы.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тестировщик выполнил все тест-кейсы по разделу «Отзывы о курсах», но осталось два открытых дефекта severity «критичный» (глава 6.6). Какой из трёх типичных критериев выхода, названных в уроке, из-за этого НЕ выполнен? Ответь так, как этот критерий назван в уроке (несколько слов).
Подсказка: Вспомни, что именно должно случиться с критичными дефектами, чтобы критерий выхода считался выполненным.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях, почему критерий выхода «нашли 0 багов» неверен и что вместо него на самом деле стоит за формулировками вроде «критичных дефектов не осталось».
Критерий приёмки: объяснено, что требование «0 багов» нереалистично, потому что вероятность найти ещё один дефект не падает до нуля никогда; указано, что реальные критерии выхода говорят про допустимый ОСТАВШИЙСЯ уровень риска, а не про полное отсутствие дефектов; упомянуто, что команда сознательно решает, какой остаточный риск (например, некритичные дефекты) приемлем для релиза.
Подсказка: Вспомни абзац про «частую ошибку новичка» в этом уроке и что там сказано про допустимый уровень риска.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Команда готовит тестирование раздела «Оплата курса». На тест-анализе получилось 9 условий тестирования (проверка суммы, способы оплаты, обработка отказа платежа и другие). Похожий по сложности раздел «Промокоды на подписку» с 5 условиями команда тестировала два рабочих дня одним тестировщиком. Оцени примерный объём предстоящего тестирования раздела «Оплата курса» и обоснуй свою оценку, опираясь на способы оценки объёма из этого урока.
Критерий приёмки: указана примерная оценка (в рабочих днях), выведенная из сравнения количества условий тестирования (9 против 5, то есть заметно больше) с опытом похожей задачи (2 дня на 5 условий); явно названо, что это ОБОСНОВАННАЯ оценка, а не точная формула, и число условий — не единственный фактор (например, оплата может требовать больше проверок на условие из-за более высокой цены ошибки).
Подсказка: Сравни количество условий у двух разделов и оттолкнись от уже известного факта — сколько заняла похожая по духу задача.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Мы разобрали, как понять, что тестирование можно начинать и можно ли считать его завершённым. Но критерии входа сами по себе не защищают от того, что пойдёт не так уже В ПРОЦЕССЕ: сборка задержится, окружение окажется недоступным, единственный тестировщик заболеет. В следующем уроке разберём риски — и продукта, и самого процесса тестирования — и подход risk-based testing, который помогает решить, что проверять в первую очередь, когда времени не хватает на всё.
