Почему быть истеричкой непродуктивно?

Что должен делать тестировщик?

Любой прохожий ответит вам “находить баги”. И будет в чем-то, конечно, прав.

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

И большинство молодых тестировщиков стремится соответствовать этому мнению, выкладываясь в поиске багов на 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 за месяц.

Понятно, что цифры очень приблизительные и варьируются в зависимости от человека и проекта, но суть та — времени это занимает ой, как немало.

И это не есть хорошо, товарищи.

“А как хорошо?”, — вполне резонно спросите вы. Вот сейчас и поясню: нужно хотя бы немного сдерживать своё неистовое желание наклепать как можно больше тикетов в кратчайшие сроки. Нужно уделять каждому из них чуть больше времени, чем требуется на его заведение. Алгоритм “нашел -> завел” к добру не приведет, поверьте мне).

В первую голову не стоит, найдя что-то, показавшееся вам странным, вопить “здесь бага” и носиться по офису, тревожа всех подряд. Для начала удостоверьтесь в том, что это:

  1. Воспроизводится (одной повторной проверки будет достаточно)
  2. Действительно баг (проверьте в ЧТЗ. Если проверка не дала нужного результата — спросите у коллег-старичков на проекте. Если и это не возымело нужного эффекта — тогда уже стоит бежать к аналитику за консультацией).

Потом, когда удостоверитесь в том, что это ДЕЙСТВИТЕЛЬНО баг, нужно озадачиться его локализацией — найти минимально необходимые шаги воспроизведения. Дальше нужно проверить, не задеты ли смежные модули продукта. Проверить, воспроизводится этот баг на каких-то конкретных редко встречающихся тестовых данных или же вылазит в любом месте и для любого пользователя. Воспроизвести баг еще раз, записав логи.

И только после вот этих немудрёных, в принципе, действий, можно идти и заводить баг, приложив к нему результаты ваших исследований.

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

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

Метки
Android (1)courses (1)HR (1)iOS (1)java (1)kaizen (2)QA (7)QualityLab (1)selenium (1)softwaretesting (1)sql (4)TestSuites (1)usability (2)БАГИ (1)Исследовательское тестирование (2)Истории поинт (6)Курс тестирования для начинающих (1)Мнемоники (1)Мнемоники в тестировании (1)Нина Агеева (4)ПОИНТ (26)ПРомо-вебинар (1)Роман Буданов (3)Скриншот (1)Тестирование (9)Тестирование ПО (1)Тренер (11)Туры (1)автоматизация (2)алгоритмы (1)баг (1)безопасность (1)введение в тестирование (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (6)как надо тестировать (2)конференция (1)котик (1)курс для начинающих тестировщиков онлайн (1)мобилки (2)мобильное тестирование (2)настройка мозгов (1)начинающий тестировщик (4)негативное тестирование (2)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)режим разработчика (2)резюме (1)сопроводительное письмо (1)тайм-менеджмент (1)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование мобильных приложений (1)тестировщик (4)улучшайзинг (1)ученик (2)фреймворки (1)чит лист (1)что должен делать тестировщик (1)
С 15.07 по 9.09, ОНЛАЙН Зарегистрироваться