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

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

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

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

И большинство молодых тестировщиков стремится соответствовать этому мнению, выкладываясь в поиске багов на 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. Действительно баг (проверьте в ЧТЗ. Если проверка не дала нужного результата — спросите у коллег-старичков на проекте. Если и это не возымело нужного эффекта — тогда уже стоит бежать к аналитику за консультацией).

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

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

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

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

Метки
#Тестирование ПО (3)Android (1)Cache (1)Cookie (1)courses (1)css (1)HR (1)iOS (2)istqb (1)ISTQB FL (1)IT (2)java (1)Jedi Point (12)JSON (1)kaizen (2)pairwise (1)QA (25)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)SOAPUI (1)softskills (1)softwaretesting (1)SQA Days-25 (1)sql (5)TestSuites (1)usability (2)web (1)XML (1)xpath (1)Анна Палей (1)БАГИ (1)Исследовательское тестирование (2)Истории поинт (10)История успеха (1)Команда разработки (1)Курс тестирования для начинающих (1)Кэш (1)Лаборатория Качества (1)Мнемоники (1)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)ПОИНТ (43)ПРомо-вебинар (1)Подготовка к istqb (1)Роман Буданов (3)Сессионное тестирование (1)Скриншот (3)ТЗ (1)Таблица решений (1)Тестирование (27)Тестирование ПО (5)Тест менеджмент (2)Тренер (12)Туры (1)автоматизация (2)автотесты (1)алгоритмы (1)баг (1)багнапродакшене (1)безопасность (1)бесплатный вебинар (1)введение в тестирование (1)граничные значения (1)декомпозиция (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (10)как надо тестировать (2)комбинаторика (1)конференция (2)котик (1)курс для начинающих тестировщиков онлайн (1)лайфхак (1)минутка юмора (1)мобилки (3)мобильное тестирование (4)настройка мозгов (1)начать карьеру (1)начать карьеру в IT (1)начинающий тестировщик (8)негативное тестирование (2)обучение тестированию (11)ограничения (1)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)разработчик (1)режим разработчика (3)резюме (1)сертификация ISTQB FL (1)скринкаст (1)смена работы (2)сопроводительное письмо (1)стать тестировщиком (1)стратегия (1)тайм-менеджмент (1)тест-анализ (1)тест-кейс (1)тест дизайн (3)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование веб (2)тестирование игр (3)тестирование мобильных приложений (1)тестировщик (6)тесткейс (1)удаленная работа (1)улучшайзинг (1)ученик (2)фреймворки (1)чеклист (4)чит-листы (1)чит лист (2)что должен делать тестировщик (1)ятренерпоинт (1)
С 19.10 по 5.01, ОНЛАЙН Зарегистрироваться