В уроках 4.1–4.3 вы разбирали требование построчно: искали пропущенные форматы, проверяли пять характеристик, ловили маркеры неопределённости — и всё это ДО того, как разработчик написал хоть одну строку кода. У этой работы есть официальное название — статическое тестирование: проверка документа чтением и анализом, без запуска программы. Противоположность — динамическое тестирование, когда реально нажимают кнопки и смотрят, что происходит на экране; этим курс займётся дальше. Сейчас разберёмся, почему находка дефекта именно на этом, самом раннем этапе, обходится дешевле всего.
Чему научишься за этот урок:
— различать статическое и динамическое тестирование;
— объяснять качественно, почему стоимость исправления дефекта растёт по фазам разработки;
— оценивать, во что реально обойдётся один и тот же дефект, найденный на разных этапах.
Статическое тестирование — это то, чем вы уже занимались
Когда вы ищете в требовании пропущенный формат (4.1), проверяете полноту и непротиворечивость (4.2) или замечаете слово «нормально» без расшифровки (4.3) — вы не открываете приложение, не нажимаете ни одной кнопки. Вы читаете текст и рассуждаете о нём. Это и есть статическое тестирование: работа с документом, а не с работающей системой. Динамическое тестирование начинается позже — когда есть что запускать: страницу, форму, кнопку, готовую функцию. Оба вида нужны, но статическое всегда идёт первым, потому что документ появляется раньше кода.
Почему дефект дорожает с каждой фазой
Представьте противоречие в требовании к промокоду: одна строка говорит «скидка не больше 50%», другая — «промокод даёт скидку 60% в честь распродажи». Если это противоречие заметили в тексте требования, до того как разработчик сел за код, — исправление стоит одной правки абзаца: кто-то из авторов документа уточняет, какое число верное, и текст меняется.
Если то же противоречие не заметили, и разработчик уже написал код по одной из двух цифр — исправление требует переписать код. Если код успели покрыть автотестами, ожидающими именно ошибочное поведение, — тесты тоже придётся переписать. Если функцию уже выпустили, и часть учеников получила скидку 60% вместо 50% — добавляется хотфикс, разбор, кому вернуть разницу, объяснение пользователям и, возможно, недовольство тех, кто заметил разницу в скидках между собой. Дефект один и тот же с самого начала. Дорожает не сам дефект, а количество того, что успело построиться поверх него: код, тесты, реальные данные в базе, ожидания пользователей — и всё это приходится пересматривать, когда правда всплывает.
Требование -> Разработка -> Тестирование -> Продакшен дёшево -------------------------------------------> дорого +---------------+---------------------------------------------+ | Требование | правка абзаца текста | +---------------+---------------------------------------------+ | Разработка | + переписать уже готовый код | +---------------+---------------------------------------------+ | Тестирование | + заново прогнать тесты, найти новые дефекты | +---------------+---------------------------------------------+ | Продакшен | + хотфикс, разбор, кому что вернуть, | | | объяснение пользователям | +---------------+---------------------------------------------+
Точных цифр вроде «дефект после релиза стоит в N раз дороже» тут намеренно нет — конкретный множитель у каждой команды свой. Важна не цифра, а направление: с каждой следующей фазой добавляется ещё один слой работы, которую нужно переделать, а предыдущие слои никуда не исчезают.
Практика на полигоне
На нашем учебном полигоне то же противоречие в требовании к промокоду можно поймать в двух разных точках. Сценарий (а): тестировщик читает требование перед началом разработки, находит нестыковку «50% против 60%» и сразу пишет вопрос автору требования. Сценарий (б): требование не перечитали, разработчик закодировал скидку 60%, функцию выпустили, и часть учеников за неделю успела оформить запись на курс с завышенной скидкой. В обоих случаях дефект один. Разница — в том, что успело произойти вокруг него.
Итог:
— статическое тестирование — это проверка документа чтением и анализом, без запуска программы; динамическое — это работа с уже запущенной системой;
— дефект в требовании не дорожает сам по себе — дорожает то, что успевает построиться поверх него: код, тесты, данные, ожидания пользователей;
— чем раньше поймали дефект, тем меньше придётся переделывать — статическое тестирование требования это самый дешёвый момент для находки.
Контрольный вопрос. Тестировщик читает требование к функции ещё до того, как программист написал код, и ищет в тексте противоречия и пропуски. Как называется такая проверка?
Подсказка: Смотри, запускается ли при этом хоть что-то — программа, страница, форма.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Тестировщик открывает уже работающее приложение, вводит промокод в поле и смотрит, применилась ли скидка. Как называется такая проверка?
Подсказка: Здесь уже есть что запускать и на что нажимать.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. На каком из четырёх этапов один и тот же дефект обходится ДЕШЕВЛЕ всего, чтобы его исправить?
Подсказка: Это тот этап, где дефект — всего лишь строчка текста, а не код и не данные пользователей.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. А на каком из тех же четырёх этапов исправление того же дефекта обходится ДОРОЖЕ всего? Ответь одним словом.
Подсказка: Это этап, на котором дефект уже видят реальные пользователи системы.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Почему дефект в требовании, не пойманный вовремя, дорожает с каждой следующей фазой разработки? Выбери все верные утверждения.
Выберите все верные варианты.
Подсказка: Подумай, что происходит с кодом, тестами и данными по мере того, как проект двигается вперёд, пока дефект остаётся незамеченным.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Противоречие в требовании к промокоду («50% против 60%») заметили ДО того, как разработчик начал писать код. Что минимально нужно сделать, чтобы устранить дефект?
Подсказка: На этом этапе дефект существует только в виде текста — кода и реальных пользователей ещё нет.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. То же противоречие в требовании к промокоду НЕ заметили вовремя: функцию выпустили, и часть учеников уже получила скидку 60% вместо 50%. Какие из уже существующих артефактов — текст требования и написанный по нему код — теперь придётся поправить, чтобы устранить дефект полностью? Ответь одним словом.
Подсказка: Код к этому моменту уже написан по неверной цифре, а требование всё равно нужно привести в порядок, чтобы дальше по нему не работали неправильно.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На полигоне сравни два сценария с одним и тем же противоречием в требовании к промокоду («скидка не больше 50%» против «60% в честь распродажи»): (а) противоречие заметили ДО того, как разработчик начал писать код; (б) противоречие всплыло уже ПОСЛЕ того, как функцию выпустили, и ученики массово получили скидку 60%. Распиши по пунктам, что именно придётся сделать в каждом из двух случаев.
Критерий приёмки: для сценария (а) указано, что достаточно уточнить и переписать текст требования (без кода); для сценария (б) перечислено не менее трёх дополнительных действий из набора: переписать код, переписать/перепрогнать тесты, разобраться с уже начисленными скидками у реальных учеников, объяснить ситуацию пользователям, — общие фразы вроде «всё исправить» не засчитываются.
Подсказка: В сценарии (а) кода ещё нет — там просто текст. В сценарии (б) уже есть код, тесты и реальные ученики со скидкой 60%.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. Дан перепутанный список фаз разработки: продакшен, требование, тестирование, разработка. Перечисли их через запятую в порядке ВОЗРАСТАНИЯ стоимости исправления одного и того же дефекта (от самого дешёвого этапа к самому дорогому).
Подсказка: Вспомни: чем позже нашли дефект, тем больше уже успело построиться поверх него. Это подскажет направление сортировки.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На полигоне пропустили дефект в бизнес-правиле «скидка по промокоду не больше 50%». К моменту, когда дефект наконец заметили, поверх ошибочного правила успели построиться: (1) код скидочного модуля, (2) автотесты, которые проверяют именно ошибочное поведение (скидку до 60%), (3) реальные записи в базе — часть учеников уже получила скидку 60%, (4) статья в разделе помощи, которая объясняет ученикам работу скидки по ошибочным 60%. Сколько из этих четырёх слоёв придётся пересмотреть или переделать, чтобы исправление требования подействовало по-настоящему (не просто на бумаге)? Ответь одной цифрой.
Подсказка: Пересмотреть нужно каждый слой, который был построен на основе неверной цифры — посчитай их все.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что из перечисленного лучше всего описывает идею статического тестирования?
Подсказка: Ключевое слово — «до того как что-либо запущено».
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Что дальше
Вы теперь понимаете, ПОЧЕМУ проверять требования раньше выгодно. Но внимательного прочтения одним человеком не всегда достаточно: автор мог сам не заметить свою ошибку, а один свежий взгляд ловит не всё. Следующий урок — про то, КАК организовать проверку требований формально: какие для этого есть роли, шаги процесса и типы ревью — от лёгкого до самого строгого.
