Под «апельсином» в этой статье будем понимать не качество продукта целиком, а тот контур функциональной проверки, в котором пересекаются ручное и автоматизированное тестирование. На качество влияют разработчики, аналитики, менеджеры и вся продуктовая команда, но здесь речь пойдет о более узкой задаче: как двум способам проверки работать согласованно и давать команде единый, понятный сигнал о состоянии продукта.
Пока объем автоматизации, число окружений и количество обязательных прогонов невелики, многие решения держатся на общем контексте: всем понятно, что уже покрыто, что проверяется вручную, какие наборы запускать и кто разбирает падения. По мере роста продукта эта очевидность исчезает. Нужно согласованно выбирать кандидатов на автоматизацию, запускать нужные проверки на нужных конфигурациях, разбирать результаты, фиксировать ручную компенсацию и сохранять актуальную картину покрытия. Проблема не в количестве людей или тестов как таковых, а в отсутствии воспроизводимого способа принимать эти решения.
Меня зовут Михаил Шалепо, я старший инженер по тестированию в InfoWatch. Я собрал повторяющиеся ситуации, в которых ручное и автоматизированное тестирование зависели от неявного контекста, и оформил их в единый процесс. В статье я покажу не только итоговую структуру документа, но и инженерную логику каждого его раздела — что именно мы фиксируем, зачем это нужно и какой результат должен остаться после каждого этапа.
У нас уже были 2 пакетика ручные проверки, и автотесты, и целое множество дефектов всех сортов и расцветок. Дефекты находились, тестовые наборы запускались, но отдельные действия не складывались в сквозной процесс. Не всегда было явно определено, как команда принимает решение о пополнении очереди на автоматизацию, кто валидирует смысл нового автотеста, какие существующие наборы обязательны для фичи и релиза, кто владеет падением и когда его можно компенсировать ручной проверкой. Из‑за этого готовность фичи и релиза могла опираться не на единые критерии, а на знание конкретных людей.
