Сколько создавать тикетов или багов

В 90-е годы управление процессом разработки было очень простым - нужно просто подойти к программисту и сказать, что нужно написать, а тестеров вообще не было. Когда в 2000-х начали тестировать, то с тестерами процесс работы также был через личное общение. Просто подходишь к человеку и спрашиваешь что надо или просишь сделать все лично. 

Нормально с системами учета заданий я познакомился уже в Клике (Торонто). Первый же проект, который мне дали, состоял из разработки нового функционала для сайта Sony, мне назначили несколько тикетов в написанной Кликом системе, и я начал работать. 

Когда я закончил работать над заданием, то мне сказали назначить всё QA. И тут я понял процесс, что это действительно удобно. Это был 2009-й год. 

И вот я отправляю проект QA, а мне назад возвращают новые тикеты с большим количеством багов. Кажется, в одном из видео на моём YouTube канале Програмысли я говорил про этот момент. Я по старинке подошел к тестеру лично, попросил показать и объяснить, что не так и почему. Проект был огромный, это же eCommerce сайт, и почти все баги были из-за того, что я не знал многих внутренностей и как раз поэтому пошел к тестеру, чтобы он мне объяснил эти внутренности. Он улыбался, все подробно рассказал мне и на взгляд оказался хорошим молодым парнем. 

У нас еще был процесс 360 Review, это когда каждый член команды пишет свое мнение о проекте. И вот подходит время этого Review и меня вызывает начальница и говорит, что тестер написал про меня много плохого, что я сдал плохой и не готовый проект. Человек только недавно улыбался мне в глаза, а потом в спину написал гадости. 

Это нормально для канадцев и американцев улыбаться и создавать видимость дружелюбия, но при первой возможности они вставят вам в спину ножик и провернут его. У меня это было несколько раз. В этом отношении общаться с русскими проще, они тебе в лицо скажут все, что думают и не будут делать это подло в спину. 

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

Я не стал мстить, а наоборот при первой же возможности прикрыл заднее место этого тестера, и он понял, что со мной нужно дружить, потому что я как раз в спину ничего вставлять не собираюсь. Но это отдельная история, кажется, о ней я тоже говорил на своём YouTube канале Програмысли. 

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

Был у меня еще случай, когда мне дали другого тестера, который должен был протестировать редизайн процесса регистрации на сайте и как назло он уходил в отпуск на несколько дней, кажется на 3 дня. Я знал, что он уходит на несколько дней, поэтому в обед подошел к нему и спросил, все ли нормально. Он сказал, что все отлично, тестирование идет полным ходом. В 4 часа мне прилетают сообщения, что на меня назначили 15 новых багов. Нихрена себе – нормально процесс тестирования идет. Открываю баги: 

1. Не показывается логотип на форме регистрации

2. Не показывается логотип на форме подтверждения регистрации

3. Не показывается логотип на форме проверки e-mail

4. Не показывается логотип на форме подтверждения проверки e-mail

5. Не показывается картинка breadcrump, которая показывает процесс регистрации на форме регистрации

6. Не показывается картинка breadcrump, которая показывает процесс регистрации на форме подтверждения регистрации

7. 

Ну вы поняли паттерн. Я просто забыл закомитить картинки, потому что папка картинок была в gitignore, чтобы туда ничего не комитили просто так. Если реально нужно было что-то добавить в репозиторий, нужно было использовать -f при вызове команды git add. Из-за gitignore файлы картинок не показывались, как измененные и поэтому я про них и забыл. 

Еще штук 5 багов были про отсутствующую валидацию, которая просто не была прописана. Да, я согласен, что она была полезна, но можно же было создать только один баг – «Давай добавим валидацию» и все валидации добавить в один баг? Это же удобнее – добавить все валидации за раз и проверить все валидации за раз. 

Две проблемы – отсутствуют картинки и добавить валидацию превратились в 15 багов. И знаете, я не против подойти к этому человеку и объяснить, что это не эффективно и давай объединим все в два бага, но его уже не было за рабочим местом. Он подготовил баги, назначил их мне и ушел домой на несколько дней. Именно это тогда взбесило, и я вернул баги обратно с гневными комментариями. 

Сейчас в компании у нас тоже есть тестер, которая раньше любила создавать множество багов. Стоит где-то чихнуть, она создавала баг. Стоило реально ошибиться, она могла создать 10 багов на одну и ту же проблему на разных страницах. 

Я не против множества багов, если от этого есть выгода. Весь этот процесс создан не для того, чтобы завести как можно больше багов и не для того, чтобы их прятать, а для того, чтобы сделать конечный продукт лучше. Если есть баг, он должен быть исправлен и в систему его заносят не для того, чтобы кого-то потом наказать за ошибку, а для того, чтобы программист знал, что нужно исправить, а тестер знал, что нужно протестировать. Только для этого, а не для наказания кого-то. 

