пятница, 18 ноября 2011 г.

"Бага не повторяется!", сказал программист, не читая условия

Навеяно разбором кейса от Александра Орлова.
Очень понравился третий пункт - мягко провести диалог, повернув его в нужное тебе русло. Не каждый так умеет. У меня бы первой реакцией было нахамить в ответ на хамство :)) А у вас?

Предлагаю разобрать кейс тестировщиков.
Думаю, вам будет знакома ситуация.

Она меня, если честно, вообще в шок повергла ))))
Итак, есть права доступа - "право 1" и "право 2", созвучные, но разные.
Есть элемент, который открывается из "места 1" и "места 2".

Находим ошибку, заводим:
"Выбрав право 1, переходим на элемент из места 1... *описание ошибки*
При этом если перейти к элементу из места 2, все будет ОК".

По баге прилетает вопрос - как же так, она не повторяется. Меняю права, так как работаю уже с другим - все повторяется. Опять вопрос: "Нет, вот, я ставлю право 2 и ...". "Конечно, не повторяется, в описании совсем другая роль выбрана".

ОК, передаем разработчикам. Бага возвращается с комментарием "не воспроизводится". Опять лезу, выполняю предварительные шаги (ну а вдруг и правда не воспроизводится, всякое бывает, была бага, потом раз и нету, потому что ее поправили, делая другое). Да все же повторяется. Помня о первом сомнении, отписываюсь "Все повторяется. Проверь, то ли право ты выбрал и из того ли места перешел". То есть даже дается подсказка, где человек мог ошибиться и неверно прочитать.

Нет, не повторяется и точка. В доказательство прикрепляется линк... На элемент, открытый из места 2 -_-
Хотя это специально было оговорено в теле баги + в комментариях )))))

Итак! Как вы ведете себя в таких ситуациях?

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

Я пока выбрала звонок в скайпе. Ну и по возможности больше визуализации))) То есть рисунков. Правда, в данном примере я все же настаиваю на точном (и коротком! Там не было захламления текстом, в результате чего может возникнуть недопонятость) описании, к которому рисунки излишни.

