Автор: Мэг МакКей (Meg MacKay) Оригинал статьи Перевод: Ольга Алифанова
Переход от «рассмотрения» к «уточнению» багов
Когда я вышла на работу в мою нынешнюю компанию, в бэклоге было столько багов, что за ними невозможно было уследить. Все знали, что с багами проблемы, но никто не знал, с чего начать. Более того, в команде за короткое время появилось и исчезло множество людей. Изменения происходили на ряде ключевых позиций – сменились вице-президент продукта, главный разработчик, главный QA-инженер и техлид. Сумятицу усиливало и то, что ключевая команда разработки сильно сократилась в объемах, и многим из нас пришлось наряжаться в множество новых шляп.
Как новичок и тестировщик, я должна была поддержать команду в улучшении качества продукта. Но это было возможно только после решения вопроса, как нам работать в изменившихся командных условиях.
Ранее у нас были регулярные встречи по рассмотрению багов, но по различным причинам никто не стремился их воскресить. Я, однако, заметила, что команда считает, что встречи по грумингу фич помогают нам повысить качество кода юзер-стори. Поэтому мы решили применить тот же подход к рассмотрению багов. И так родились сессии по уточнению багов!
Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Что мы имеем? Сложную предметную область, высокую вариативность сценариев и потенциально огромные риски от ошибок с одной стороны, и короткие итерации разработки и частые циклы доставки с другой. Я расскажу о том, как на данный момент при таких вводных выглядят процессы обеспечения качества множества сервисов, которые поставляют всю необходимую информацию нашим торговым терминалам.
Я начал свой путь в компании в конце 2017 года с должности специалиста технической поддержки, некоторое время поддерживал скрипты на python, а затем в мае 2019 года стал тестировщиком.
Здесь и далее я буду употреблять именно слово “тестировщик”, так как согласен с мнением, высказанным в книге “Agile Testing”, что в попытке называть специалистов QС или QA больше желания уйти от негативных ассоциаций низкоквалифицированной должности, чем реальных расширений компетенций. Тем не менее тестировщик в agile, как правило, более t-shaped и оказывает влияние на весь процесс разработки ПО. О выделенных ролях QC и QA, не занимающихся непосредственно тестированием, речи мы не ведем.
В мае 2021 года мне предложили занять должность тест-лида, которая со временем трансформировалась в тест-менеджера. В течение этих трёх с половиной лет мы пару раз меняли подходы к процессам в тестировании: сначала по собственной инициативе, а затем вместе с переходом компании на методологию SCRUM. Мы хотели всё и сразу, убеждались, что это невозможно, интуитивно находили более полезные сценарии действий. А потом читали в книжках, что так давно уже все делают – но без набитых шишек нам бы и не удалось осознать, что это именно то, что нам нужно в наших условиях. Итак, приступим.
