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