Аналитик с 15-летним стажем Ольга делится историей о том, как забывчивость в мелочах чуть не сорвала релиз, и предлагает шесть дополнительных пунктов для чек-листа приёмки требований в тестирование.
Ольга возглавляет направление аналитики в продуктовой команде корпоративного страхования и выступает наставником. Однажды в слаженный коллектив с прозрачными процессами пришёл новый аналитик — и выяснилось, что не всё так гладко, как казалось. Базовый чек-лист передачи задачи в тестирование включал девять пунктов: задача в Jira со ссылкой на требования, отдельная страница с требованиями, структура запроса с методом, заголовками и типом взаимодействия, описание ограничений (обязательность, типы полей, размерность, структура хранения), перечень интеграций с адресами стендов, контакты смежных команд, ролевая модель, а также метрики и события для журналов и аудита.
По документации требовалось добавить новый метод расчёта тарифа с учётом промоакций. Разработчик реализовал всё строго по описанию и не ошибся, но QA настаивал: старая функциональность в текущей конфигурации работает, а новая — падает. На разборе выяснилось, что изменения не внесли в шлюз безопасности. Аналитик поняла: часть важных для тестирования деталей обсуждалась неформально, на ходу, и в задаче для разработчика не фиксировалась.
После долгой и продуктивной беседы чек-лист пополнился шестью пунктами, полезными не только новичкам. Первый — степень влияния изменений на процесс: это новый процесс или глобальная переделка существующего, включая новые точки отказа. Второй — затрагиваются ли авторизация, ролевая модель и другие условия доступности продукта (например, внедрение графика тиражирования, новая роль, смена разрешений). Третий — замена одного конфигурационного элемента другим: миграция с legacy или переезд на целевую систему аудита может не менять функциональность, но для тестирования это критично.
Четвёртый пункт — остаются ли неизменными адреса стендов. Для интерфейса это катастрофа: придётся получать новые доступы, перенастраивать автотесты и заново прогонять полное тестирование, включая нагрузочное. Пятый — есть ли изменения на стороне системы-потребителя: к примеру, после введения новых правил валидации она не должна принимать данные от нас. Шестой — указать версию приложений и всех узлов, где изменения должны появиться в сборке.
В финале Ольга задаёт вопрос, который редко звучит в подобных инструкциях: не станем ли мы рабами собственных инструментов? Когда команда гонится за галочками в чек-листе и забывает о смысле, помощник превращается в надзирателя. Её пожелание — не терять критического мышления и гибкости.
Загрузка...
