О записи багов, или Найди кота

    Эта статья родилась из поста на внутреннем форуме нашей конторы, немножко пообсуждалась, слегка дополнилась, а потом я решил выложить её в итоговом виде тут, чтобы ссылаться было удобнее.
    Да, пост капитанский, это ожидаемое поведение :) я просто хочу это иметь собранным, упорядоченным и общедоступным.


    Введение: найди кота


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


    Найди кота


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


    Часто к багу прикладывают видео. Ведь на видео всё видно!
    Там всё то же самое, только ещё травка колышется (двигается мышка) и ворота открываются (открывают не относящиеся к делу диалоги).
    В этот момент я рассказываю о правилах записи багов, которым я стараюсь следовать для себя, и которые рекомендую другим.


    Мои личные правила записи багов


    1) Ключевые слова в заголовке бага
    Чтобы можно было быстро понять, к чьей области компетенции относится баг.


    2) Шаги для воспроизведения
    И это очень очень важно. И да, их составление занимает самую большую часть времени при записи.
    Потому что достаточно часто, начиная, записывать шаги и выкидывая "лишние", ты понимаешь, что баг воспроизводится совсем не всегда.


    3) «ожидаемое поведение» vs «наблюдаемое поведение» в тех шагах, где, собственно, баг.
    Это критично. Потому что не всегда то, что человек ожидает увидеть, соответствует тому, как оно есть на самом деле. Тогда искать кота можно бесконечно.


    4) Скриншоты – это хорошо
    Картинки дают визуальный контекст, показывают разработчику части продукта с проблемами, и он сразу понимет необходимую область знаний. Картинка в этом плане работает в паре с ключевыми словами (см. п. 1)


    5) Видео – это хорошо, но только когда показываем баг на анимацию
    И – видео это то, с чем можно в принципе жить, когда автор бага не может написать шаги для воспроизведения.
    Или ошибка недетерминированная, и нужны доказательства.
    В остальных случаях видео избыточно.
    Видео для бага должно быть для бага. Длиной секунд 10, без открытия левых окон.


    6) Стэк трейс / ошибки в консоли при явном эксепшене
    Ну, это и так почти все понимают и прикладывают, пишу только для завершённости списка.


    7) Пример для воспроизведения.
    Если мы говорим о какой-то десктоп системе — то нужен архив, на котором воспроизводится проблема.
    В вебе проще — часто можно дать ссылку на онлайн-демку (или на развёрнутый staging environment).


    На этом в первом приближении всё.


    Я делюсь этим с другими людьми – и часто они мне верят и начинают делать так же.
    Дальше примеры и 20% деталей, которые занимают 80% статьи :)


    Примеры


    Пример бага – как я их записываю, и который более-менее :)




    dxTreeView creates redundant loading indicators in Virtual mode



    Основной скриншот




    Ещё тикеты (просто некоторая случайная подборка из списка публичных тикетов, записанных нашей командой)
    • Web Dashboard – The Reset and Submit buttons disappear in the Parameter custom item after submitting the parameter value
      To reproduce the issue, run the attached project, change the parameter value in the Parameter custom item and click the Submit button.
      Actual Result: The Reset and Submit buttons disappear.
      Expected Result: The Reset and Submit buttons should be shown.
    • Web Dashboard Viewer – Toolbar buttons are shown when any part of the control is clicked on a touch-enabled monitor and item captions are hidden
      Run the project and click any part of the viewer to reproduce the issue.
      Actual Result: Toolbar buttons are shown.
      Expected Result: Toolbar buttons should be shown only when hovering over them.
      As a workaround, execute the following (internal) code in the OnInit event handler:
      function onInit(s, e) {
      DevExpress.Dashboard.Internal.DashboardLayoutModeHelper.isTouch = false;
      }

    • ASPxDashboardViewer/MVCxDashboardViewer- An exception is raised if you open dashboards with tabs (тут нет expected, но он очевиден из тайтла бага. Такое бывает, ладно.)
      The old ASPxDashboardViewer control and the MVCxDashboardViewer extension do not support the Tab container dashboard item as compared to ASPxDashboard / MVCxDashboard. When ASPxDashboardViewer / MVCxDashboardViewer opens a dashboard with a tab container, a client-side exception occurs. It is necessary to show the corresponding pop-up message in a dashboard UI instead.
    • Dashboard Web – Binding panel remains transparent in certain cases (тут видео, потому что тут реально поганый баг, мы его полтора года пытались поймать)
      Steps to reproduce:
      1. Create dashboard with an item. Make sure that binding panel will overlap the item when opened.
      2. Select the item.
      3. Open the binding panel (e.g. click on the 'Options' button) and move a cursor over the panel to the moment when the cursor placed over the item. Binding panel become transparent (expected)
      4. Click on the dashboard item. Binding panel closed.
      5. Click 'Options' button again.
        Actual result:
        Binding panel is transparent.
        Expected result:
        Binding panel is not transparent.
        The main step is to close the binding panel by clicking to the item while is is transparent.
        Screencast is attached.

    • Web Dashboard – Fullscreen item — Pivot operates incorrectly in the maximized state
      1. Open the RevenueAnalysis demo.
      2. Expand the Pivot's "Bikes" column.
      3. Collapse the Pivot's "Bikes" column.
      4. Maximize the Pivot dashboard item.


      Expected result: The Pivot's "Bikes" column should be collapsed in the maximized state.

      Result: The Pivot's "Bikes" column is expanded in the maximized item.
    • Chart's tooltip can be clipped if a custom container is used
      Steps to reproduce:
      1. Use the chart's container as the tooltip container;
      2. Show a tooltip on some points close to the edge of the chart;
      3. WRONG. The tooltip is shown outside the container or can be clipped depending on the container's overflow setting.
        EXPECTED. The tooltip should be shown inside its container until it fits container size.


    И др.


    Философствования и мелкие определяющие детали


    Подготовка скриншотов


    Картинки должны быть с большими красными стрелками или даже с подписями.
    Скриншот должен быть частью тела бага, прямо в тексте.
    Если баг репортится в большинство современных систем — то это делается просто вставкой картинки из буфера обмена по Ctrl + V


    Почему нельзя просто дать ссылку на картинку? Потому что происходит потеря контекста. Если ты смотришь на картинку, ты не видишь текст. Если ты видишь текст, то ты не видишь картинку. Если ты видишь и то и то — вероятность, что в мозгу что-то щёлкнет, значительно выше.


    Минутка профессиональной деформации
    Именно поэтому становятся популярны дашбоарды как явление анализа данных :)
    Когда человек видит одни и те же данные в разных форматах и с разных углов, к нему может прийти озарение (insight).
    Подробности см. у Стивена Фью и других авторов.

    Размер скриншота – всегда компромисс.
    Когда маленький, проблему лучше видно, и места занимает мало. Но не всегда ясно, откуда вообще этот кусок взят.
    Захватили область экрана чуть побольше – влезают посторонние детали. Экран, с которого открыли попап, на котором ошибка. Браузер, в котором ошибка. Кнопка пуск той винды, на которой ошибка. DPI того монитора, на котором ошибка… ой, а самой ошибки-то уже и не видно. Кот стал двухпиксельным и неопределимым даже внутри красного кружка.
    Где остановиться, обрезая скриншот – это всегда искусство )


    Примеры скриншотов, от малого к большому:


    • багрепорт в УК, перила сломались
      Скриншот фотографии сломанных перил
      Проблема хорошо видна, но контекст потерян. Если б не было надписи словами, что это около парадного входа, сварщик ходил бы в маске по участку, искал бы.


    • в личном общении, вопрос про реализацию TreeView



    скрин визарда репортов
    Показано, какой элемент я имею в виду (плюсик… ну, идите переведите extend button лучше :)), виден контекст (экран нового визарда)


    • Проблема с маштабированием демок дашбоардов на DPI=125%
      скрин оперы на 125%
      Видно, что это за браузер и URL сайта
      Замазаны ненужны вкладки, чтобы не отвлекать. Оставлена статья про Windows 10 Creators Update (в котором 125% DPI и стал дефолтом на ноутбуках 15,6″), чтобы я, глядя на этот скриншот, вспомнил об этом и смог выпендриться и про это рассказать.

    Давайте ещё раз подчеркнём. При нормальных инструментах, время подготовки каждого из этих скриншотов составляет от 5 до 30 секунд.
    Это не плод долгой художественной работы. Это быстро и эффективно. Можно упороться и довести каджый из них до совершенства… но как правило это не требуется.


    Программы для снятия скриншотов


    • Яндекс.Диск я вот нежно люблю его скриншотилку. Ну вот так вот. Она почему-то оказалась лучшим из того, что я пробовал, чтобы делать стрелочки, обводить кружочком-квадратиком и добавлять читатабельные надписи. На ней сделаны все примеры из статьи.
    • Monosnap (бесплатная, с платным планом). В принципе очень ничего, но (субъективизм!) стрелочки страшненькие;
    • ShareX (совсем бесплатная);
    • Jing широко использовался нашими инженерами техподдержки; потихоньку уходит, потому что пишет видео в богомерзкий флэш.
    • В Windows 10 — встроенный по сочетанию Win+Shift+S # Комментарий автора: действительно вполне неплохо
    • встроенный скриншотер на Mac #,
    • GreenShot — Win #, #
    • LightShot — Mac/Win #
    • FastStone Capture #
    • FlameShot (Linux, на гитхабе обсуждают возможность Windows) #
    • Snipping Tool — встроен в Windows #
    • gooncam #
    • PicPick (Windows) #
    • Spectacle & KSnapshot (Linux) #
    • Problem Steps Recorder — встроен в Windows, запускается по PSR из командной строки #

    Записываем проблему, а не решение


    Этот пункт возник в результате внутренней дискуссии. Очень неожиданно он оказался не всем ясен, поэтому – пример.


    Вот например тестирую я дашбоард дизайнер и вижу такую штуку:
    Пример скриншота на баг дизайнера


    И пишу баг:
    "Отсутствует горизонтальный скролл"
    Могу даже написать его с шагами и ожидаемым результатом :smiley:
    Ожидаемый результат: название правила должно скроллироваться горизонтально
    реальный результат: название правила не скроллируется


    Баг оформлен нормально, но это не помешает разработчику посчитать меня дебилом. И он окажется прав :)


    Есть проблемы: "текст не виден целиком; текст накладывается на иконку"
    Но вместо записи этой проблемы я записал своё решение этой проблемы. Одно из многих, и точно не самое лучшее.
    И вот такая подмена происходит не сказать чтобы редко. Даже себя я иногда ловлю на этом.
    Ведь я-то знаю точно, как надо фиксить. А значит, так и напишу!
    (ну, иногда действительно знаю. И стараюсь писать свои предложения в теле бага, после собственно описания проблемы. Но не как единственное возможное решение)


    Про пример для воспроизведения


    В desktop-разработке этот пункт является дискуссионным. С одной стороны, полезность выполняющегося примера кода, воспроизводящего проблему, всем понятна.
    С другой, создание примера уже значительно увеличивает срок записи бага, до порядка.
    В общем, в моей голове так: для сложных случаев это обязательно, в простых случаях — может быть избыточным.
    Меня в универе учили, что если система безопасности становится слишком сложной и приносит вред и неудобства, то ей просто перестают пользоваться.
    Если на каждый баг обязать делать пример — то через месяц забьют даже на примеры для сложных багов )
    С другой стороны, на простых багах можно тренироваться делать примеры…
    Короче, вопрос дискуссионный.


    Сюда же в копилку добавлю десятилетней давности статью CTO нашей конторы, где он объясняет, почему мы наших кастомеров просим о примерах.


    A request for simple example programs 10 by Julian


    А ещё есть такой момент с упрощёнными примерами, цитата:


    Сильно упрощенный пример это конечно хорошо, но и плохо. Неоднократно были случаи, что упрощенный пример:
    – не покрывает всех сценариев проявления бага;
    – не отражает реального сценария, что может привести к неподходящему решению.
    В идеале лучше иметь и упрощенный и исходный сэмпл.

    Теперь вы знаете, что:


    • подготовливать примеры – очень полезно;
    • это сложно;
    • главное, не переборщить.

    Время записи бага


    Получилось очень много букв. Может показаться сложной, долгой и нудной бюрократической процедурой.
    Так вот, это не должно быть сложно и долго.
    Медиана времени записи бага, удовлетворяющего портянке требований выше – около минуты.
    Дааа, в тех случаях, когда оказывается, что шаги-то не воспроизводят баг; или что они не все важны, и захотелось убрать лишнее; или в процессе вскрылся новый шаг — тогда время увеличивается.
    Зато верояность, что ваш баг пофиксят, а не закроют с комментом "can not be reproduced", значительно растёт.


    Оппозиция


    Что мне говорят, когда я делюсь своим видением:


    баг же очевиден

    Он очевиден тому, кто уже нашёл кота.
    Без подробного описания и шагов всем остальным придётся его искать. Недетерминированное время.
    Да, моя жена и VYudachev нашли кота в первые три секунды. Двое из моей выборки.
    А остальные люди (примерно с десяток), в мониторы которых я подглядывал, искали кота до пяти минут.
    А я в общем-то плюнул и сразу открыл отгадку.
    И с плохо записанными багами то же самое.


    видео достаточно, там всё видно

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


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


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


    (Справедливости ради, бывало в моей практике, что на прикреплённом видео автор функционала находил другие баги)


    записывать так баги очень долго

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


    Список литературы


    Список требований к записи багов родился у меня на основе:


    • Bug report writing guidelines (Mozilla); (по этой ссылке на форуме было очень мало переходов, а зря, отличная статья :) );
    • How To Ask Questions The Smart Way 10. Эту статью коллега подкинул как коммент к первому варианту, прочёл с удовольствием:

    если выкинуть форумно-мэйллистовую-опенсорсную специфику, то ценно почти всё. Включая мои любимые “Describe the problem’s symptoms, not your guesses” и “Be explicit about your question”;


    Конец


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


    Спасибо дочитавшим.




    Вот тут отгадка картинки с котом (взято тут).
    Кстати, картинка не моя, но подготовлена неплохо – есть стрелка, и есть увеличение области с багом котом.




    UPD 28.06.2019
    Программы-скриншотилки из комментариев добавлены в общий список
    Исправлены опечатки, даже вызвавшие дискуссию в комментах

    Developer Soft
    150,51
    Компания
    Поделиться публикацией

    Комментарии 110

      +4
      А кот-то где?
        +5
        А вот кто дочитал статью до конца — тот нашёл ссылку!
          +2
          По ссылке «вот тут» находится картинка, где черным квадратом и красным кружком обведены области с белым цветком, который по форме напоминает нос кота. Кот по ссылке не найден.
            0
            Там ухо торчит.
              0
              А второе ухо скрыто травинками, которые находятся позади головы? И всё тело до последней шерстинке скрыто в невысокой траве. Также обращает на себя внимание отсутствие глаз, которые должны были бы выделяться на фото. На многочисленных картинках типа «найди кота» зачастую именно глаза выдают зверька. Поэтому вполне можно предположить парейдолию.
                +2
                Это парейдолия смотрит на вас, как:
          0
          — вы знаете, а хабр глючит, к первому комментарию не идёт ответ
          Пойду баг репортить )
            0
            Чуть ниже середины фото и правее.
              +2
              Есть еще один кот рыжего цвета.
                0
                И где он?
                  0
                  Лежит на крыльце возле стеклянной двери в верхнем левом углу фотографии
                    0
                    Хорошо, осталось найти на фото эту стеклянную дверь.
                    Я ещё рыжего котёнка нашёл ниже середины фото.
            0
            Где кот!?
              +2
              Программы для снятия скриншотов

              Из личных предпочтений я бы добавил GreenShot (бесплатный под вин) и LightShort если у вы работаете на маке или винде (хотя он полайтовее)
                +1
                FastStone Capture тоже на их уровне, судя по скриншотам. Все у всех всё своровали.
                  0
                  Их скриншотилку не пользовал, попробую, спасибо. А вот ImageViewer от FastStone с его пакетной обработкой! и удобным UI — must have.
                    +1
                    На вкус и цвет… для пакетной обработки и тех же целей пользую Irfanview.
                  +1
                  Встроенный Snipping Tool в винде часто просто достаточен.
                  Вырезать, обвести, нарисовать стрелку — все есть, бесплатно, уже установлено, доступно в самой анально огороженной политиками организации.
                    0
                    Сколько программ для снятия скриншотов не перечисляй, а ежели тестировщик привык делать фото, зачастую низкого качества но в высоком разрешении и считает нормальным выложить это фото размером в несколько мегабайт в JIRA, то тут остается только нервно хихикать, особенно если через час-другой запланирован релиз.
                      0
                      Ну, может стоит (после релиза) сесть вместе, поработать в паре, показать свои подходы и почему они лучшее, удобнее и быстрее для всех?..
                        0
                        С удовольствием всегда так и делаю. Но в данном конкретном случае, тестеры на стороне заказчика. Единственный доступный контакт — это продакт менеджер на их стороне (весьма профессионально слабенький)
                    0
                    Проблема описания багов относится не только к программированию, а и ко всем отраслям по ремонту.
                    Когда работал по ремонту техники (телефоны, планшеты, ноутбуки), то очень часто приносили с неисправностью «глючит» и приходилось часто искать котов. На приемке строго запретил принимать в ремонт с неисправностями типа: «глючит», «тупит», «плохо работает» и т.п., только с явным описанием проблемы, поиск котов резко сократился.

                    (на картинке кота нашел без подсказки =) )
                      0
                      Ну вот я пытаюсь так даже в управляющую компанию так заявки оставлять на ремонт оборудования нашего дома, иногда помогает )
                      +1
                      Всем тестировщикам в уши. А то после одного тестировщика бэклог полон багов, которые непонятно как непонятно где воспроизвести, а у другого спрашиваешь — ты видел этот краш?, а он отвечает — да, но не заносил как баг потому что еще не нашел четкие степы.

                      Сразу видно, что вы — хороший тестировщик.
                        0
                        Спасибо!
                        Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
                          0
                          Прямо игра в одни ворота. Не всякий программист читает описание бага внимательно, обходится одним заголовком. Я уже молчу про комментарии, когда находишь важную информацию по дефекту и заносишь её вне описания, чтобы была видна историчность. Или же когда дефект воспроизводится после починки и его гоняют туда-сюда по статусу, комментарии тоже не всегда читают.
                            0
                            это просто невнимательность, но у девелоперов все же с годами вырабатывается больше скиллов дочитать описание до конца, слишком часто он будет себя чувствовать глупо не дочитав детали.

                            P.s. есть хоть одна причина, почему некоторые тестеры называют баги дефектами?
                              0
                              ЗЫ: так в умных книжках написано. В т.ч. и советских времён.
                              0
                              Прям на днях пришел с отпуска, а мой баг закрыли описанием того, как этот механизм работает (= тому, что я описал и так), пропустив то, что и зачем нам надо.
                              Ещё плюс два письма и только тогда до них дошло…
                              Не, ну кому может прийти в голову, что если один элемент в нескольких разных списках отображается, то у него может быть разный номер сортировки. Действительно, зачем. Ясно же, что элемент всегда будет 5…
                              Так что не просто невнимательно читают, а зачастую читают то, что хотят прочесть. А, очередной человек не понял, как у нас сортировка работает!
                            +4
                            По поводу видео только для анимаций поспорю — нет, нет и еще раз нет. Очень часто и только на видео я замечаю множество аспектов, которые можно пропустить в степах. Например, на телефоне выбран 3g, а данный вид групповых чатов работает только на wi-fi. Я вижу iPhoneX, на котором данные заехали под монобровь, а у меня в распоряжении только iPhone 7. И еще множество нюансов, которые тестировщик от лени, от неведения, от ужасного владения английским может не указать, видно на видео.

                            В остальном я категорически согласен со всем, особенно с тем что нужно выкидывать лишние степы и перевоспроизводить баг несколько раз. Уж сколько было от разных тестировщиков «от бога» баг содержания «вот иногда крашится когда заходишь на эту вьюшку, не всегда воспроизводится», а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?
                              0
                              Ну, да, бывали случаи, когда видео оказывалось прям полезно-полезно-полезно. То есть если бы не оно, то и фикса могло бы не быть, потому что проблема оказалось бы не понятной в принципе.
                              Но это всё же от бедности )

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

                              Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
                                –5
                                а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?
                                Эм, ну да, правильно. Ведь лучше все юзеры страдают, потому что четко воспроизвести баг не всегда возможно, а девелопер, написавший данный код, ни в чем не виноват?
                                  –1
                                  То есть в этой теме люди серьезно считают, что репотить о багах, которые не имеют четкого воспроизведения не надо, потому что программист такой хороший работает, а его отвлекают по ерунде и заставляют, такие нехорошие люди, баги в старом коде править вместо написания новых?
                                  И пофиг, например, что благодаря этому пациенту будет выдан не верный результат анализа, из-за чего врач не верно может продиагностировать оного и назначит не верное лечение? Потому что баг, оказывается, завязан не на последовательность действий человека, а на криво написанный запрос к базе данных, который зависит от положения марса в раке. Потому что половине случаев именно так можно описать те ошибки, которые программист находил по нашим багам «иногда случается фигня», когда врачи прибегали к нам и показывали неверный результат в системе.
                                  И да, пару таких багов наш программист уже полгода отловить не может, исправив по пути десятки других мест.
                                    +2
                                    Это противопоставление неверно. Как мне недавно подсказали, оно называется теоремой Эскобара. Ссылку давать не буду, потому что она сформулирована в обсценённой лексике, но она хорошо гуглится )

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

                                    В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
                                    И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.
                                      –1
                                      Уж сколько было от разных тестировщиков «от бога» баг содержания «вот иногда крашится когда заходишь на эту вьюшку, не всегда воспроизводится», а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?
                                      знаете, мне тут стока минусов в карму понапихали, что мне стало интересно — где я что подменил? вот, перечитываю исходное сообщение, на которое отвечал. и вижу ровно то, что описал — тестировщик должен поймать уникальную последовательность действий. а разраб, видите ли, мучается. то есть тестировщики то не мучаются искать такие последовательности? или они должны обладать даром предвидения?
                                      поэтому подмену совершил не я.
                                      когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
                                      в базе только результат. запросы в по забиты.
                                        +1
                                        то есть тестировщики то не мучаются искать такие последовательности?

                                        У тестировщика это, как бы, должностная обязанность.

                                          0
                                          А у программиста должностная обязанность писать корректный и рабочий код. Странно, почему тестировщики должны быть подобны богам и уметь находить любые последовательности, приводящие к ошибкам, а программисты писать без ошибок — не, не могут.

                                          Ещё раз, не все баги четко привязаны к жесткой последовательности. Или последовательность действий — это десяток различных не связанных действий подряд. Или к действиям добавляется внешние факторы. Или это вообще зависит от того, что с прибора в этот момент пришли свои числа в базу, пользователь на другом компе сделал то-то, а на этом — то-то. И всё пошло не так, как надо. И кучу таких моментов можно понять только зная, как и что внутри крутится. Так что именно должен найти тестировщик в этом случае? Что программист даже с логами найти не мог неделю?
                                          Вот у меня баг: тесты с одного отдела постоянно поступали с неверно оцененным вхождением в нормы. Во всех отделах нормально, а от них — как не норма шпарит числа в диапазоне нормы. В итоге это была связка с типом теста и какой-то обработкой тестов вообще для другого приложения печати результатов. И что я, как тестирующий и оформляющий баги мог там найти?
                                          «Вот в этом месте у нас какая-то ошибка, воспроизвести лично не получается».
                                            +1
                                            А у программиста должностная обязанность писать корректный и рабочий код

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

                                            Не нормально — это когда программист получил тикет и решил его не делать/делать не полностью. Также и тестировщик — если нашел ошибку, ее надо описать поймать и описать. У всех свои обязанности и все (надеюсь) их выполняют в меру своих возможностей.
                                              0
                                              Также и тестировщик — если нашел ошибку, ее надо описать поймать и описать. У всех свои обязанности и все (надеюсь) их выполняют в меру своих возможностей.
                                              Извините, но вот там выше меня сильно заминусовали за то, что не для фиксации всех багов тестировщику возможно найти условия его возникновения. Достаточно часто программисту проще определить в каких кусках ПО вообще идёт обращение к данном полю, например, базы и понять, какой из них имеет шансы попортить данные в этом поле.
                                              У меня, как у тестировщика, доступа к sql запросам в программе зашитым, например, нет.
                                              И при этом получается, что тестировщик ОБЯЗАН найти жесткую не всегда понятную последовательность, которой может и не быть (если зависимость от внешней системы) иначе баг не считается. Ведь у него это должностные обязанности. А программист — не, не обязан писать без ошибок, ведь видимо у него таких должностных обязанностей писать правильный код — нет. Замечательная логика, что сказать.
                                                0

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

                                                  0
                                                  Всё таки не соглашусь: переоценена работа так себе программиста и в отрасли таких много.
                                                  как в старой шутке
                                                  Плохой программист 1С увеличивает штат бухгалтерии в два раза каждые 1,5 года.

                                                  А работа программиста, который действительно умеет и решает задачи для бизнеса — переоценить трудно. Обычно эту работу только недооценивают.
                                                  Но вот что разработка ПО — это коллективная совместная работа, соглашусь безоговорочно. И тянуть должны все в направлении качественного решения задачи по возможностям.
                                              0
                                              Ещё раз, не все баги четко привязаны к жесткой последовательности. Или последовательность действий — это десяток различных не связанных действий подряд.
                                              Абсолютно любой баг — результат жесткой последовательности действий, если вам действия кажутся несвязанными — вы не разобрались в причинах бага.

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

                                              Код тестов связан с кодом продакшна? Где вы вообще работаете?
                                                0
                                                Абсолютно любой баг — результат жесткой последовательности действий, если вам действия кажутся несвязанными — вы не разобрались в причинах бага.

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


                                                есть хоть одна причина, почему некоторые тестеры называют баги дефектами?

                                                А как их надо называть? Баг — это отличие в наблюдаемом поведении программы от желаемого. Значит, это дефект. Если же поведение не определено, то есть мы не знаем, что мы хотим… То это проблема технического задания. Если же программа ведет себя так, как мы ожидаем, то это не баг, а фича )

                                                  0
                                                  Слова девопса, но не девелопера
                                                    0

                                                    спасибо, это, наверное, был комплимент. Спасибо еще раз )

                                                    0
                                                    Баг — это отличие в наблюдаемом поведении программы от желаемого. Значит, это дефект.
                                                    Это только малая часть багов такая. При этом даже в них далеко не всегда верно желаемое (даже если это четко прописано в задаче). Дефектом баг становится в момент когда ответственный за эту часть исправляет его и все соглашаются что да, вот так и должно все работать. На моей практике таких багов меньше половины, что-то решается оставить как фичу, где-то меняется задача, где-то придумывается вообще третий вариант отличающийся и от изначальной задачи и от реализации. Половина вообще идет как улучшение а не фикс. Зачастую даже за деньги клиента и с его согласия (никакого обмана естественно, просто нормальное описание клиенту почему так, почему это будет стоить дополнительных денег и какие проблемы это улучшение будет решать). Но когда тестеры и девелоперы начинают называть баги дефектами, то они обычно начинают использовать это слово как синоним, а не как название совершенно конкретной небольшой категории возможных проблем.
                                                    0
                                                    Абсолютно любой баг — результат жесткой последовательности действий, если вам действия кажутся несвязанными — вы не разобрались в причинах бага.
                                                    Нет. Если завязано на другую программу или там по сети, то баг может быть в ней, а проявлятся от других условий, не зависящих от пользователя. Просто пример: одна база, с десяток разных армов, есть частичная пересекаемость по функционалу, причем часть из которого было добавлено по просьбам других организаций или исходя из какого-то своего виденья и мы даже не знаем, что в том арме может быть функционал, влияющий на базу (банально, ошибка из арма печати результатов портила оценку числа в базе. Арм печати — взять данные из базы, сформировать xml и отправить на печать. А туда же). Отследить откуда ошибка появилась — сложно, логи покрывают далеко не все действия пользователей.
                                                    Дальше — ошибки только на одном типе ОС. И т.п.
                                                    У багов в причинах есть не только ошибки самого приложения, но и окружения. Реальный мир, к сожалению, не идеальная среда.
                                                    Код тестов связан с кодом продакшна? Где вы вообще работаете?
                                                    В медицине. Ошибка в определенном редком типе хранимого в базе медицинского теста.
                                                    QA всегда лучше знают приложение, т.к. девелопер варится в своей части, а QA по всему приложению.
                                                    Тогда отдайте уже мне исходники, я сам поковыряю и найду, угу.
                                      +3
                                      На Upwork, когда попадается какой-то подходящий по скиллам мелкий проект, но заказчик предлагает посмотреть видео с описанием задачи, прохожу мимо. Лучше текстом объяснить что не так.

                                      P.S. Голосовым или видеочатом вообще ненавижу пользоваться, такое тоже пропускаю. Пусть лучше заказчик текстом напишет задание, тогда уже не забудешь мелких деталей.
                                        0
                                        Я их тоже голосовые сообщения терпеть не могу… но, кажется, нам придётся с ними жить
                                        Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
                                        Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGU
                                          0
                                          Не-не-не, нередко даже носители англ. языка текст неграмотно пишут, а уж речь разобрать, со всем этим сленгом и разнообразием акцентов… Последний раз когда общался голосом — их двое было, к тому же еще и перебивали друг друга, я только через слово мог разбирать, что они говорят.
                                        0
                                        Текст длинный и запутанный. Выглядит как перевод. Все хорошо до примеров. Потом — плохо.

                                        Но все равно за статью спасибо, кину коллегам.
                                          0
                                          В вашем комментарии не хватает раздела «ожидаемое поведение».
                                            0
                                            Как скажете.

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

                                            +2
                                            Все хорошо до примеров. Потом — плохо.… кину коллегам.

                                            Похоже на хокку.

                                              0
                                              Случайно получилось ;)
                                            +1
                                            Стэк трейс / ошибки в консоли при явном экспешене
                                            Ну, это и так почти все понимают и прикладывают, пишу только для завершённости списка.

                                            Нет, это понимают не все. И, если упорядочить по важности, это должно идти первым пунктом, а не предпоследним! Очень часто для починки бага достаточно одного только стектрейса. Вот в тех случаях когда его уже не достаточно — тогда уже нужны шаги для воспроизведения, ожидаемое и наблюдаемое поведение, и прочие скришоты.

                                              +2
                                              >Очень часто для починки бага достаточно одного только стектрейса.
                                              Ну, это только в первые пять лет жизни продукта!.. :-D

                                              Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.

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

                                              Если бы все программы были stateless — было бы проще, но увы :(
                                              0
                                              а «цветорые» это нормально? (баг с наложением стрелки на текст)
                                                0
                                                :) да, это пофикшено в версиях 19.1.4 и 18.2.9, как я только что убедился, проверив свой тикет.

                                                Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).

                                                По хорошему, одна проблема — один багрепорт.
                                                  0
                                                  И один мастер тикет на всех со ссылками на связаные проблемы.
                                                    0
                                                    А вот тут тоже вопрос дискуссионный
                                                    Мастер-тикеты уже начинают искажать статистику по количеству багов )
                                                    Да и вообще… так ли они нужны?

                                                    Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
                                                    В каждом из них в комментах проставляем ссылки.

                                                    Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.
                                                      0
                                                      А так ли нужна статистика по количеству багов? Я вроде уже не один год работаю тестировщиком, в том числе строю процессы, а не только тестирую таски, но я так и не смог придумать ни одной адекватной причины зачем нузна статистика по количеству багов. Ну кроме того что это успокаивает менеджера и он начинает считать что вы работаете а не дурака валяете.
                                                      А касательно мастер тикета — я как раз люблю записывать список багов в один тикет с которым потом ПМ с лидом разбираются — что фиксить, как и когда. Довольны все — мне приходится тратить меньше усилий на бюрократию вроде создания отдельных тасков, менеджеру и лиду проще понять объем работы и распланировать следующую итерацию.
                                                        0
                                                        Статистика — ну, чтобы понять — вот тут мы работали полгода, и после этого накопилось просроченных багов
                                                        А вот тут мы полгода работали по-другому, и тогда завала багов не было
                                                        То есть это больше для последующего анализа, а не для тактических решений…
                                                          0
                                                          Возможно мне не везло с проектами (или везло), но количество багов за первый квартал могло кардинально отличаться от количества багов за второй квартал независимо от того работали мы также или иначе. Просто потому что разные фичи пилятся в разный момент и имеют разные шансы быть забагованными. И это даже не начиная разговор о неопределенности понятия «баг».
                                                          Нет, я не говорю что вы что-то делаете неправильно, если для вас это работает — замечательно. Просто у меня ситуаций когда такой анализ мог бы сработать пока не возникало и мне было интересно как у вас получается эту метрику использовать.
                                                        0
                                                        Не столько дискуссионно, сколько кейсозависимо. Если связных проблем три штуки, то и смысла нет городить огород. А, если поломался условный BGP, и повылазили проблемы в десятках независимых систем, то смело линкуем их к одному единственному тикету.
                                                          0
                                                          Да, это уже другой кейс. Эти десять тикетов ведь не связаны — это суть один и тот же тикет.
                                                          В нашем багтрекере это зовётся «дупликатами». И — да, мы сразу все, кроме одного основного, закрываем, при этом автоматически подписывая авторов дубликатов на уведомления по основному тикету
                                                  +2

                                                  Странно, что не упомянули


                                                  1. встроенный скриншоттер в Маке. Он прекрасен (за одной небольшой деталью) и даже позволяет рисовать поверх скриншотов. P — PRODUCTIVITY
                                                  2. под виндой — PicPick
                                                  3. В линуксе — есть две альтернативы Spectacle & KSnapshot. Они ТОЛЬКО для снятия скринов и по умолчанию забиндены на PrntScrn.

                                                  Естественно, что продвинутые тулзы вроде Слака тоже помогают…

                                                    +3
                                                    под виндой — PicPick

                                                    В Windows 10 — встроенный по сочетанию Win+Shift+S
                                                      0
                                                      Забавная штука.
                                                      Полноценную скриншотилку не заменит (нет стрелочек из коробки, нарисованное не является векторным — его править тяжело, нет текста)
                                                      Но на голой чужой машине — может быть очень даже ничего, спасибо
                                                        0
                                                        Под виндой есть ножницы.
                                                        Но я предпочитаю gooncam для создания гифок, дабы последовательность была наглядно видна (с учетом, как программисты иногда не читают последовательность действий, делая как им показалось верно в данном случае, в итоге не получая ошибку)
                                                        +2
                                                        Под Linux мое сердце покорил flameshot.js.org
                                                        Минималистичный интерфейс, набор всех необходимых инструментов, возможность гибко выбирать куда сохранять получившийся скриншот (автоматически зааплоадить и получить ссылку, скопировать в буфер обмена, сохранить на диск).
                                                          0
                                                          Я правильно понял по видео, что у них, грубо говоря, инлайн-редактирование скриншота прямо как будто бы до его снятия?
                                                          Выглядит и вправду забавно, доберусь дома до убунту — попробую.
                                                            0
                                                            Все верно, работает именно так. Выделяется область (либо фулл скрин), после чего можно выбрать необходимые действия из набора доступных функций. Можно добавить текст, заблурить, что-нибудь нарисовать и после этого сохранить/скопировать в буфер/зааплоаадить изображение.

                                                            Под Ubuntu использую уже больше года, безумно доволен.
                                                            0

                                                            О, flameshot реально находка. Спасибо.

                                                          +2
                                                          Странно, но почему-то никто не упомянул Joel Spolsky и его трактат «Painless Bug Tracking»: www.joelonsoftware.com/2000/11/08/painless-bug-tracking
                                                            0

                                                            Отличная статья. Спасибо. Странно, что я ее пропустил

                                                            +3
                                                            В OS Windows есть встроенный инструмент «problem steps recorder». Запускается из коммандной строки алиасом PSR. Автоматом делает скрины с пометками, где какие действия совершались, позволяет вставлять текстовые комментарии. Результат сохраняет в виде архива с .mht файлом. В Win 7 уже точно есть.
                                                              0

                                                              mht — не очень удобный формат. Но в любом случае спасибо за вариант.

                                                                0
                                                                Блин, век живи — век учись. Отличная программа.
                                                                +1

                                                                Парочка приветов из геймдева :)
                                                                В крупных компаниях обычно очень серьезно к этому подходят, потому что время программистов, которые ищут котов вместо починки багов, дорогое. Когда прилетает тикет — к нему обычно есть и скриншоты, и видео, и трейсы, и текстовое описание, и точная версия билда… и все равно иногда не помогает ¯\_(ツ)_/¯ потому что баги бывают хитросделанные.
                                                                А один мой хороший знакомый делал убер-фичу: в редакторе уровней один из объектов — это джира-тикет. Кликаешь на него — попадаешь в джиру, ну и в обратную сторону можно. Очень удобная штука.

                                                                  +2
                                                                  Этого кота без увеличительного стекла найти невозможно
                                                                    +3
                                                                    Пока ехал в метро, читал статью со смартфона, и кота разглядеть не удалось. А когда глянул на ту же картинку на большом мониторе — нашел его сразу же.

                                                                    По делу: В общем-то все правильно написано. Меня, как разработчика ПО, сильно раздражают багрепорты типа «программа г-но, ни хрена не работает».

                                                                    Вообще-то тестировщику за то и зарплату платят, чтобы он баги не только находил, но и мог по человечески объяснить, как их воспроизвести. Обычно для этого достаточно написать несколько строк (типа: «если случайно ввести в поле ВЛАЖНОСТЬ значение больше 100%, то никаких предупреждений при вводе не выдается, а потом в процессе работы произойдет ошибка Float Point Error»).

                                                                    Ну а дальше все зависит от того, что это за ошибка.

                                                                    Иногда нужно приложить какой-нибудь файл, с комментарием. (Например, «этот файл конфигурации открывается и отображается правильно, но при попытке изменить любой параметр происходит ошибка Out Of Memory»).

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

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

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

                                                                    Но самое интересное начинается, когда в роди тестировщика выступает обычный пользователь, не имеющий специальной подготовки… Вот в этом случае возможны знатные казусы. Есть личный опыт, когда моя программа вполне нормально работала у всех, а «грохалась» только у одного единственного пользователя. Причем это проявлялось на разных компьютерах, но только у одного человека! Дело осложнялось тем, что он находился в другом городе, и просто так пронаблюдать за его действиями не удавалось. По его словам — «Я просто щелкаю мышой в этом окне и программа падает!» А все мои и не только мои попытки воспроизвести эту ошибку ни к чему такому не приводили. (как мы только не извращались с мышками разных моделей и разным числом кнопок). В конце концов оказалось, что этому человеку легко удавалось делать не просто щелчок мышкой, и даже не двойной, а пяти — восьми — десятикратный! А та программа управляла технологической установкой, и в ответ на щелчки мыши отправлялась серия команд различным исполнительным механизмам (в данном случае — всяким клапанам, задвижкам, вентилям, и пр. Команды отправлялись в определенной последовательности и с нужными задержками) Поступления такого количества событий технологическая установка не успевала «переварить», и все начинало работать совсем не так, как задумывалось.
                                                                    Конечно, это был мой баг, который и был немедленно исправлен, как только проблема была осознана. А дело было в середине 90-х, когда и компьютеры были не такие шустрые, и до полезных инструментов (типа Problem Steps Recorder) еще не додумались. Поэтому осознал я эту проблему не сразу.
                                                                      +2
                                                                      Мы при виде видео в тикете обычно восклицаем: «ну вот, начинается: «следите за руками»!»
                                                                        0
                                                                        getgreenshot.org же!
                                                                        Вопрос скриншотов оным закрыт давно и надолго :)
                                                                          0
                                                                          6) Стэк трейс / ошибки в консоли при явном экспешене
                                                                          У меня предохранитель перегорел на последнем слове :)

                                                                          И вот одно из моих правил: разработчикам без тебя неясности хватает, изьясняйся недвусмысленно, и точно.
                                                                          В приведенной цитате: то ли это «экспектейшн» хотели написать, то ли «эксепшн», ведь ожидания тоже бывают явные и неявные. И уже лишние ватты разработчика тратятся не на решение проблемы, а на осмысление твоего небрежного наброска.

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

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

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

                                                                          В заголовке я пишу, что не так и при каком условии. Если насобачиться можно всегда уложиться в одно предложение. Например: «Профиль пользователя отображается неверно при возврате из меню настроек пользователя.» Описание не должно давать полной картины, но оно должно, при беглом прочтении, давать общее представление так чтобы можно было отличить этот тикет от другого, или упомянуть его в разговоре. Обратная проверка заголовка — если из него можно напрямую сформулировать запись в релизный журнал именений. Например: «Исправлена ошибка когда профиль пользователя в некоторых случаях отображался неверно».

                                                                          Описанию ошибок меня научил один коллега, сам того не желая. Он был разработчиком трейс-монитора для нашей проги. И вот у меня этот трейс-монитор однажды перестал реагировать на ввод мыши. Я завел тикет, и написал, что у программы «фриз». Он пришел и сказал мне на повышенных тонах, что это не фриз. Оболочка не реагирует, но программа продолжает работать. А ушел сказав: «Просто пиши то что ты видишь, а не то что ты думаешь

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

                                                                          Ну и конечно при собеседовании тестировщика, я бы в первую очередь, проверял владение челвоеческим языком. Если человеку трудно изьясняться, (ну бывает такое, что слабое место) то ему нельзя быть тестировщиком.
                                                                            0
                                                                            Я хотел написать «эксепшене»
                                                                            В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.

                                                                            Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.

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

                                                                            Но в такой области языка, как разработка ПО…
                                                                            > Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
                                                                            Серьёзно? Стало понятнее? )

                                                                            — Дальше довольно много претензий про то, что тестировщик должен и не должен.
                                                                            Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
                                                                            Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.

                                                                            — >Просто пиши то что ты видишь, а не то что ты думаешь
                                                                            Это хорошее дополнение, спасибо за него.
                                                                              0
                                                                              Вспомнил, полностью фраза звучала так: «пиши что ты делаешь и что видишь, а не то что ты думаешь ты видишь».

                                                                              довольно много претензий про то
                                                                              Боже упаси, какие претензии, счастье, что вообще такие статьи есть. Я просто по роду профессиональной деятельности занимаюсь тестированием, вот и решил поделиться мыслями в тему. Вдруг кому-то пригодится. Бывает так, у тебя есть какие-то убеждения, но их никто не разделяет. А так раз, прочтешь комментарий на хабре и на душе легче — значит все-таки ты не сумасшедший :)

                                                                            0
                                                                            Если дело касается бизнеса, то можно писать программы так, чтобы они самодиагностировались на наличие противоречий
                                                                            habr.com/ru/post/342302
                                                                              0
                                                                              Программы для снятия скриншотов

                                                                              На macOS удобнее всего использовать встроенный инструмент создания скриншотов:


                                                                              1. Нажать ⌘⇧4
                                                                              2. Выделить нужную область экрана
                                                                              3. В нижнем правом углу экрана появится сделанный скриншот, нажать на него
                                                                              4. Нарисовать от руки нужные пометки
                                                                              5. Либо сохранить скриншот как файл:


                                                                                • Нажать Done

                                                                                Либо скопировать в буфер обмена (многие сайты позволяют вставлять изображение из буфера обмена):


                                                                                • Сбросить выделение пометки
                                                                                • Нажать ⌘C
                                                                                • Нажать иконку мусорки


                                                                              Видео можно записать, нажав комбинацию клавиш ⌘⇧5.

                                                                                0
                                                                                Описанный автором подход верен, но крайне трудозатратен. С практической точки зрения баги делятся на 2 типа:

                                                                                1. «Найди на картинке слона», когда слон красный на зелёном фоне, по центру и занимает 3/4 экрана (баг существует, воспроизводится всегда) — таким багам не нужно всё то детальное описание, которое просит автор, если его писать и читать — мы просто потратим время зря.

                                                                                2. «Найди на картинке кота» — вот как в статье. Можно потребовать детально, статьей на 5 абзацов описать местоположение кота, его породу и родословную до 5-го колена. Или можно одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию.

                                                                                В общем, коммуникации в команде рулят.
                                                                                  0
                                                                                  >о одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию

                                                                                  Да, но что с ней делать потом?
                                                                                  Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
                                                                                  Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
                                                                                  И очередь фикса подойдёт только через две недели?
                                                                                  Даже во время внутренней дискуссии мне писали про это сразу несколько человек :)

                                                                                  Практика “Заведи на меня (заведу на себя) карточку в трелло с описанием проблемы без детального описания (ведь мы же оба будем ‘помнить’ о чем она, когда до нее руки дойдут)” так же очень порочна и должна пресекаться при первых же мыслях о ней.

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


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

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


                                                                                  Я бы от себя ещё добавил, что проблемы желательно описывать так, чтобы ты сам через месяц мог понять, что там в баге написано, когда детали забудешь


                                                                                  А ещё бывает, что его за эти две недели пофиксил кто-то другой, как сайд эффект от починки другой проблемы / рефакторинга / нечаянно.

                                                                                  Могу дополнить. Очень часто приходится не только “искать кота на картинке” но и проверять что “кота на картинке больше нет”. И в этом случае steps to reproduce и expected results вдвойне полезны.


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

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

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


                                                                                  Просто не всегда получается.
                                                                                    0
                                                                                    Быстрая коммуникация нужна именно для решения фиксить баг сразу или описывать. Если разработчик сразу понял о чём речь и может пофиксить это здесь и сейчас — отлично, мы сэкономили кучу времени тестировщика и разработчика. Если баг непонятен или не приоритетен — может быть принято решение о его детальном описании.
                                                                                      +1
                                                                                      Разработчик в момент нахождения бага может быть занят (и он почти наверняка будет занят). А когда он доберется до собственно бага занят чем-то другим будет уже тестировщик, у него вряд ли есть время сидеть и ждать пока до его очередного бага доберутся ответственные за фичу люди. И когда тебе в середине очередного поиска прилетает приглашение в видео чат, то цензурные слова для такого человека находятся далеко не сразу. Тестировщик это не бездельник который всегда готов потрындеть об очередном баге и у него тоже вполне себе бывает состояние потока. Видеочаты без предварительной договоренности — зло.
                                                                                        0
                                                                                        Я в курсе о проблеме входа в поток и переключения контекстов внимания. Но тут же чистая математика: если мне для входа в поток надо 15 минут, а для полного описания и изучения багрепорта мне и тестировщику нужно по 20 минут, то лучше вырваться из потока, 25 минут экономии. Плюс в половине случаев баг будет исправлен «здесь и сейчас», а не отложен на неделю.
                                                                                          0
                                                                                          Хорошо если у вас эта математика работает, без сарказма. Если меня в определенные моменты выбить из такого потока, то я могу потом полдня назад на работу настраиваться. И я совсем не уверен чей случай правильнее считать за правило. Обычно считается что программистов отвлекать не стоит — я придерживаюсь аналогичного правила для тестировщиков. Тем более что если я сам к программисту не пришел сразу после нахождения бага (лично или в чате, неважно), то скорее всего это не продакшн упал, а какая-то проблема которую совершенно необязательно решать вот прямо сейчас, большинство таких проблем великолепно подождут до следующей недели, где их решение будет запланировано и не пойдет в ущерб ничему из текущих планов. Вообще, по моему опыту, половина случаев сдвигания сроков готовности чего бы то ни было происходит в основном из-за попыток решения проблем в неподходящее для этого время.
                                                                                      0
                                                                                      Да, но что с ней делать потом?
                                                                                      Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
                                                                                      Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
                                                                                      И очередь фикса подойдёт только через две недели?


                                                                                      Ну что-что… помочь тестировщику (если это был он) составить багрепорт или составить его самому. В тех терминах, которые понятны тем, кто будет багу править.

                                                                                      Не в виде: «Я что-то нажал и все сломалось», а «При открытом модальном окне приветствия я нажал F1 и в форме исчезли ОК и крестик закрытия».

                                                                                      А дальше очевидно.
                                                                                        0
                                                                                        Плюс находясь в контексте бага на машине, где он воспроизвелся, бывает достаточно кликнуть пару кнопок, посмотреть пару файлов и становится понятно, что сломалось. Тестировщик не знает, куда смотреть, а разработчику потом, возможно, нужно будет долго воспроизводить окружение и шаги по воспроизведению.
                                                                                    +1
                                                                                    Для тех, кому только кота.
                                                                                    image
                                                                                      0
                                                                                      Для начала нужно понять: кот ли это на самом деле, или цветочки-трава так выстроились и мозг думает, что это кот. Нужна более детальная фотография этого места.
                                                                                        0
                                                                                        Необязательно. Нам же кот не нужен чтобы его кастрировать или покормить. Поэтому цветочки похожие на кота — тоже ответ на вопрос где же тут кот.
                                                                                        +1
                                                                                        это не кот, это фича…
                                                                                          0
                                                                                          там на картинке может быть и маска вместо кота
                                                                                          image
                                                                                          0
                                                                                          Кстати, про запись бага. Всегда есть выбор того, что важнее в данный момент при соответствующих условиях — клише или оптимальное для задействованных сторон содержание, стереотипное мышление или понимание «пульса, дыхания, с полуслова» работы системы и команды.
                                                                                          Говорят, что кот обязательно сам найдёт любящего и понимающего его хозяина — надеюсь, Вы видите, что я здесь не пытаюсь выдавать известные знания за свои новые мысли и идеи.
                                                                                            0
                                                                                            Итак:

                                                                                            1) Ключевые слова в заголовке бага
                                                                                            2) Шаги для воспроизведения
                                                                                            3) «ожидаемое поведение» vs «наблюдаемое поведение»
                                                                                            4) Скриншот
                                                                                            5) Видео
                                                                                            6) Стэк трейс / ошибки в консоли при явном эксепшене
                                                                                            7) Пример для воспроизведения.
                                                                                            На этом в первом приближении всё.

                                                                                            Вы забыли с самого начала добавить пункт «объяснить контекст».

                                                                                            То, что вам кажется очевидным, программисту/менеджеру/Сотоне может быть вообще неочевидно, даже несмотря на детальные полотна Рембрандта в разделе «2) Шаги для воспроизведения».

                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                            Самое читаемое