Должен ли тестировщик придираться к мелочам?

Во время очередного батального сражения рабочего дня столкнулся с проблемой программистом, который в упор не хотел признавать, что допущенные при выполнении задачи мелочи тоже должны быть исправлены.
Проблема заключается в том, что уточнения по этим мелочам были получены по почте, а не указаны в таске сразу. Внесение изменений в таск с учетом таких мелочей заняло у программиста много времени, теперь же я прошу их убрать. Что вызывает естесственную реакцию противления: «Я убил столько времени, а теперь это все убрать???»
Собственно в этом и вопрос: На сколько придирчивым внимательным к мелочам должен быть тестировщик? Стоят ли такие мелочи напряжения в команде?
Мой ответ: всё зависит от сути этой «мелочи». Если на неё обратил внимание заказчик или другое важное лицо, то ответ очевиден. Если эта «мелочь» касается GUI, то я бы тоже хотел исправления таких «мелочей». Если же эта «мелочь» более внутренняя бага или мало заметная для пользователя, или заказчик даже не уточнил, как он хочет это видеть, тогда зеленый свет — программист может пока расслабиться и не исправлять такие мелкие замечания.

Кстати, в какую сторону едет автобус?

Ответ:в лево, ведь дверей не видно!

Из-под пера Maksim Grinevich

Тэги: , , ,
Нашли ошибку в тексте? Выделите её мышкой и нажмите Ctrl + Enter.

Ещё по данной теме:


9 ответов, оставьте свой...:

  1. Алексей Лупан отметил:

    Он стоит.
    Он же картинка :)

  2. Maksim Hrynevich отметил:

    Если предположить, что предполагаемый автобус начинает двигатся в одну из сторон: лево либо право. Если при этом предположить предположение направления, то что вы выберете?

  3. Алексей Лупан отметил:

    Влево.

    Предполагаю, что у автобуса есть двери, и они расположены на его правом боку. Значит, автобус, коий на картинке, мы наблюдаем, стоя на противоположной стороне улицы.

    А движение у нас правосторонее. И если он поедет по маршруту, то поедет влево.

    Однако этот ответ построен на предположении ("предположить предположение направления"), а не на наблюдении. А мой ответ построен именно на наблюдении. WYSISWYG :)

  4. Maksim Hrynevich отметил:

    Дело в том, что зачастую взрослые люди не способны думать просто... Этот тест обычно ставит втупик взрослых людей, в то же самое время дети отвечают правильно без задержек.

    А мы, тестировщики, в свете своих профессиональных "заболеваний" обращаем внимание на мелочи. Вы первый. кто сказал, что он стоит... остальные же гадали направление. ;)

  5. Алексей Лупан отметил:

    Похлопывая самого себя по плечам: "Мы круты!"

    Совершенно не удивляюсь тому, что взрослый не может определить направление автобуса, ведь взрослый ЗНАЕТ, что у автобуса спереди установлен водитель с рулем и педалями. На картинке нигде не указан этот важный атрибут, поэтому получается очередной буриданов осел...

    Ребенок может и не знать вообще, что автобусу нужен водитель, и считает двери за обязательный атрибут автобуса. Оп, а двери не видно! Дальше понятно.

    По-моему, чистоту эксперимента нарушает это самое "тут должна быть дверь" - тоже ведь, установка... А если вместо двери использовать модель автомобиля?

    Я в детстве ориентировал аналогичное направление автомобиля по "папе, который за рулем". Каждого человека за рулем я считал чьим-то папой. Без "папы за рулем" мне бывало сложно понять направление автомобиля, ведь все они для меня были на одно "лицо".

    Вернемся к теме беседы - почему у вас тестировщик определяет, что именно должно быть пофиксено? Тестировщик докладывает о проблемах, а решение принимает вышестоящее лицо. Или там - то, что видит нижестоящий, когда обращается к вышестоящему...

    И вопросы в записи слегка смешаны. Да, тестировщик должен быть очень придирчив к мелочам, ибо дьявол в мелочах.

    Но он должен понимать, что так просто на пинг "А, блин, не то, давай, эт-та, отменяй!" ни один программист не ответит "Ура, я отменю одним движением результат двух дней работы!!!"

    Тут, скорее, подойдет метод вопросов и пряников, а не "Понимаешь... Ты ведь должен понимать, что все зависит от сути этой мелочи... Вот эта - высокоприоритетна, начальник по багам тут я, и разумеется, надо откатиться, поэтому..." Это естественно вызовет напряжение.

    Поэтому - пряники, бублики, кексы, и полное "взял вину на себя"...

  6. Maksim Hrynevich отметил:

    Поэтому - пряники, бублики, кексы, и полное "взял вину на себя"...

    Я всё понимаю.. но ведь программисты не дети, а тестеры не их родители, чтобы понимать и входить в положение. Это работа комманды, поэтому нужно быть готовым к разным ситуациям.

  7. Алексей Лупан отметил:

    Дык именно потому, что они не дети, к ним подход нужен, почти как к детям...

    Ребенка-то всегда можно в угол поставить, если "он не понимает" :)

  8. Polyanna отметил:

    Имхо, тестировщик обязан быть внимательным ко всему. К мелочам в том числе.

    Решая судьбу мелкого дефекта, стоит принять во внимание не только его суть, но и количество подобных вещей в программе. Отдельно взятый минорный баг – не слишком большая проблема, на то он и мелочь. Но проблема точно появляется, когда эти мелочи накапливаются в большом количестве. С программой становится очень некомфортно работать пользователю (на каждом шагу спотыкаешься об эти шероховатости). И ее становится трудно тестировать, т.к. постоянно отсеивая эти известные дефекты, теряешь остроту внимания.

  9. Maksim Hrynevich отметил:

    Polyanna, вот-вот ...
    Иногда мелкие дефекты приобретают более высокий приоритет.
    Основанием для этого могут служить разные причины:
    - внимание заказчика к этому вопросу;
    - большое количество таких дефектов(то, о чем вы писали);
    - откровенное неудобство пользования программой из-за этого, даже одного дефекта;
    - если этот дефект - орфографическая ошибка (считаю такое вообще нельзя пропускать в релиз);
    - много-много всего, что просто сейчас не приходит в голову...