Баг-трекер из прошлого урока хранит дефекты и их движение по статусам. Но где хранятся сами тест-кейсы и чек-листы, которые вы писали в главах 6.1–6.3? Не в личных файлах на компьютере одного тестировщика — для этого есть отдельный класс инструментов, система тест-менеджмента. И ещё один важный вопрос напоследок: что делать, если найденная «проблема» на самом деле не баг, а просто чьё-то пожелание сделать иначе?
Чему научишься за этот урок:
— понимать, зачем нужна система тест-менеджмента и чем тест-ран отличается от самого тест-кейса;
— чётко отличать дефект от запроса на улучшение по одному критерию;
— классифицировать реальные находки на дефект и улучшение с обоснованием.
Где живут тест-кейсы: система тест-менеджмента
Тест-кейсы и чек-листы, которые вы писали в 6.1–6.3, в реальной работе не разбросаны по личным файлам — их хранят централизованно, в системе тест-менеджмента (TestRail, Qase, Zephyr и похожие). Такая система решает три задачи: хранит все тест-кейсы и чек-листы в одном месте, доступном всей команде; группирует их в тест-сьюты — наборы связанных тест-кейсов (вспомните урок 6.2); позволяет запускать тест-ран — прогон конкретного набора тестов на конкретном релизе, с отметкой «пройден / не пройден» по каждому тесту.
Главная польза — именно в связке с багом: когда тест в тест-ране не проходит, из системы тест-менеджмента заводят баг в трекере и связывают его с этим тестом. Так видно не только «что сломано», но и «какой тест это поймал» и «на каком релизе».
Дефект или запрос на улучшение: один критерий
Не всё, что тестировщику кажется неправильным, — дефект. Критерий простой: дефект — это когда реальное поведение системы не совпадает с тем, что прямо заявлено в требовании или документации. Если требование ничего не говорит о конкретном аспекте, а тестировщику просто кажется, что было бы лучше иначе, — это запрос на улучшение (feature request), а не баг.
Дефект Запрос на улучшение ------------------------------------- ------------------------------------- Требование: заявлено прямо Требование: не зафиксировано Факт: расходится с требованием Факт: соответствует, но можно удобнее -> баг заводится в трекере -> предложение уходит в бэклог
Например: кнопка «Оплатить» корректно становится активной после заполнения формы — требование выполнено. Тестировщику кажется, что кнопку удобнее расположить по центру экрана, а не справа. Место кнопки в требовании не зафиксировано — значит, это запрос на улучшение, а не дефект. А вот если промокод, помеченный в требовании как «одноразовый», применяется повторно, — это дефект: факт расходится с прямо заявленным требованием.
Как тест-менеджмент и баг-трекер работают вместе
+----------+ +----------------------+ +--------------------+ +----------------------+ | тест-ран | --> | неудачный тест-кейс | --> | баг в баг-трекере | --> | ссылка на баг у теста| +----------+ +----------------------+ +--------------------+ +----------------------+
Так тест-менеджмент и баг-трекер не дублируют друг друга, а дополняют: один хранит методику проверки — что и как проверять, другой — найденные дефекты и их статус. Связь между ними — это ссылка от неудачного теста на созданный баг.
Итог главы 6 «Тестовая документация и баг-репорты»: за восемь уроков вы прошли весь путь от находки до системного хранения — чек-лист (6.1), тест-кейс и тест-сьют (6.2), тестовый сценарий (6.3), баг-репорт (6.4), локализация и генерализация дефекта (6.5), severity/priority и жизненный цикл бага (6.6), баг-трекер на практике (6.7), тест-менеджмент и разница между дефектом и запросом на улучшение (6.8). Каждый инструмент решает свою задачу: чек-лист и тест-кейс — что проверять, баг-репорт и трекер — что нашли и как это чинится, тест-менеджмент — где всё это системно хранится и как связано между собой.
Контрольный вопрос. Где по-хорошему должны храниться тест-кейсы и чек-листы всей команды?
Подсказка: Централизованное хранилище — не личное, а командное.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Тест-сьют в системе тест-менеджмента — это:
Подсказка: Термин уже встречался в главе про тест-кейсы — он не про баги.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется прогон определённого набора тестов на конкретном релизе в системе тест-менеджмента? Ответь двумя словами.
Подсказка: Вспомни, как в этом уроке называли прогон набора тестов на конкретном релизе — термин встречается в первом же абзаце про систему тест-менеджмента.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Когда тест-кейс в тест-ране не проходит («не пройден»), какие два элемента связывает система по схеме из этого урока (выбери оба)?
Выберите все верные варианты.
Подсказка: Смотри на схему связи тест-менеджмент ↔ баг-трекер в этом уроке.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Дефект — это ситуация, когда:
Подсказка: Критерий этого урока строится на сравнении факта с прямо зафиксированным требованием.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Запрос на улучшение — это ситуация, когда:
Подсказка: Тут поведение совпадает с требованием — вопрос только в удобстве, которое требованием не зафиксировано.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Кнопка «Оплатить» на экране оплаты расположена справа внизу. В требовании к экрану оплаты зафиксировано только то, что кнопка должна становиться активной после заполнения формы, — расположение кнопки в требовании не упомянуто. Тестировщику кажется, что кнопку удобнее было бы разместить по центру. Классифицируй эту ситуацию и ответь одним словом.
Подсказка: Проверь, было ли расположение кнопки прямо зафиксировано в требовании.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Требование к промокоду гласит: «Промокод, уже использованный этим аккаунтом, повторно не принимается». При тестировании выяснилось, что промокод принимается повторно и скидка применяется второй раз. Классифицируй эту ситуацию и ответь одним словом.
Подсказка: Сравни фактическое поведение с тем, что прямо написано в требовании.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Зачем нужен именно тест-ран, а не просто список тест-кейсов сам по себе?
Подсказка: Речь про фиксацию результата именно для конкретной версии продукта, а не про сам список тестов.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Тест в тест-ране не прошёл (провалился). Каким должно быть следующее действие по логике этого урока?
Подсказка: Смотри на схему связи тест-менеджмент ↔ баг-трекер.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На полигоне тестировщик зафиксировал три находки после проверки каталога курсов:
(1) Требование гласит: «Фильтр по цене должен применяться сразу при изменении ползунка, без нажатия кнопки «Применить»». Фактически: список курсов обновляется только после нажатия «Применить».
(2) Список курсов в каталоге отсортирован по дате добавления, самые новые сверху. Требование к порядку сортировки в документации не зафиксировано. Тестировщику кажется, что удобнее было бы сортировать по популярности.
(3) Требование гласит: «Поиск по каталогу должен игнорировать регистр букв». Фактически: поиск «Python» находит курс, а поиск «python» — нет.
Классифицируй каждую находку как «дефект» или «запрос на улучшение» с обоснованием по критерию из этого урока.Критерий приёмки: для каждой из трёх находок указан вердикт (дефект/улучшение) и обоснование, ссылающееся на то, было ли поведение прямо зафиксировано в требовании; находка 1 — дефект (не совпадает с прямо зафиксированным требованием мгновенного применения фильтра); находка 2 — запрос на улучшение (порядок сортировки не был зафиксирован как требование); находка 3 — дефект (регистронезависимость поиска прямо требуется, но не соблюдается).
Подсказка: Для каждой находки спроси: было ли это поведение прямо зафиксировано в требовании, и совпадает ли с ним факт?
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Следующая глава курса — про веб-тестирование, вёрстку, формы и юзабилити: как устроена страница изнутри и что там можно проверить. Вы уже вооружены полным набором тестовой документации, чтобы фиксировать всё, что найдёте.
