Ранее я предположил, что все тестировщики делятся на два типа: Гарантировщик и Проверяльщик, которых я сравнил с хирургом и медсестрой. Сравнение, несомненно, навеяно Бруксовой книгой «Мифический человеко-месяц или Как создаются программные системы». Но сравнение точное.
Подобное “ролевое” разграничение слишком жестко определяет взаимоотношения между этими двумя товарищами. В медицине хирург всегда будет хирургом, и сколько бы ни подавала ему скальпель медсестра, она все равно останется медсестрой. Более того, хирург начал учиться “сразу на хирурга”, а не “сперва на медсестру”… В области IT, как уже говорилось, ролевые рамки более легко преодолимы, медсестра может вечерами “резать по-живому” посредством компьютера, и в какой-то момент сможет делать операции самостоятельно. “Если”, конечно.
Предположим, что молодой тестировщик еще не хочет становиться программистом, потому что это крайность. Пока что он хочет стать опытным тестировщиком. Потом очень опытным. А потом вообще – Гарантировщиком.
Как именно “начинающий тестировщик” становится “опытным тестировщиком”? Только ли временные промежутки помогают ему наработать этот опыт? Изменения в этой области скорее качественные, а не количественные. Можно и два года работать “плохо”. А можно и за полгода стать “зверем”, который “рвет всех”.
Как?
Мы ведем репортаж из здания свинофермы “Новые зорьки”. Откроем дверь отдела “QA”, и посмотрим на товарищей тестировщиков вблизи.
Сегодня в “Новых зорьках” тяжелый день – рождены новые, модифицированные поросята, которые в большей степени отвечают потребностям рынка (непрестанное повышение качества услуг…). Гарантировщик давал свиноматкам особенные, нечеловеческие корма, знакомил их с нестандартными свинокобелями, пел по вечерам арии Ленского и чесал за ушком. После всех этих действий свиномамы должны были принести ему обновленных поросят, “Поросенок v2.0”. Принесли, вот. Теперь этих поросяток надо проверить на соответствие ожиданиям.
Гарантировщик говорит своему Проверяльщику: “Будем проверять так: ты тестируешь GUI поросят, а я – их кишочки, потому что там копаться надо, тебе сложно будет. Бери тест-комплекты на поросячьи интерфейсы, и шуруй…“
Проверяльщик шурует, и начинает крутить-вертеть поросенка, отмечая наличие и/или отсутствие всего того, что понаписано в тест-кейсах.
Тест-кейс “Про пятачки” гласит: “Осмотреть поросенка спереди, найти “пятачок”. Ожидаемый результат: Поросенок оснащен пятачком. Пятачок укомплектован двумя ноздрями.” Кейс отмечен как “пройден”, но усердный тестировщик крутит поросенка дальше, переступая через жесткие рамки тест-кейсов.
О боже!
Баг!
Есть баг!
Тестировщик делает скриншот бага на поросенке, открывает баг-трекер, и пишет, пишет, пишет…
Читаем описание бага: “Поросенок оснащен пятачком и двумя ноздрями. А если повернуть поросенка другой стороной, то легко обнаружить третью ноздрю, расположенную в области хвостика…” Приложена крупная картинка “третьей ноздри”.
Опыт – сын ошибок. Можно посмеяться над молодым тестировщиком или отправить его на заготовку кормов, но рвение молодого тестировщика похвально. Он не остановился на тест-кейсах – это следует похвалить.
Поэтому опытный Гарантировщик, оторвавшись от поросячьих кишочков, без ругани “закроет” баг с пояснением, почему это не баг. Пояснение будет максимально подробно вписано в трекер, с ссылками на спеки (если есть).
Чем больше “не багов” будет закрыто в баг-трекере, тем больше и чаще молодой тестировщик будет знать, что есть баг, а что не есть. Это же будут знать его последователи, которые несомненно появятся в коридорах свинофермы “Новые зорьки”.
Внимательным просматривальщикам этого текста уже понятно, что я проповедую занесение всех “не багов” в багтрекер наравне со всеми багами.
По-моему, это является основой обучения и превращения молодого тестировщика в немолодого, опытного, косматого волка, который “крутит поросят” одной левой (правой он делает пометки в тест-кейсах).
Что важно знать: надо знать и определить момент, когда молодой тестировщик становится тестировщиком немолодым. Ибо если тестировщик опытен, знает поросят “на уровне производителя”, но все еще заносит “не баг”, это вызовет раздражение и у Гарантировщика, и у свиномамы.
Особо раздраженные начинающими Проверяльщиками свиномамы даже публично заявляют, что чем больше “не багов” заносит на багтрекер тестировщик, тем достойнее он для отправки на заготовку кормов.
“Особо раздраженные” в этом случае не правы в принципе. Они правы только в мелочах.
“Не баги” всегда будут появляться. И если их не заносить сегодня, то их занесут “завтрашние” проверяльщики.
“Не баги” тоже надо заносить в багтрекер, во имя обучения нынешних и будущих поколений Проверяльщиков, которые когда-то станут Гарантировщиками. Или же не станут, потому что бросят все и уедут жить на берег моря…
Третья дырка у порося – затронуло до глубины души )
Все бы было хорошо и правильно… но… это не работает на больших проектах. Во-первых, если проект большой, часто у тестировщиков просто нет времени прочитать все существующие баги, физически. Это неправильно, но жизнь есть жизнь.
Во-вторых, за баги, не являющиеся багами никто тестировщика не похвалит (это мягко сказано). Как минимум попросят быть внимательнее и постараться больше таких “багов” в багтреккер не добавлять. Почему? Это довольно очевидно. “Хирург” не всегда может проверить все баги, открытые “проверяльщиками”. Хирург – он обычно один, а “проверяльщиков” может и быть несколько. За всеми не углядишь, да и своей работы у него хватает. Что получается в таком случае? Баг передается девелоперу для дальнейшего изучения и исправления. Девелопер доказывает, что баг не является таковым. Что получается в этом случае? Потеряли как минимум время. Время тестировщика на описание бага, может еще не дай бог скриншоты, время девелопера на изучение бага и возможно, на описание того, почему он считает баг невалидным. Итого – несколько человеко-часов. Тех самых, за которые платит клиент. Потеряли зря, из-за неквалифицированности тестировщика. Кроме того, в проектах, где ведется статистика – испортили статистику – кол-во багов стало больше, пусть даже и не валидных. Но бог с ней, статистикой . А что если девелопер, к которому попал вот такой невалидный баг не разобрался до конца и “профиксил” его. Да – внес те самые ненужные изменения…убрал ту самую “третью дырку у поросенка”. НА самом деле очень часто так бывает – девелопер получил баг. Написано – исправить это на это. Написано – значит надо делать, сделал, исправил. У поросенка нет третьей дырки. Код не работает. Кто виноват? Тестировщик, который открыл такой баг.
Так что опыт показывает что за не баги, занесенные в багтреккер надо наказывать, как минимум следить за тем, что бы такое не повторялось. За что наказывать? За незнание функционала, спецификаций и технических заданий как минимум. Конечно, все мы люди, все ошибаемся, но отвечать за качество, в том числе и за качество открытых багов, приходится тестировщику.
…это не баг – это фича!
Автор всегда славился замысловатыми аллегориями, но в этой статья он превзошел самого себя!
по существу – реакция девелопера на подобные псевдобаги в зависимости от разного рода причин может быть разной. Начнем с того что мне лично не жутко нравится само слово баг, вот неприятно и все тут. В свое время я попросил нашего как-бы тестера и партнеров по проекту заменить его на слово “фикса”, ибо бытует стереотипное мнение что допускающий баги девелопер – плохой девелопер.
1 вариант – Едить, колотить !!! Неужели не понятно что это ЖОПА!
2 вариант – Хорошо, ладно – вы там самые умные да? Зашиваем третью ноздрю! А когда кокашки из ноздрей полезут тогда посмотрим кто здесь умный.
На самом деле я крайне уважительно отношусь к тестированию. Но, имхо большое количество псевдобагов в трекере никому кроме медсестер пользы не принесет.
Рацуха – ввести промежуточный термин “фикса” – для “сомнительных” багов, которые будут попадаться на глаза девелоперу после “одобрения” Хирургом.
А мне нравится !
Аллегории автора близки и понятны.
(стаж в тестировании 7 лет)
согласен с Адесой-Мамой 🙂
стаж всего 2,5 года. но тоже через тернии прошёл. )))))
считаю хорошим делом заносить “небаги”. главное, чтобы контроль был норм за ними. чтоб трёху не зашивали канеш быдлокодеры