Этот урок объясняет, что тестирование — это не хаотичный поиск багов, а структурированный и управляемый процесс, известный как STLC (Software Testing Life Cycle). В материале подробно разбираются шесть ключевых фаз этого цикла: от анализа требований и планирования до настройки окружения, выполнения тестов и подведения итогов. Также проводится четкое разграничение между тест-стратегией, описывающей общий подход компании, и детальным тест-планом для конкретного релиза. Отдельное внимание уделяется важным метрикам качества, таким как покрытие требований, плотность дефектов и процент багов, «утекших» в продакшен. В итоге студенты узнают, как с помощью этих документов и показателей объективно оценивать прогресс тестирования и принимать обоснованные бизнес-решения о выпуске продукта.

Этот урок посвящен работе с исходной документацией и объясняет, почему четкие требования являются фундаментом любого качественного тестирования. В материале разбираются различия между функциональными требованиями (что система должна делать) и нефункциональными (качественные характеристики, например, скорость работы). Подробно описывается структура User Story и критериев приемки (Acceptance Criteria) в формате Given-When-Then, которые служат прямым основанием для создания тест-кейсов. Особое внимание уделяется навыку критического анализа текста для выявления в нем неоднозначности, неполноты, противоречий и непроверяемости. Также даются практические рекомендации на случай нехватки документации: от изучения дизайн-макетов и рыночных аналогов до прямого диалога с продактом или разработчиком. В итоге студенты учатся не додумывать условия самостоятельно, а профессионально уточнять детали, предотвращая ошибки на самых ранних этапах разработки (подход shift-left).

Этот урок объясняет две ключевые системы классификации тестирования: по степени важности функций и по цели проверки. По значимости выделяются три уровня глубины: Smoke-тестирование (быстрая проверка работоспособности сборки), Critical Path (тестирование основных пользовательских сценариев) и Extended Testing (исследование нестандартных и граничных случаев). По цели проверки различаются тестирование новой функциональности с нуля, регрессионное тестирование (проверка, что изменения не сломали существующий функционал) и ретест (точечная проверка конкретного исправленного бага). Отдельное внимание уделяется практическому алгоритму формирования регрессионного набора: в него обязательно включают критичные для бизнеса функции, часто изменяемые области и модули с исторически высокой плотностью дефектов. Важно понимать, что регрессию почти никогда не проводят полностью — она охватывает только логически связанные с изменениями участки продукта, и её часто автоматизируют для экономии времени. В итоге студенты учатся выстраивать приоритеты тестирования и понимать, с каких проверок начинать рабочий день после каждого обновления продукта.