А чтобы исправлять баги эффективно, нужно уметь правильно и хорошо создавать тикеты. Их должно быть минимальное, но необходимое количество. 

Если где-то отсутствует картинка, то это баг. Если такая же картинка отсутствует где-то еще, это все тот же баг, даже если программисту придется менять разные строчки кода и тестеру проверять разные страницы. Подобные вещи должны исправляться одновременно и тестироваться одновременно. 

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

Когда тестеры создают тикеты, то их цель должна быть не создать их как можно больше, а чтобы сделать продукт лучше. В систему вводятся баги не для того, чтобы показать, кто и что налажал, а чтобы исправить проблемы. И мы должны вводить все так, чтобы проблемы решались максимально эффективно. 

Очень важно группировать проблемы по типу и/или странице. Как я уже приводил пример с валидацией. Если сгруппировать все валидации в одно группу, то только один программист будет работать над багом, он решит все проблемы за раз и тестер проверит все за раз.

Но если проблемы разные, но на одной и той же странице, то тут нужно уже думать немного по-другому – будет ли выгода от того, что один и тот же программист/тестер работает над проблемой? Если нет, то лучше завести два бага. В этом случае просто два человека смогут работать над разными проблемами, но одновременно и это тоже по-своему победа. 

Нет ничего плохого в том, что тестер создаст 10 багов, если 10 человек смогут работать одновременно и ни один программист не будет повторять работу другого или тестировать одну и ту же функциональность. 

Чтобы тестеры больше думали об эффективности решения проблем, а не о количестве создаваемых багов, их не должны поощрять за количество, их должны поощрять за качество. Просто это не часто делают, потому что качество сложно оценить. Количество багов – оценить очень легко, а качество результата – очень сложно. 

Что лучше – найти 10 или 100 багов? В процессе разработки – все равно. Это нормально – не находить баги. Главное – сколько багов потом прилетает после запуска от клиентов. 

Вот мне все равно, сколько багов найдет QA в моем коде – 10 или 100, главное, чтобы потом клиенты не нашли ни одного и вот это показатель качества, к которому должны стремиться тестеры и программисты. Находить баги во время разработки – это нормально. Ошибаться – это нормально. А стремление к качеству должно быть не через наказания, а через повышение эффективности работы. 

Так что никогда не ставьте количественные показатели на первый план. Создавайте столько багов, сколько нужно, чтобы сделать проект качественнее. Создавайте минимально, но необходимое количество багов, чтобы потом после каждого из не тестировать одно и то же. 

Помните, что целью тикетов является не оценка качества проекта, а улучшение качества. Не оценка, а именно улучшение. Тестер должен создать баг, чтобы его потом смог пофискить программист, а тестер чтобы протестировать. Особенно если в команде несколько тестеров, нужно писать описание бага так, чтобы программист знал, что исправлять, а любой другой тестер знал, что проверять. 

Баги можно не создаваться если программист может пофиксить проблему за 5 минут и тестер может тут же проверить. Нет такой необходимости - обязательно внести баг в систему. Его обязательно пофиксить, а вносить необязательно. 

Если нет возможности исправить и проверить за 10 минут, то нужно создавать новый баг или тикет. Не дай бог программист скажет: исправлю через пять минут, а через две пойдёт пить кофе или прилетит более важное задание и он забудит пофиксить. Не дай бог тестер не может проверить фикс, и возникнет новая проблема, которая уйдёт к клиенту. Попытки скрыть баги за счёт не создания тикетов может привести к снижению качества.

Я сталкивался с ситуациями, когда программисты просили тестеров не создавать баги из-за какой-то мелочи и обещали пофиксить в течении получаса и реально делали это. Казалось бы, что в этом плохого, если баг быстро исправили и тестер проверил? Для того, чтобы быстро все это провернуть, программист скорей всего переключился на баг и бросил другую работу. Любое переключение задачи отнимает время и это минус.  Он отложил другую работу из-за мелочи и только для того, чтобы не создавать баг и из-за большого количества мелочей потом страдает основной проект и время его доставки. 

Если это реально мелочь - да создайте баг и посмотрите на него позже, когда будет время, не надо тратить время на переключение задач и не бросайте основную работу. 

Но чтобы программисты не боялись багов из-за мелочей я снова вынужден повторить - их работу не должны оценивать по количество созданных багов. 

Багов нужно создавать столько, сколько нужно, чтобы проблему решать эффективно. 

---

Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание