Почему быть истеричкой непродуктивно?
Что должен делать тестировщик?
Любой прохожий ответит вам “находить баги”. И будет в чем-то, конечно, прав.
Именно этого ждут от тестировщиков остальные. Как и того, что кот будет ловить мышей — ведь это его природа, его, если хотите, предназначение.
И большинство молодых тестировщиков стремится соответствовать этому мнению, выкладываясь в поиске багов на 146%. И это было бы хорошо, если бы желание завести как можно больше багов не приводило к снижению их качества. Я сейчас говорю не про приоритеты багов, нет. Совершенно не про то, что лучше найти 1 блокер, чем 50 миноров.
Я сейчас говорю о том, что, зачастую, полностью отдавшись цели “наклепать 100500 тикетов”, начинающие тестировщики начинают видеть их там, где их на самом деле нет.
Все же помнят сказку про мальчика, который кричал “волки”? Вот и юные падаваны от тестирования точно так же поднимают панику на любой чих системы, который не соответствует их внутреннему видению продукта, не удосужившись предварительно посмотреть в ЧТЗ или проконсультироваться с аналитиком.
Вот и получается, что подобного рода баг-репорты попадают на стол разработчику. Он тратит своё время на то, чтобы разобраться в сути проблемы. Привлекает аналитика, отрывая его от важных задач. А всё потому, что тестировщику показалось, что там баг.
В рамках подготовки этой статьи нами была собрана статистика по 2 “боевым” проектам Лаборатории Качества. И вот, какие цифры мы наскребли по сусекам:
В среднем, за месяц, тестировщик заводит от 50 до 60 багов. У свежеиспеченных тестировщиков процент реджектов-нотэбагов (дефекты, отклоненные с резолюцией “not a bug”) составляет порядка 20-30%.
Таким образом мы получаем, в среднем, 15 баг-репортов в месяц, которые багов не содержат. Минут 25 потратит совсем зеленый тестировщик на заведение тикета. Минут 5 его наставник (опытный тестировщик) будет пытаться понять, что же там тестировщик завёл. Еще минут 10 будет объяснять, где и что надо поправить в репорте (и почему). И минут 10 разработчик будет скрипеть мозгами перед тем, как выдать на-гора неутешительный вердикт “не баг”.
Вот и получаем мы, в итоге, 50 минут времени на один дефект. А их у нас 15! На выходе видим неутешительную цифру в виде 12-13 часов времени трёх специалистов, потраченных впустую.
Чуть веселее смотрится статистика новичков, уже имеющих опыт в IT- 10 минут на заведение, 5 минут на ревью наставником. В итоге-25 минут на баг, часов 6-7 за месяц.
Понятно, что цифры очень приблизительные и варьируются в зависимости от человека и проекта, но суть та — времени это занимает ой, как немало.
И это не есть хорошо, товарищи.
“А как хорошо?”, — вполне резонно спросите вы. Вот сейчас и поясню: нужно хотя бы немного сдерживать своё неистовое желание наклепать как можно больше тикетов в кратчайшие сроки. Нужно уделять каждому из них чуть больше времени, чем требуется на его заведение. Алгоритм “нашел -> завел” к добру не приведет, поверьте мне).
В первую голову не стоит, найдя что-то, показавшееся вам странным, вопить “здесь бага” и носиться по офису, тревожа всех подряд. Для начала удостоверьтесь в том, что это:
- Воспроизводится (одной повторной проверки будет достаточно)
- Действительно баг (проверьте в ЧТЗ. Если проверка не дала нужного результата — спросите у коллег-старичков на проекте. Если и это не возымело нужного эффекта — тогда уже стоит бежать к аналитику за консультацией).
Потом, когда удостоверитесь в том, что это ДЕЙСТВИТЕЛЬНО баг, нужно озадачиться его локализацией — найти минимально необходимые шаги воспроизведения. Дальше нужно проверить, не задеты ли смежные модули продукта. Проверить, воспроизводится этот баг на каких-то конкретных редко встречающихся тестовых данных или же вылазит в любом месте и для любого пользователя. Воспроизвести баг еще раз, записав логи.
И только после вот этих немудрёных, в принципе, действий, можно идти и заводить баг, приложив к нему результаты ваших исследований.
Тогда ваши репорты будут содержать всю необходимую информацию для скорейшего фикса.
Таким образом вы сэкономите кучу времени другим людям и заработаете репутацию серьезного и ответственного специалиста. И довольные разработчики потратят сэкономленное вами время на то, чтобы поставить лишнюю свечку в церкви за ваше здоровье )