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

Когда я приехал в Канаду, то мало что слышал про тикеты. На работе в Интерстепе в 2008-м году у нас приобрели Jira, но в реальности мы так и не начали нормально ей пользоваться, потому что даже не понимали, зачем это все нужно. Нафиг нужны тикеты, когда можно подойти к чуваку за соседним столом и попросить – сделай фишку или исправь бак плиз. 

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

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

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

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

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

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

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

Был у меня еще случай, когда мне дали другого тестер, который должен был протестировать редизайн процесса регистрации на сайте и как назло он уходил в отпуск на 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, главное, чтобы потом клиенты не нашли ни одного и вот это показатель качества, к которому должны стремиться тестеры и программисты. Находить баги во время разработки – это нормально. Ошибаться – это нормально. А стремление к качеству должно быть не через наказания, а через повышение эффективности работы. 

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

---

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