понедельник, 18 января 2016 г.

Там баг в коде был, поправил, тестируй!

Тестирую сравнивалку типа «Araxis merge»

Araxis merge сверяет два текста и подсвечивает 
различия между ними

Открываю два документа, система падает с NPE — NullPointerException. По логу не могу понять, в чем дело и завожу задачу. В этом случае разработчику быстрее локализовать баг.

И правда, разработчик «пришел, увидел, победил», за 15 минут исправил и передал в тестирование с комментарием «Поправил, документы там нормальные, просто косячок был».

Просто косячок был? о_О
И как мне это тестировать теперь? Как проверять, что исправлено? Что исправлялось то? «Косячок»...
Пишу в скайп:

разработчик: пофиксил
тестировщик: а что там было?
тестировщик: «просто был косячок» — что за комменты, блин?
разработчик: бага в коде

Да да, резко стало понятнее, правда ведь?

тестировщик: "тестируйте все"
тестировщик: что-то исправил -_-
разработчик: построение дифа
разработчик: в этом участке

Иди и проверяй «этот» участок. И ничего, что тестировщик пока не в курсах, что такое «ЭТОТ участок»...

тестировщик: в каком участке?
тестировщик: почему другие документы не развалились?

Подошла вживую, пообещала заводить баги «Результат: работает некорректно, ожидаемый: работает корректно», вытянула клещами локализацию. Баг был, когда в одном тексте была заполнена строка с одной стороны, а с другой — нет. Вернулась к себе, поправила название, указала локализацию для истории.

Это история из серии «Как описывать баги», только со стороны разработчика... Если уж локализовал за тестировщика, так подскажи, где косяк то, а не просто «Что-то исправил, тестируйте все»... Потому что через неделю придется вернуться к багу и будем вместе сидеть вспоминать, в чем там проблема то была...

Разработчику такое описание позволительно, а вот нам — нет Wink ;)

См также:
Как заводить задачи в баг-трекер — чтобы потом не возникали вопросы

2 комментария:

  1. Позволю себе комментарий:

    Во-первых, мне здесь видится, что проблема обоюдная: Тестировщик не разобрался в чем баг, программист не рассказал что пофиксил. Описывая баг, вы точно понимать почему он происходит, иначе мы скатимся к "что-то где-то не так с этим файлом" и "должно правильно работать". Конечно же бывают неочевидные вещи, которые только вод жестким дебагом локализовать можно, но это бывает не часто.

    Ну и второе, может это не гибко, но баги/таски в багтрекере надо заводить всегда. Иначе код меняется можно сказать бесконтрольно. Да и учет времени вести проще, когда етсь баги, таски и т.д.

    ОтветитьУдалить
    Ответы
    1. Ну так я второе и использую :)
      Безусловно, баги надо локализовывать и это задача тестировщика. Но бывает, что быстрее попросить помощи разарботчика, нежели самому копаться в коде.

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

      Удалить