← вся теориятеория к собесу · Теория тестирования

STLC: процесс тестирования

Процесс тестирования и его этапы

В требовании написано: «скидка при заказе от 10 штук». Десять штук - это уже скидка или ещё нет? Один знак в условии. Пока никто не спросил, разработчик и тестировщик прочитают его одинаково и, возможно, одинаково неправильно - и тест подтвердит баг. Спросить в чате стоит полминуты, узнать после релиза - стоит разбора с поддержкой и возвратов.

Стержень: анализ требований - уже тестирование, а тест-план и критерии этапов существуют, чтобы решения принимались по фактам, а не по ощущению «вроде проверили».

// Формулировки: «какие этапы у процесса тестирования?», «что такое shift-left?», «зачем критерии входа и выхода?».

Этапы и работа с требованиями

Процесс тестирования разворачивается по этапам, у него даже есть аббревиатура - STLC (software testing life cycle). Порядок такой: анализ требований, планирование, проектирование тестов и данных, подготовка среды, выполнение, отчёт и завершение. У каждого этапа свой результат, и «прогон кейсов в конце» - это только пятый пункт из шести.

Первый этап - уже тестирование, просто объект проверки не код, а текст. Что ищут: противоречия между пунктами, дырки (что делать, если оплата прошла, а склад отказал?), неоднозначности вроде тех самых «от 10 штук» и нетестируемые формулировки. «Работает быстро» непроверяемо: быстро - это сколько миллисекунд, при какой нагрузке, для какой доли запросов. Пока цифры нет, проверять нечего, и требование возвращается на переформулировку.

// Это и есть shift-left, сдвиг влево по оси проекта: тестирование начинается раньше кода. Крайняя форма - когда проверки формулируют вместе с требованиями, ещё до написания кода; отсюда подходы ATDD (acceptance test driven development) и BDD (behaviour driven development), где приёмочные сценарии пишутся заранее и служат одновременно требованием и тестом.

STLC: жизненный цикл тестирования: требования, план, дизайн тестов, среда, прогон, отчёт
нетестируемое требование: формулировка без измеримого критерия: «быстро», «удобно»

Трассировка: дыры видно арифметикой

Я взял набор из 12 требований и 18 тестов и просто свёл их в таблицу «требование - какие тесты его проверяют». Тестов в полтора раза больше, чем требований, ощущение полного покрытия. Считаем: два требования не покрыты вообще ни одним тестом, покрытие требований 83%, а один тест не привязан ни к чему - живёт сам по себе, и непонятно, зачем его гоняют.

Такая таблица называется матрицей трассировки: связь «требование - тесты - дефекты». Она отвечает на два вопроса, на которые иначе отвечают наугад. Первый: что мы забыли проверить. Второй: что перепроверять, когда требование поменялось. В моём наборе изменение четвёртого требования задевает ровно два теста из восемнадцати - вот их и надо пересмотреть, а не гнать весь набор на всякий случай.

// Главный вывод из этих цифр: количество тестов ничего не говорит о покрытии. Восемнадцать тестов на двенадцать требований выглядят солидно ровно до момента, когда их разложили по требованиям.

матрица трассировки: таблица связей требование - тесты - дефекты
покрытие требований: доля требований, у которых есть хотя бы один тест

Ворота этапов и честная оценка

Критерии входа и выхода - это объективные условия, при которых этап начинается и заканчивается. Вход в тестирование: сборка собралась, среда развёрнута, смоук зелёный - это быстрая проверка на несколько минут, что приложение вообще поднялось и главные экраны открываются. Без таких ворот половина найденных «багов» окажется недоразвёрнутой средой, и время уйдёт на разбор собственного окружения. Выход: запланированные проверки пройдены, открытых критичных дефектов нет, известные проблемы описаны и приняты. Тест-план фиксирует всё это плюс скоуп - что тестируем и что осознанно не тестируем, - риски и роли, но живым документом, а не бумагой для галочки.

Теперь про оценку сроков, на которой валятся чаще всего. Считаем честно: 40 кейсов по 12 минут - это 480 минут, 8 часов. Именно эту цифру обычно и называют. Но дефекты найдутся примерно в четверти кейсов: 10 штук, и каждый добавляет работы - оформить репорт 10 минут, потом ретест (повторный прогон того же сценария на новой сборке) 12, потом проверки вокруг 20. Итого 420 минут сверху, ещё 7 часов. Реальность - 15 часов против обещанных 8, промах почти вдвое.

