Процесс и управление тестированием

Привязывайте покрытие к требованиям, а не только к строкам кода. Матрица трассировки сопоставляет каждое требование с проверяющими его тест-кейсами, так что требование без связанного кейса — видимая дыра. Сочетайте это с риском: сперва покрывайте высокорисковые области. Покрытие достаточно, когда каждое требование протрассировано и остаточный риск приемлем.

С документацией вы тестируете по спецификации — выводя кейсы из требований и проверяя соответствие. Без неё опираетесь на исследовательское тестирование: изучаете продукт, используя его, строите ментальную модель и судите поведение по здравому смыслу и аналогичным продуктам. На незадокументированное поведение не считайте его багом — пометьте, спросите аналитика или PO и подтвердите ожидание до заведения.

Пирамида тестирования предписывает много быстрых, дешёвых unit-тестов в основании, меньше интеграционных/сервисных в середине и мало медленных, хрупких UI/e2e-тестов наверху. Она балансирует скорость, стоимость и уверенность. Применять её — значит толкать каждую проверку на самый низкий уровень, способный поймать баг, и избегать антипаттерна-рожка со слишком многими UI-тестами и слишком малым числом unit.

Waterfall идёт последовательными фазами (требования → дизайн → разработка → тестирование → релиз) с малым перекрытием и поздним тестированием. Scrum итеративен: спринты фиксированной длины дают инкременты, роли — Product Owner, Scrum Master и команда разработки. Kanban — непрерывный поток без спринтов: работу тянут по доске под лимитами WIP (work-in-progress, незавершённая работа).

A/B-тестирование делит живой трафик между двумя вариантами (A и B) и измеряет, какой лучше по метрике — например, даёт ли зелёная кнопка «Купить» больше конверсии, чем красная? Это техника экспериментов/оптимизации, а не поиска дефектов: оно сравнивает результаты статистически, а не сверяет поведение с требованиями, как функциональное тестирование.

Alpha-тестирование проходит внутри компании, до релиза, на стороне разработчика — силами внутренних сотрудников (часто QA или выбранных работников) в контролируемой среде. Beta-тестирование проходит снаружи, позже в цикле, в реальной среде настоящих конечных пользователей, которые сообщают о проблемах из почти-боевого использования. Alpha — внутри и раньше, beta — в реальном мире и позже.

Статическое тестирование изучает артефакты без запуска кода — ревью, walkthrough, инспекции и статический анализ. Динамическое выполняет ПО и проверяет его поведение. Статическое находит дефекты раньше и дешевле всего, до появления кода. Ревью — его основная ручная форма: peer review тест-кейсов или требований ловит неоднозначность, которую динамический прогон не вскрыл бы дёшево.

Тестовая стратегия — высокоуровневый, часто общий для организации или продукта документ, описывающий общий подход к тестированию — уровни, виды, инструменты, стандарты — и меняется редко. Тест-план привязан к проекту или релизу и выводится из стратегии: задаёт объём, сроки, ресурсы, окружения, критерии входа/выхода и риски конкретной работы.

Тест-анализ отвечает на вопрос ЧТО тестировать: изучить тестовый базис (требования, спецификации, риски) и вывести тестовые условия для покрытия. Тест-дизайн отвечает КАК тестировать: превратить эти условия в конкретные тест-кейсы техниками вроде классов эквивалентности, граничных значений и таблиц решений. Анализ выявляет, дизайн производит кейсы.

Session-based тестирование дробит исследовательское тестирование на тайм-боксовые сессии (обычно 60–120 мин), каждую ведёт чартер — короткая миссия, что исследовать, какие области или риски и на каких данных. Тестировщик фиксирует находки и покрытие в session sheet, затем проводит дебриф. Так исследование становится учитываемым и отчётным без прописывания каждого шага заранее.

Совпадать должны измерения, меняющие поведение: объём данных, версии сервисов и библиотек, сеть, конфигурация, флаги, продоподобная нагрузка. Синхронизируйте через infrastructure-as-code, чтобы окружения не дрейфовали с эволюцией прода. Отличайтесь лишь ради безопасности — маскированные данные, sandbox-креды. Докажите паритет, сверив версии и конфигурацию и прогнав smoke рисковых потоков.

Начните с продукта, его пользователей и рисков — риск-ориентированный подход решает, куда вкладываться. Введите сперва лёгкую документацию (чек-листы, затем кейсы для критичных потоков) и определите критерии входа/выхода. Постройте smoke-набор для приёмки сборки и растущий regression-набор, а исследовательское тестирование применяйте там, где спеки тонкие. Заведите workflow багов: репорт → триаж по severity/priority → фикс → проверка. Встройте его в релизный цикл с CI-гейтами и отслеживайте метрики (просочившиеся дефекты, покрытие, время цикла), доказывающие, что процесс работает.