Записки программиста

Снова и снова я сталкиваюсь с тем, что QA, тестировщики, или как их там у вас называют, не умеют нормально писать багрепорты. Что хуже, они и не хотят учиться делать это правильно. Что намного хуже, часто это касается не только QA и багрепортов, а команды и тикетов вообще в Jira, Trello, или чем вы там пользуетесь.

Рассмотрим пример. Имена, события, предметная область и вообще — все вымышленное.

Создается тикет. Название: «Не пришла котировка». Описание: (пустое). Статус: Блокер. Эстимейт: 4 часа. Исполнитель: ты, чувак.

Какая котировка, куда не приходит, почему считается, что она вообще должна приходить, как воспроизвести проблему, в каком из окружений следует ее воспроизводить, хотя бы примерное время или какой-нибудь id — ничего нет.

Ну ОК, программист может попытаться угадать. Хорошо, если в системе есть какой-то источник вообще всех котировок, назовем его, например, QProducer, а также единственный приемник этих котировок, пусть будет QConsumer. Для определенности пусть продьюсер с консьюмером будут микросервисами, а котировки от продьюсера к консьюмеру будут литься по JSON стриму. Также эти микросервисы предоставляют какой-то REST API, притом некоторые ручки являются отладочными и предназначены специально для заглядывания в стейт микросервисов.

Из описания задачи и знания того, что тестирование обычно производится в окружении test, программист делает вывод, что не доходят вообще никакие котировки в окружении test. Он дергает ручку для добавления котировки в QProducer, затем дергает ручку для просмотра текущих котировок в QConsumer. Все приходит. Повторяем эксперимент пять раз — вроде все ОК. Что теперь?

В общем, через пару часов на работу приходит создавший задачу QA, долго и мучительно вспоминает, что за задача, в чем именно там была проблема и тд. Выясняется, что проблема в действительности была на stage, где крутится билд недельной давности, и проявлялась она не для всех котировок, а только для определенных значений ask и bid.

На вопрос «А что мешало написать все это в задаче» коллега сообщает дескать «Ты понимаешь, у меня нет времени…». А стоящий рядом PM поддакивает, мол «Незачем играть в бюрократию, у нас же Agile». Вам может показаться, что я преувеличиваю. Если и так, то преувеличиваю я совсем немного. И нет, такое происходит больше, чем в одной компании.

Ну то есть у человека, заводившего тикет, времени нет, а у меня времени на угадывание, что же имелось в виду, навалом. Нет, поймите меня правильно. Мне лично вообще пофигу. Как говорит один мой знакомый, «пожалуйста, любой каприз за ваши деньги». Можно работать и так. Задача заводится просто чтобы не забыть о проблеме. Потом, когда до этой задачи доходят руки, проблема обсуждается голосом. Это ОК. Просто я действительно считаю, что пять минут, потраченные на нормальное описание задачи, сэкономят кучу времени.

Не нужно пытаться понять, что же имелось в виду, недоуменно читая логи и смотря в метрики, не нежно ждать момента, когда исполнитель и постановщик одновременно появятся в офисе, не нужно долго вспоминать, что же там была за проблема неделю назад, а потом пытаться правильными словами это объяснить.

Лично у меня есть подозрения, что истинная причина хреновых багрепортов заключается не в нехватки времени, а в лени. Создается новая таска. Название: «Не пришла котировка на stage». Описание: «(1) через отладочную ручку кладем в QProducer котировку EUR/USD с ask = 1.2598, bid = 1.2596, (2) смотрим котировки в QConsumer, (3) видим, что ask и bid другие». Совсем несложно, правда?

Вообще, хороший подход — описывать проблему в виде истории мол делал то-то и то-то, ожидал получить одно, а увидел другие. И постановщику написать не сложно, и исполнителю все понятно.

Разумеется, все написанное выше в существенной степени применимо и к обычным задачам, не багам. А сталкивались ли вы с описанной проблемой, считаете ли вы ее вообще проблемой и если да, как с ней боролись?

Метки: Разработка, Тестирование.