// В коротких итерациях этапы не исчезают, а сжимаются: анализ, дизайн и прогон идут внутри спринта параллельно разработке, критерии качества входят в определение готовности задачи (то самое definition of done - список условий, при которых задачу можно считать сделанной), а регресс - перепроверка всего, что работало раньше, - без автоматизации перестаёт помещаться в темп.

критерии входа / выхода: объективные условия старта и завершения этапа
оценка с буфером: к прогону добавлены репорты, ретесты и проверки вокруг

Как отвечать: «Что такое shift-left и зачем QA на этапе требований?»

Shift-left - это сдвиг тестирования влево по оси проекта, к самому началу, вместо привычного «QA подключается, когда код готов». Смысл в экономике дефекта. Возьмите требование «скидка при заказе от 10 штук». Десять - это уже скидка или ещё нет? Если никто не спросил, разработчик и тестировщик прочитают его одинаково, и тест подтвердит неправильное поведение. Вопрос аналитику стоит полминуты в чате. Тот же вопрос после релиза - это правка кода, сборка, ретест, регресс вокруг, разбор с поддержкой и деньги, возвращённые клиентам. Поэтому на этапе требований я, по сути, тестирую текст: ищу противоречия, незакрытые ветки вроде «оплата прошла, а склад отказал», и нетестируемые формулировки - «быстро» возвращаю с вопросом, сколько это миллисекунд и при какой нагрузке. Дальше это перерастает в проектирование тестов до кода: приёмочные сценарии пишутся вместе с требованием и работают и как требование, и как тест. Итог - дефекты ловятся там, где они стоят дёшево, а не бетонируются в коде.

Почему это сильный ответ: термин определён, экономика показана на конкретной двусмысленности «от 10 штук», названа реальная работа QA с текстом требований и переход к проектированию тестов до кода.

На чём валят

−Подключать тестирование после кода: двусмысленность в требовании к этому моменту уже забетонирована.
−Пропустить критерии входа - половина «багов» окажется недоразвёрнутой средой.
−Считать число тестов покрытием: 18 тестов на 12 требований, а два требования не проверены вообще.
−Не вести связь требований и тестов: требование поменялось, что перепроверять - гадаем.
−Оценивать только прогон: 8 часов превращаются в 15, как только считаешь репорты, ретесты и проверки вокруг.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.

