Должен ли тестировщик придираться к мелочам?
вторник, августа 04, 2009 Во время очередного батального сражения рабочего дня столкнулся с проблемой программистом, который в упор не хотел признавать, что допущенные при выполнении задачи мелочи тоже должны быть исправлены.
Проблема заключается в том, что уточнения по этим мелочам были получены по почте, а не указаны в таске сразу. Внесение изменений в таск с учетом таких мелочей заняло у программиста много времени, теперь же я прошу их убрать. Что вызывает естесственную реакцию противления: «Я убил столько времени, а теперь это все убрать???»
Собственно в этом и вопрос: На сколько придирчивым внимательным к мелочам должен быть тестировщик? Стоят ли такие мелочи напряжения в команде?
Мой ответ: всё зависит от сути этой «мелочи». Если на неё обратил внимание заказчик или другое важное лицо, то ответ очевиден. Если эта «мелочь» касается GUI, то я бы тоже хотел исправления таких «мелочей». Если же эта «мелочь» более внутренняя бага или мало заметная для пользователя, или заказчик даже не уточнил, как он хочет это видеть, тогда зеленый свет — программист может пока расслабиться и не исправлять такие мелкие замечания.
Кстати, в какую сторону едет автобус?
Ответ:в лево, ведь дверей не видно!
Он стоит.
Он же картинка :)
Если предположить, что предполагаемый автобус начинает двигатся в одну из сторон: лево либо право. Если при этом предположить предположение направления, то что вы выберете?
Влево.
Предполагаю, что у автобуса есть двери, и они расположены на его правом боку. Значит, автобус, коий на картинке, мы наблюдаем, стоя на противоположной стороне улицы.
А движение у нас правосторонее. И если он поедет по маршруту, то поедет влево.
Однако этот ответ построен на предположении ("предположить предположение направления"), а не на наблюдении. А мой ответ построен именно на наблюдении. WYSISWYG :)
Дело в том, что зачастую взрослые люди не способны думать просто... Этот тест обычно ставит втупик взрослых людей, в то же самое время дети отвечают правильно без задержек.
А мы, тестировщики, в свете своих профессиональных "заболеваний" обращаем внимание на мелочи. Вы первый. кто сказал, что он стоит... остальные же гадали направление. ;)
Похлопывая самого себя по плечам: "Мы круты!"
Совершенно не удивляюсь тому, что взрослый не может определить направление автобуса, ведь взрослый ЗНАЕТ, что у автобуса спереди установлен водитель с рулем и педалями. На картинке нигде не указан этот важный атрибут, поэтому получается очередной буриданов осел...
Ребенок может и не знать вообще, что автобусу нужен водитель, и считает двери за обязательный атрибут автобуса. Оп, а двери не видно! Дальше понятно.
По-моему, чистоту эксперимента нарушает это самое "тут должна быть дверь" - тоже ведь, установка... А если вместо двери использовать модель автомобиля?
Я в детстве ориентировал аналогичное направление автомобиля по "папе, который за рулем". Каждого человека за рулем я считал чьим-то папой. Без "папы за рулем" мне бывало сложно понять направление автомобиля, ведь все они для меня были на одно "лицо".
Вернемся к теме беседы - почему у вас тестировщик определяет, что именно должно быть пофиксено? Тестировщик докладывает о проблемах, а решение принимает вышестоящее лицо. Или там - то, что видит нижестоящий, когда обращается к вышестоящему...
И вопросы в записи слегка смешаны. Да, тестировщик должен быть очень придирчив к мелочам, ибо дьявол в мелочах.
Но он должен понимать, что так просто на пинг "А, блин, не то, давай, эт-та, отменяй!" ни один программист не ответит "Ура, я отменю одним движением результат двух дней работы!!!"
Тут, скорее, подойдет метод вопросов и пряников, а не "Понимаешь... Ты ведь должен понимать, что все зависит от сути этой мелочи... Вот эта - высокоприоритетна, начальник по багам тут я, и разумеется, надо откатиться, поэтому..." Это естественно вызовет напряжение.
Поэтому - пряники, бублики, кексы, и полное "взял вину на себя"...
Поэтому - пряники, бублики, кексы, и полное "взял вину на себя"...
Я всё понимаю.. но ведь программисты не дети, а тестеры не их родители, чтобы понимать и входить в положение. Это работа комманды, поэтому нужно быть готовым к разным ситуациям.
Дык именно потому, что они не дети, к ним подход нужен, почти как к детям...
Ребенка-то всегда можно в угол поставить, если "он не понимает" :)
Имхо, тестировщик обязан быть внимательным ко всему. К мелочам в том числе.
Решая судьбу мелкого дефекта, стоит принять во внимание не только его суть, но и количество подобных вещей в программе. Отдельно взятый минорный баг – не слишком большая проблема, на то он и мелочь. Но проблема точно появляется, когда эти мелочи накапливаются в большом количестве. С программой становится очень некомфортно работать пользователю (на каждом шагу спотыкаешься об эти шероховатости). И ее становится трудно тестировать, т.к. постоянно отсеивая эти известные дефекты, теряешь остроту внимания.
Polyanna, вот-вот ...
Иногда мелкие дефекты приобретают более высокий приоритет.
Основанием для этого могут служить разные причины:
- внимание заказчика к этому вопросу;
- большое количество таких дефектов(то, о чем вы писали);
- откровенное неудобство пользования программой из-за этого, даже одного дефекта;
- если этот дефект - орфографическая ошибка (считаю такое вообще нельзя пропускать в релиз);
- много-много всего, что просто сейчас не приходит в голову...