21 комментарий:

  1. В данном случае остается только расширение каналов коммуникации:

    Звонок.
    Картинки.
    Видеозапись.
    Дойти лично.

    Ну и для избежания подобных эксцессов - с программистом пить кофе\чай и поинтересоваться - как он смотрел.
    Без претензий, к тому, что он не читает.

    Ответы - могут натолкнуть на мысль по другому оформлять дефекты, например :)

    ОтветитьУдалить
  2. Если мы с разработчиком в одной комнате, самый быстрый способ - позвать его (или самой подойти) и показать.
    Если он далеко, то к багу прикрепляю дополнительную видеозапись. Скриншоты в таких случаях менее эффективны, т.к. на них не видна последовательность действий.

    ОтветитьУдалить
  3. Особая сложность в кейсе - именно удаленная работа, "лично" всегда проще, я согласна :)

    На счет оформления дефектов, опять же, курсивом я признаю, что иногда "мысль скачет" и тд - я пишу непонятно. Я пытаюсь исправиться )))

    Но данный кейс:
    Все четко, по шагам. Шага 4-5, то есть нет кучи текста.
    Снизу отдельной строкой интеграция *а вот оттуда все ок, проблемы только при выполнении п.3*.
    Тут картинки просто излишни, информация не сложная для восприятия

    ОтветитьУдалить
  4. если дадите парочку примеров описания багов, то можем провести анализ и найти проблему, если она есть...

    ОтветитьУдалить
  5. Так пример описан )))
    Выше написано, что мы имеем. Описание баги:

    "1. ставим Ольге роль:
    *право 1*
    2. *место 1*
    3. добавляем элемент в это место 1
    Заходим под Ольгой
    5. *место 1*

    Видим "элемент отсутствует", хотя должны видеть. При переходе в элемент через место 2 мы их видим"

    Ну и комментарий:
    "*ссылка на место 2*. Все там есть!"

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

    Поэтому меня очень веселило, когда баги возвращались описанные по шагам. Приходила к ним, вставала над душой и мы учились читать))) То есть при мне программист все делал по моим шагам и оп-ля :) Бага таки воспроизводится)))

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

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

    Клиент: Здраствуйте, у меня ничего не работает.
    Саппорт провайдера: На кого договор зарегистрирован?
    Клиент: На меня.
    Саппорт провайдера: У Вас фамилия есть?
    Клиент: да.

    ОтветитьУдалить
  7. Я бы посоветовал для решения таких проблем вместо текстового описания записывать автоматизированный скрипт на Selenium IDE к примеру. Включили на запись и прокликали. Потом подправили чтобы надежно повторялся и отправили разработчику по скайпу или почтой. И у него не возникнет сомнений в месте 2 он или в месте 1 и под какой ролью. Просто и быстро. А вы потом проверите, запустив тот же скрипт. После этого можете его выкинуть или сделать частью тестового набора. Как пожелаете. :)

    ОтветитьУдалить
  8. Однако ))))
    Интересное решение...

    Но, в принципе, ситуацию быстрее разрулить звонком по скайпу\мобильному, чем написанием скрипта))))
    Тут, во-первых, не каждый умеет писать скрипты.
    Я только учусь и с релогином еще ничего не писала (а в примере надо действовать под одним логином, потом под другим), мне будет намнооооого дольше писать скрипт :)

    А во-вторых. Почему мы приходим к нормальному описанию багов? Ведь так хочется, просто дать ссылку и все. Но это если быстро поправят, когда еще свежо воспоминание. А бывает, что бага всплывает через пару месяцев или ее правят через пару месяцев, ну вот отложили.

    В итоге ты, вроде сам писал, автор жеж. Открываешь багу, и не можешь понять, как же ее смоделировать. Так как ссылка уже не рабочая. А шаги поленились писать))) А если вы не можете вспомнить, что имели в виду, разработчик тем более не вспомнит)

    Так и со скриптом. Написали, разрулили. А может и нет, написали, приложили в джиру. А исправлялось позже. А скрипт уже нерабочий, что-то поменялось. И все ))) И та же проблема :)

    Да, и кстати, в "прокликали" даже такой начинающий, как я, уже давно не верю)))) Это "прокликали" валится слишком легко

    ОтветитьУдалить
  9. 90% ваших действий вполне адекватно запишет Selenium IDE. Для этого даже делать ничего дополнительно не потребуется. Особенно в случае, когда вы не делаете изменений в приложении. И этого предостаточно чтобы передать разработчику.

    Теперь по поводу описания бага. Вы правда считаете что шаг "кликаем на кнопку Login" и click //button[text()="Login"] будут столь розниться для разработчика? Да это практически одно и то же. Вы же не для первоклассника пишете. А если уж так сомневаетесь, то снабдите скрипт комментариямии. Тогда, даже если к нему вернутся через месяц, то сценарий будет понятен.

    Вместо того, чтобы критиковать, вы возьмите и попробуйте так сделать. ;)

    ОтветитьУдалить
  10. То есть вы, фиксируя баги, вместо описания шагов вставляете скрипты?)

    Я с таким никогда еще не встречалась)))
    Но - для разработчика оно, может и будет понятным, а для меня? =)
    А если я не единственный тестировщик? И у нас далеко не все автоматизаторы.

    Да и для автоматизатора. Все же запись русским языком более читабельна. чем скрипт, ну для меня по крайней мере. И обращаясь к баге "потом", удобнее читать шаги, а не скрипт. Тем более что шаги предельно ясные. Это-то и возмутило, ладно бы фыркали, когда я непонятно описала (что бывает), а то я пишу... А для кого пишу)))

    + Заказчики у нас ну совсем не автоматзаторы, а джиру читают. Так что полная замена шагов шагами из IDE невозможна.
    А комментарий в виде скрипта.

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

    И он прочтет в них ровно то же самое. Прочитает "место 1", и все равно полезет через место 2. Смысл то моего поста был - когда все описано, а тебе возвращают с комментарием, противоречащим твоему описанию.

    Я ведь не просто критикую, я себе даже могу представить реакцию своих (и уже не своих) программистов, если им дать код теста и сказать "запустите у себя". Прочитают и сделают, но врядли запустят. Еще и возмутятся, что у них нет времени на глупости.

    Так что весьма интересно, если у кого-то эта практика работает)))

    Хотя я все равно буду ее критиковать, так как двойную работу делать не хочется, а если шаги все равно писать - зачем писать и шаги, и код?) А если вставлять код уже на стадии "я не понял даже по шагам", то проще же позвонить, диалог лучше письма, живой совсем хорошо, но его не будет

    ОтветитьУдалить
  11. Так ставить практически ничего и не нужно. Просто плагин к Firefox. А если разработчик узнает, что можно будет багу повторить ничего не читая, а просто запустив скрипт, то будет просто счастлив. Или вы думаете, что разработчики обожают читать ваши сочинения и идти шаг за шагом? ;) В этом то и решение корня проблемы. Не надо читать - нет ошибочного восприятия вашего текста. Выполнил - вот результат.

    А в джире можно просто к такому тесту делать описание в 1-2 предложения. Чтобы заказчики читали, хотя в принципе непонятно зачем им детально шаги читать. Да и дело в культуре. Если вы им покажете как плагином к Firefox можно практически любой тест у себя запустить без технических заморочек, то они вам только благодарны будут.

    Посчитайте сколько раз потребуется интерпретировать ваше сочинение и по нему делать последовательность действий. Как минимум 5 раз: вам 2 чтобы убедиться что повторяется, разработчику 2 чтобы найти баг и потом проверить, потом опять вам чтобы проверить. Теперь возьмите ничтожную вероятность в 2%, что ваш шаг может быть воспринят и выполнен неправильно. Умножьте на количество шагов в сценарии и на 5 (количество запусков). Можете уверенно придти в большому проценту. Вот отсюда и ошибка. Простая теория вероятности. А так сделали 1 раз и потом сколько угодно раз запускаете автоматом.

    А разработчики будут просто счастливы ничего не читать и не делать руками. Попробуйте! ;)

    ОтветитьУдалить
  12. Да, я согласна в том, что в данной ситуации скрипт бы подошел именно из-за того, что меня как раз и раздражало все действия воспроизводить. Потому что оставить все "как было" для быстрого воспроизведения баги я тоже не могу, роль для тестирования постоянно меняется.

    Действия ленивого тестировщика))) Но всеже это весьма скоротечный результат.
    Уж умалчивая о том, как работает рекордер, вон я для курсов пыталась записать этим IDE, так вот, при записи выбора из выпадающего списка получался код "Error!", то есть запуск такого скрипта профита не даст - там нет всех шагов.

    Но тем не менее, система динамическая, и этот скрипт потом просто перестанет работать)

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

    Но как средство достучаться до разработчика или не раздражаться необходимости снова сделать эти же шаги - да, вариант :)

    ОтветитьУдалить
  13. Уровень умений и владения инструментом не должен быть причиной обвинения в сторону самого подхода. ;)

    ОтветитьУдалить
  14. to Mikalai Alimenkou

    текстовое описание, скриншоты, видео, + логи - в общем случае являются простыми, быстрыми и понятными инструкциями к воспроизведению дефекта.

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

    И менять в данном случае надо не подход к описанию дефекта, а подход к его чтению.

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

    На мой взгляд, куда эффективнее, быстрее и дешевле, провести воспитательную беседу с программистом.

    ОтветитьУдалить
  15. to Mikalai Alimenkou

    Кстати, с последним комментарием я согласна, вспоминая неодобрение команды, когда у нас только только вводился Agile. А ведь это и правда лучше :))

    Но в остальном согласна с Pollyanna
    На каждый дефект скрипт писать - и правда сложнее и дороже (вы, Mikalai Alimenkou, кстати, так и не ответили на вопрос, есть ли у вас такая практика :)) )
    Хотя он не прям уж разгильдяй, не совсем же я своих программистов то не люблю))) Но эта ситуация явно описывает невнимательность.

    ОтветитьУдалить
  16. Отвечаю на вопрос: тестировщиков в своих проектах я прошу делать именно так. На данный момент мы живем без тестировщиков, о чем я недавно рассказывал на одной из конференций по тестированию: http://www.slideshare.net/alimenkou/development-without-testers-myth-or-real-option.

    По поводу больной и здоровой головы - а как вы убережете себя от повторения этого бага в будущем? Будете больше тестов ручных запускать? Или нанимать тестировщиков еще пока бюджет не профукаете? "Воспитательная беседа" - вы же не в детском саду живете и работаете. Это самое простое решение. Зачем разбираться и пытаться что-то сделать лучше и качественнее? Легче надавать по шапке всем несогласным и делающим что-то не так, как вы придумали. :) Но против теории вероятности не попрешь. Ошибку в интерпретации ваших шагов все равно допустят, потому что мир не идеален. :)

    ОтветитьУдалить
  17. Сейчас, к сожалению, времени нет послушать слайдкаст, но мне понравился слайд "обсуждать все детали перед началом" :)) Ну... У нас не всегда так)
    А уж как любят ставить перед фактом :) Например, отмечала я свое ДР, пить не хотелось. Тут звонит начальник "а у нас вечером релиз". Ну все, ребят, я точно не пью, мне работать)))
    Или. Нет, нет задач, потом бац и дофигища. А почему? Потому что никто не предупреждает. Ну и парное программирование например, в удаленке как-то не очень возможно, по скайпу чтоли?

    Как убережем? Автоматизацией. Но! Автоматизация запускается, когда на нее есть время. Когда его нет, в приоритете ручное. Да, оно не охватит все области. Их потом покроют тесты. Но автоматизация - это априори дороже ручного. Если делать нормальные устойчивые тесты.
    Запись рекордера - это бред в динамичной системе.

    Записали раз, два, три. И вот у вас уже сотни тестов, что-то изменилось и вам все перезаписывать? Нет, надо сразу делать устойчивыми. А это уже дольше.

    И проекты без тестировщиков - это совсем другое. Если сами программисты тестируют, то на уровне своих тестов. Но программисту написать программу и тестировщику тоже разные вещи.

    "Легче надавать по шапке всем несогласным и делающим что-то не так, как вы придумали" - в чужой монастырь))) Правила устоялись давно, всегда всех устраивали. Хотя да, правила тоже должны быть динамичными, в нашем мире стоять на месте неправильно. Но все равно фраза как-то неправильно звучит. Я не стараюсь пропихнуть какие-то свои больные фантазии, ругаясь, если меня не понимают и не принимают.

    Но вообще как-то странно слышать "если программист не стал читать твою багу, иди и запиши скрипт". А желательно еще и сам поправь о_О Тут действительно переложение с больной головы. Разобраться, да, пояснить, что как сделал, да. Но идти писать скрипт...

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

    В общем, мы смотрим каждый со своей колокольни. Спасибо хоть исследователькое тестирование нам оставили))) *Мельком послушала первые секунды слайдов*

    Изначально задачка была - что делать в таком-то случае.
    Ответ "записать скрипт" - да! Чтобы не раздражаться, когда тебя просят повторить в очередной раз.
    Ответ "и оставить его в сборке автотестов" - нет, ибо он неустойчив. И в динамической системе он долго не проживет! Или вы несогласны с этим?)))

    ОтветитьУдалить
  18. Согласен, что он долго не проживет без правильной обработки. Но не согласен с той сложностью, которую вы в это вкладываете. Вы повсюду оперируете понятием нехватки времени и откладыванием на потом. Неужели еще не поняли, что потом никогда не наступит? И никто ничего не будет дописывать. :) А правила нужно менять, чтобы подстраиваться под проблемы и находить решения. :) Думаю, что наша дискуссия дальше не имеет смысла. Захотите - попробуете то, что я вам предложил. Тогда обсудим, что у вас не получилось. А то пока это как разговор глухого со слепым. Вы не пробовали так сделать, но не жалеете слов для критики. :)

    ОтветитьУдалить
  19. "Вы повсюду оперируете понятием нехватки времени и откладыванием на потом. Неужели еще не поняли, что потом никогда не наступит?"

    Вы не правы! Не стоит с уверенностью рассуждать о том, о чем не знаешь))))
    Речь идет о моей второй работе. На которую после основной остается в будний день 3-4 часа. И на ней всегда было ручное тестирование. Раньше :) Мне предложили автоматизацию где-то сентябре, вначале я занималась ею лениво, более активно уже потом, недели 3 назад.
    Итого я пару недель кодила, мне помогали программисты, мы написали простой скрипт, а потом рефакторили его, переписывая раз за разом.

    Да, я признаю, что прошедшая неделя была неделей простоя. Потому что "внезапно" на мне оказалось 20+ задач, навалилось ручного тестирования. + Работа не основная + я в понедельник, например, слегла, не работала. В пятницу после ГАИ я тоже очень плохо себя чувствовала и ушла спать.

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

    Откуда этот снисходительный тон "никто ничего не будет делать". Я буду! Но что вы хотите от тестировщика, который код пишет аж 2 недели? Да, это долго и сейчас идет медленнее, чем хотелось бы. В выходные, опять же, я узнала, что один из программистов уходит в отпуск. Что добавило мне ручной работы, я же понимаю, что когда он уедет, у меня будет куча времени на автоматизацию. А сейчас надо происследовать то, что он сделал.

    На этой неделе продолжу изучение языка С#, на следующей дело пойдет еще живее. Ну и конечно, с опытом это станет легче. И я набираюсь этого опыта. А не сижу на месте, только критикуя)))

    Возглас критики вырывается сразу при виде слов "рекордер... вставим в автотесты".
    На чем мы и сошлись))) Не вставим. Без доработки - не вставим.

    Но когда я буду писать скрипт на этот кейс, я не буду писать его рекордером. Я вообще рекордером пользовалась только в тест-комплите, тыкаясь слепым котенком. Сейчас мне проще написать код, чем рефакторить запись. Поэтому критика, критика и еще раз критика :)

    Просто нао отделить мух и котлет - когда мы применяем ручное тестирование для приоритетной задачки, а когда мы автоматизируем модуль. чтобы не упускать пропущенное ручным :)
    Но я думаю, даже вы согласитесь с тем, что, вобщем то, использовать рекордер для автоматизации - моветон ))

    ОтветитьУдалить
  20. Этот комментарий был удален автором.

    ОтветитьУдалить
  21. В таких ситуациях предпочитаю залезать в логи и к багу прикладывать кусок лога! В таких случаях обычно ошибка не только описана, но и отображено состояние системы, предшествующее падению, запросы и др. полезности, которые говорят программистам об ошибке на их языке)))
    Самое главное я считаю это четкое описание шагов, которое сможет понять дядя Вася с улицы - это уже достаточное условие. По поводу автоматизации - если нет времени - лучше не заморачиваться, если очень надо будет, это можно оставить программистам и это не столь важно при проверке исправления. Очень часто случается так, что после исправления бага совсем рядышком, и не всегда заметно, вылазит еще один или парочка - в таких ситуациях без ручного тестирования не обойтись. Хотя если нет тестировщиков тогда уже будет клиент описывать такие баги или один из пользователей;)

    ОтветитьУдалить