#stlc_process1 / 5
Что задают критерии входа (entry) и выхода (exit) для фазы тестирования?
A)Entry — это дата начала проекта, а exit — календарная дата его сдачи заказчику по договору
B)Entry — когда фазу можно начинать; exit — когда её можно считать завершённой
C)Entry задаёт условия завершения фазы, а exit — условия, при которых её можно начинать
D)Оба критерия относятся к найденным дефектам и не связаны с покрытием и окружением
показать ответ и разбор
+B)Entry — когда фазу можно начинать; exit — когда её можно считать завершённой
// разбор: Критерии входа и выхода делают переходы между фазами объективными, а не «на глаз». Entry-критерии — что должно быть готово, чтобы начать: стабильный билд прошёл smoke, развёрнуто тестовое окружение, готовы тест-кейсы и данные, доступны требования. Exit-критерии — при каких условиях фазу можно закрыть: выполнено запланированное покрытие, все критичные дефекты исправлены и перепроверены, оставшиеся риски приемлемы и согласованы, уложились в отведённое время/бюджет. Без чётких exit-критериев тестирование либо обрывают произвольно, либо оно тянется бесконечно. Обычно их фиксируют в тест-плане заранее.
#stlc_process2 / 5
Что обычно входит в тест-план?
A)Пошаговые инструкции воспроизведения каждого конкретного тест-кейса с ожидаемым результатом
B)Список всех найденных за проект дефектов с их серьёзностью, приоритетом и текущим статусом
C)Объём и цели, что тестируем и что нет, подход, ресурсы, расписание, риски, критерии
D)Исходный код автотестов и конфигурацию CI-пайплайна для их автоматического запуска
показать ответ и разбор
+C)Объём и цели, что тестируем и что нет, подход, ресурсы, расписание, риски, критерии
// разбор: Тест-план — документ, отвечающий на «что, как, кем и когда мы тестируем» для конкретного проекта или релиза. Типичное содержание: цели и объём (features in/out scope — что покрываем и что осознанно нет), подход и уровни/виды тестирования, требования к окружению и данным, ресурсы и распределение ролей, расписание и вехи, риски и меры, критерии входа/выхода и приостановки/возобновления, поставляемые артефакты. Тест-план конкретен и привязан к проекту (в отличие от более общей и долгоживущей тест-стратегии). Он согласуется с командой и служит опорой для оценки и контроля хода тестирования.
#stlc_process3 / 5
Чем тест-стратегия отличается от тест-плана?
A)Стратегия детально описывает шаги одного релиза, а план — общие принципы всей организации
B)Это одно и то же: оба термина обозначают документ с пошаговыми тест-кейсами проекта
C)Тест-стратегию пишут после завершения проекта, а тест-план — по его итогам
D)Стратегия — общий долгоживущий подход организации; план — конкретика под релиз
показать ответ и разбор
+D)Стратегия — общий долгоживущий подход организации; план — конкретика под релиз
// разбор: Тест-стратегия задаёт общие правила игры: принципы, стандарты, уровни и виды тестирования, инструменты, подход к автоматизации и управлению дефектами — обычно на уровне организации или продукта, меняется редко и применяется ко многим проектам. Тест-план конкретизирует стратегию под данный проект/релиз: объём, расписание, ресурсы, риски, критерии входа/выхода именно здесь и сейчас. То есть стратегия — «как мы вообще тестируем», план — «как мы тестируем этот релиз». В небольших командах их иногда объединяют в один документ, но концептуально это разный уровень абстракции и срок жизни.
#stlc_process4 / 5
Как правильно определить момент остановки тестирования?
A)По заданным exit-критериям и приемлемому остаточному риску, а не по «багов нет»
B)Останавливаемся ровно в тот момент, когда в продукте не осталось ни одного дефекта
C)Останавливаемся, когда выполнены все написанные тест-кейсы, независимо от их результата
D)Останавливаемся, когда закончился рабочий день последнего тестировщика на проекте
показать ответ и разбор
+A)По заданным exit-критериям и приемлемому остаточному риску, а не по «багов нет»
// разбор: «Когда багов не останется» — недостижимый ориентир: исчерпывающее тестирование невозможно, а новые дефекты можно находить бесконечно. Поэтому момент остановки определяют осознанно, по совокупности критериев, зафиксированных заранее: достигнуто запланированное покрытие требований/кода, все критичные и высокоприоритетные дефекты закрыты и перепроверены, частота находок упала, оставшиеся известные риски оценены и приняты стейкхолдерами, исчерпаны отведённые время и бюджет. Это управленческое решение на основе риска: релизим с известным, приемлемым уровнем остаточного риска, а не ждём мифического нуля дефектов.
#stlc_process5 / 5
В чём особенность роли тестировщика в Agile/Scrum по сравнению с водопадом?
A)Тестировщик подключается на финальной стадии спринта, когда вся разработка завершена
B)Тестирование идёт непрерывно внутри спринта; QA вовлечён с груминга требований
C)Роль тестировщика в Agile и в водопаде идентична: отдельная большая фаза проверки в конце
D)В Agile тестирование заменяется автотестами, и ручной тестировщик не нужен
показать ответ и разбор
+B)Тестирование идёт непрерывно внутри спринта; QA вовлечён с груминга требований
// разбор: В водопаде тестирование — отдельная поздняя фаза после того, как всё разработано, и дефекты всплывают в конце, когда их дорого чинить. В Agile тестирование встроено в каждую итерацию: QA участвует уже в обсуждении и груминге пользовательских историй (уточняет критерии приёмки, тестируемость требований — shift-left), тестирует функции по мере готовности внутри спринта, тесно работает с разработчиками, а инкремент к концу спринта должен быть проверенным и потенциально релизным. Часто применяют автоматизацию регресса и практики вроде ATDD/BDD. Ценится T-shaped специалист, участвующий во всём цикле, а не «принимающий» продукт в самом конце.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Теория тестирования