Почему разработчики иногда отказываются исправлять баги

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

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

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

Иллюстрация Марии Рыбак

Коллекция отказов

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

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

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

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

«Объясни как, тогда сделаю». Ходят легенды, что есть проекты с исчерпывающей документацией, но я про такие читал только в книгах и никогда не видел своими глазами. Однажды мы реализовывали проект внутреннего информационного портала для крупной международной корпорации. Этот портал содержал подробные инструкции о том, что делать в той или иной ситуации, и даже имел цветовую дифференциацию для того, чтобы сотрудники разных отделов быстро находили информацию по их профилю. Но какой же путанной и безалаберной была документация, описывающая, как это все должно работать.

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

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

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

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

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

Тут также поможет ссылка на реализацию или мнение эксперта о том, что она все же возможна.

«В спеке про это не сказано». Спек — это последний довод королей. Или как там обычно говорят? Документация на проекте — важный источник требований, но, как уже писалось выше, далеко не исчерпывающий. Документацию пишут люди, и они тоже могли забыть, пропустить, не подумать о каком-то пользовательском сценарии. В конце концов, проект развивается и может банально перерасти свой первоначальный спек. А еще многие вещи могут быть оставлены за скобками, как сами собой разумеющиеся.

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

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

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

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

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

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

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

«А что, я должен?» К счастью, редко встретишь такой ответ на просьбу что-то на проекте починить или переделать. Но бывает, что и такое случается. Сразу хочется воскликнуть «Если не мы то, кто?».

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

Итог

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

👍НравитсяПонравилось10
В избранноеВ избранном2
LinkedIn

Лучшие комментарии пропустить

На проекте весьма редко происходит непосредственное взаимодействие между тестером и разработчиком. Более того, если процесс нормально поставлен, то тестер не должен дергать разработчика вроде: «Я тут нашел баг, пойди пофикси его». Тестер создаёт тикет, а дальше уже тикет живёт своей жизнью: его могут обговорить на ближайшем стендапе, ПМ может включить его в беклог проекта, может не включать, счесть некритичным, стейкхолдер может сказать — делайте как в спеке, я не считаю, что этот тикет описывает реальную проблему... Но в любом случае при правильно поставленном процессе тестировщик (и даже тестлид) не будет требовать у разработчика фиксить этот баг и слушать описанные отговорки.

Это делал не я" или «Это было сделано до меня
А что, я должен?

вон из профессии. (ну или ждать пока повзрослеет)

Объясни как, тогда сделаю
В спеке про это не сказано
Сказали сделать только это
Я согласовал такую реализацию с менеджером

Ссорян, Михаил. Но спеку пишет не QA и не разраб. Отсутствие имплементации отсутствующих реквайрментов — это не вина разработчика. QA в таком случае должен триггерить PO, BA или кто там у вас пишет и приоритезирует требования. Решать такие проблемы по упрощеной схеме типа «Просто пофикси этот баг!» чревато последствиями — начиная с того, что новые требования так нигде и не будут задокументированы, и заканчивая тем, что в результате «фикса» получим еще большее гуано.

Так что разраб в этом случае молодец, что не ведется на такие подкаты.

Хм, статья как-то все переусложняет. Алгоритм ведь очень прост:
1) Заводишь тикет на то, что считаешь багом, ждешь реакции девелопера.
2) Если считаешь, что баг прям супер критикал — говоришь об этом на стендапе, или тегаешь причастных в рабочем чатике, или как у вас принято.
3) Если девелопер закрывает тикет как won’t fix, и ты с ним не согласен — подробно расписываешь в комментарии, почему не согласен, переоткрываешь тикет и асайнишь на продакт овнера. Опционально можешь предварительно договориться о созвоне с девелопером и попытаться его переубедить, если у вас коммуникация нормально налажена.
4) Если продакт овнер не соглашается с тобой и снова закрывает тикет — штош, можно либо смириться, либо воспользоваться поводом и уйти на +500 через дорогу.

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

Помню, дали нам один небольшой проект с довольно ограниченными эстимейтами, оценивали не мы. Приступили к работе. Первая итерация, вторая. Тут к работе приступила QA, и началось: то анимация загрузки страницы работает не так, как она считает нужным. То какой-то сторонний плагин поиска по таблице не выдает результатов, если ввести слово с двумя пробелами. То некорректно работают имена студентов, если напихать в них всевозможных знаков препинания. В итоге, на третьей итерации достала эта ситуация изрядно — вместо того, чтобы разрабатывать новые фичи, приходилось фиксить подобную ерунду, которую в реальной жизни юзер и не воспроизведет. Попросила в итоге на очередном стендапе расставлять приоритеты, а иначе дела не будет. Многие из подобных тикетов были закрыты после обсуждения с БА. Поэтому, я прекрасно понимаю тех разработчиков, которые не бросаются фиксить баги по первому зову. Очень часто и баг — не баг, и для проекта подобные тикеты во вред.

Все смешалось в доме Обломовых. ©

Почему тестировщик решает что нужно починить и какие приоритеты работы разработчика, а не продакт оунер владеющий картой и планом движения производства?

Почему разработчик решает на что ему тратить время, а на что нет? Где план движения, приоритеты, acceptance criteria для того чтобы считать работу законченной?

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Статья представляет собой сборник ситуаций, которые редко встречается в проекте с настроеными процессами. Но все вышеперечисленные ситуации корелируется со стадией динамики работы команды и maturity процессов, имея прямую зависимость.
Действительно разработчики, не всегда ломятся сразу чинить или делать работу вне скоупа тикетов. И это правильно.
С чётким распределением ролей всегда понятно кто принимает последнее решение. Задача всей команды состоит в том чтобы делать то что нужно и что матчится с целями, которые задают и описывают PO/PM и другие руководящие стейкхолдеры процесса, в том числе заказчики.
Качество выполненных задач на плечах всей команды, если же разработчики единогласно решает судьбу багов, то ни о какой командной работе не идёт речи. Ровно так же если бы только QA принимал такие решения.
С каждым кейсом нужно понять почему именно разработчик так отвечает и вывести абстрактные ответы в конкретные причины уже с которыми можно работать.
Важно помнить что люди ленивы, и проще ответить без аргументов, хотя за такой формой может находится весьма весомые доказательства. Нужно лишь копать.

мне было бы интересно пообщаться с программистами, которые используют процентов эдак 90% от приведенных формулировок :))))
Конечно всегда есть случаи, когда и qa инденер ошибается, и исправить действительно дорого и сознательно надо пойти на риск, но «а что, я должен» улыбнуло, да блин должен. Ну и конечно, надо по процессу все делать.

Вообще, программист в этой статье как тот Антошка из мультфильма: «Тили-тили, трали-вали, это мы не проходили, это нам не задавали, тарам пам пам».

Быстро — качественно — бесплатно? Дайте угадаю, ещё и с описанием баги «у миня ниработаит»

В отмазы надо бы добавить еще один, который к сожалению для ТС, покрывает не менее 20% всех найденных м-м-м непоняток: это не бага, это поведение by design. Но допустим автор вывел эти случаи за скобки :)

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

Не-а. Вы определитесь пожалуйста: вы за то что нежелание исправлять баги надо преодолевать, либо же за то что «можно махнуть рукой» :) Это из серии «парикмахер бреет всех кто не бреется сам»: если ошибка, то ее таки надо исправлять. По той простой причине, что это сегодня и Вам она показалась «незначительной», т.е. чисто субъективно. А скажем клиент в ночь накануне релиза может быть иного мнения. А вот если QA думает что неплохо бы цвет поменять, на 2 пикселя кнопку подвинуть, добавить/изменить описалово — сори, это не ошибки, это косметика. Дело тоже нужное :), но если клиенту без разницы те 2 пикселя, то таки можно и махнуть :)

По большинству пунктов какой-то дартаньянизм и максимализм.

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

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

По большинству пунктов какой-то дартаньянизм и максимализм.

Это культурно звучит когда типа есть два мнения? Тогда да, дартаньянизм :)
Судя по пути который прошел автор в «Итоге», речь идет о продуктовых конторах. Но сори, всегда есть если не клиент, то продакт менеджер, или кто там научил чего надо писать и тестировать. Т.е. не во всех случаях шпага д’Артаньяна решает чего править :8)

Еще раз посоветую то, что считаю очень важным в правильно построенном процессе разработки — это визибилити (подскажите красивый перевод если кто хочет). Время — деньги, поэтому все потраченное время должно быть учтено. Многим не нравится такой формализм — но на самом деле он очень помогает. Потому что оказывается что в работе очень много «скрытого времени», которое во-первых редко учитывают в эстимейтах, во-вторых «подразумевают» как часть работы, в-третьих терпят как неизбежное зло и не стремятся ничего исправить.
Вот только небольшой список такого «скрытого времени»:
1) Время на репрюдюс бага девелопером. Очень часто это время «подразумевается» — но при этом если шаги для репродюса QA описал не полно, если это проявляется не всегда, если QA забыл упомянуть какие-то нюансы своей конфигурации — то репродюс бага выливается в многочасовой перебор, потом общение с QA, выяснение всех нюансов, попыток дебага на единственной машине где это воспроизводится и т.д. Это работа QA предоставить либо исчерпывающие инструкции как 100% зарепродюсить баг — или предоставить среду в которой баг постоянно воспроизводится. Баг типа «иногда где-то что-то подтормаживает» — это просто потеря времени и саботаж работы со стороны QA.
2) Время на уточнение требований. Даже на медицинских проектах, где требования верифицируются и тестируются — все равно они могут быть неоднозначными. Маловероятно что в требовании написано сколько пикселей должен быть отступ или какого цвета должна быть кнопка. Из-за этого возникают ситуации, когда один QA заводит баг, например, выровнять все по центру (ему кажется что так правильнее). А когда баг пофиксят другой QA видит что что-то поменялось непойми почему и считает что нужно вернуть как было. Бывало и такое что после фикса очевидного бага клиенты начинали жаловаться — потому что они привыкли к старому, неправильному поведению!
3) Время на билд, код-ревью, тесты, деплоймент. Я работал на проекте где билд фронтенд — приложения занимал 30 минут. До сих пор не понимаю как можно джаваскрипт (который интерпритируется!) билдить дольше, чем бэкенд — но вот так. А потом еще проходили тесты, потом код ревью ... в итоге фикс бага в одну строку занимал по общему времени до 6 часов!
4) Чужой код. Когда девелоперу нужно починить проблему в коде, который он недавно писал — это одно, но когда проблема уходит корнями в чужой код или даже стороннюю библиотеку — это совсем другая история. И другой эстимейт! Свой код починить — может быть вопрос нескольких минут. Разобраться в чужом — уже несколько дней. Очень важно правильно оценивать если даже не эстимейт на починку бага (это не всегда можно понять до глубокого изучения) — то хотя бы сколько дней нужно что бы разобраться и дать эстимейт.
5) Риски регрессии. Очень часто начинающие девелоперы об этом не думают: у них есть баг что функция считает не правильно, есть ожидаемый результат — они идут и чинят. То, что эта функция используется еще в десятке других мест — они не подумали. Починили один баг в одном месте — получили 10 в других местах.
6) Бизнес велью. В конце-концов за фикс бага кому-то придется заплатить. И у него может возникнуть резонный вопрос: если на эту проблему может случайно наткнутся один пользователь из 1000 — и он может просто решить ее перезагрузкой страницы, то стоит ли тратить сотни долларов на починку? Именно поэтому многие сейчас отказываются от QA вообще и предпочитают вместо этого лечить только баги, найденные пользователями на проде. Потому что это именно те проблемы, которые реально мешают пользователям — а не придуманные изобретательным QA редкие комбинации. В конце-концов иметь человека на сапорте, который объяснит пользователю как обойти ошибку — дешевле, чем платить дорогим девелоперам и QA!
Когда у нас все время видно, когда понятно реальная стоимость фикса конкретного бага — то очень часто оказывается что много багов банально не стоят того, что бы их пофиксили! Это совсем не значит что QA должны закрывать глаза на проблемы — это значит что их работа максимально правильно эту проблему оценить что бы не раздувать «из мухи слона».

Visibility — наочність / наглядность.

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

Цей комент міг би бути покращеною версією даної статті )

Тот момент, когда комментарий лучше статьи

Бага, которой три месяца — фича
Бага, которой пол-года — компонент
Бага, которой год — функциональное преимущество над конкурентами
Бага после IPO — средство потери миллиардов долларов на которое всем плевать
Бага в глазах QA — ВРАГ

Не читайте статью — не тратьте время!

«Сказали сделать только это».

Сразу видно что афтар — джун-«барчук» :)
В таком случае нужно заводить новый [залинкованный] тикет либо просить [с разрешения] менеджера дописывать в description/comments.

Часто в командах чтобы не бегать на каждый чих к менеджеру или лиду («Вась тут верстка поехала нам это править или нет?», «Вась тут при делении на ноль вылетает undefined это править или нет?») решают про баги на уровне между qa и dev.
Я не говорю что это правильно, но так делают. Ведь разводить бюрократию если там при делении на ноль вылетает ошибка, вместо того чтобы починить за 10 минут, — весьма странно.
Но если там править не 10 минут а час то уже разумнее конечно проводить этот багфикс по всем процессам. Еще, часто мелкие баги собираются в один тикет и тоже проводятся по всему процессу (приоритезирование — правка — перетестирование — релиз)

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

Тогда у куа есть большой шанс пролететь и потерять свою власть над разработчиком

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

Есть такая проблема за ними и не только — когда они фичи обзывают багами, хотя это фичи. Это нереально раздражает.
У меня есть ответное оружие, я говорю — «Хорошо, сделаю это по паттерну проектирования „Костыль“ ». Их это выбешивает «Нет-нет мы не пишем костыли!».
Ок — не называйте фичи багами, я не буду код обзывать костылями))

Из строк данной статьи сквозит «QA всегда прав» и «разработчики ленивые жопы» 😁

Извечный конфликт девелоперов и QA. Мое мнение что корень проблемы — в неправильном отношении к багам! QA и менеджмент зачастую считают что любой баг — это недоработка девелопера. И что девелопер должен его быстро «доделать» и все будет хорошо.
С багами, которые действительно получились по-ошибке девелопера — все обычно так и происходит. Ну перепутал где-то знак — починить не проблема.
Но весьма часто проблема уходит корнями не в код девелопера, а в другую часть кода, которую он не писал, или в сторонний компонент, или даже в нестыковку в требованиях.
Поэтому девелопер вполне резонно старается отказаться фиксить баг: потому что он понимает что усилия по починке этого бага превосходят по объему всю работу, которую он сделал в рамках этой задачи!
Например ему нужно было сделать форму, он заэстимейтил 2 дня, уложился в эстимейт, но QA заводит баг что, например где-то тест в комбобоксе не влазит на несколько пикселей. А это контрол из библиотеки, как он внутри работает и почему иногда не влазит — ХЗ... Что бы починить такой баг нужно еще два дня ковырять и в итоге может оказаться что без использования другой библиотеки контролов или ее новой версии — никак. А это еще неделя работы на переход. При этом QA с менеджером стоят над головой и каждый час спрашивают «ну когда же ты починишь последний баг? Неужели так сложно подвинуть на несколько пикселей?».
Поэтому я никогда не говорю QA что не буду чинить. А требую что бы баг был полностью и точно оформлен!
Вот-первых не «что-то где-то иногда тарахтит», а четкие условия при которых проблема возникает, скриншоты, видео, логи.
Во-вторых как именно должно работать по мнению QA. Это очень важно — потому что требования редко бывают четкими и полными, а понимание у каждого человека разное.
В-третьих насколько эта проблема критична для пользователя. Как часто возникает, блокирует ли дальнейшие действия и т.д.
В-четвертых новая ли это проблема или была до этого, просто ее увидели только сейчас.
Дальше я, как девелопер изучу эту проблему, напишу все свои выводы, поставлю эстимейт, оценю риски появления новых проблем при починке этой, и после этого уже буду обсуждать с QA и менеджером.
Моя позиция такая: есть баги двух типов — недоработки девелопера, либо непредвиденные проблемы. Недоработки должны быть устранены в рамках текущей задачи. Проблемы — это отдельный объем работы. И тут QA не вправе требовать от девелопера «все починить» — иначе он не примет задачу.
Задокументированный баг — это отдельная задача, и ее нужно соответственно приоритезировать. Нет ничего хорошего в том, что девелоперы за неделю найдут как заткнуть баг костылем — и потом еще вылезет три новых. Лучше они эту неделю будут делать полезный функционал, а баг останется лежать в бэклоге. Далеко не все баги нужно фиксить любой ценой.

есть баги двух типов — недоработки девелопера, либо непредвиденные проблемы.

Первый — это дефект фичи. Фиксится девелопером в рамках текущей таски. Второй — это регрессия, приоритезируется ПМ в зависимости от критичности.

Пам’ятаю начальника відділу QA, який дуже любив знаходити помилки. Взагалі це добре. Але основний потік помилок від нього були виду "якщо запустити додаток з притиснутою Alt+Shift при масштабуванні екрану 150% і тричі натиснути ЛКМ в правому верхньому куті, панель налаштувань зміщується на два пікселя вниз.

Я так понимаю из-за таких потом появляются такие статьи:
dou.ua/...​g-without-qa-in-peopleai

Небось еще пометку ставил: «super urgent bug»

А на мобильных девайсах ещё и повернуть несколько раз хитрым способом

Це ще по-людськи, хоч опис якийсь є. Мій чіф колись мав звичку покласти обидві п’ятерні на клаву довільним чином .. причім всю долоню а не 10 пальців. Часом шось вилазило на морду, або приміром прога по якомусь Ctrl+C вилітала. Радості не було меж:
— во, бага!!
— а шо саме Ти натиснув?!
— а я гребу? ти ж все бачив...

Если ответственность на себя брать никто не хочет

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

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

спасибо, посмеялась

Тут также поможет ссылка на реализацию или мнение эксперта о том, что она все же возможна.

жаль программистов... даже ссылки искать не умеют...

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

это как бы не крайние меры, а единственный возможный вариант действий

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

Потому что это не баги, а фичи.

Тестировщики очень редко понимают суть, цели и предназначение разрабатываемого продукта. Как на курсах научили — так и педалят. Такое впечатление сложилось за то очень короткое время, когда в команде были Manual QA. Сейчас без них все гораздо проще, и на удивление, работает :)

То були [дуже] погані тестувальники.

Что бы это оценить мы должны протестить ваш продукт ;) а так — это тоже стандартные фразы разработчиков «я написал код. Тут все работает. Багов нет»)

«Это очень сложно / долго». Правильно этот аргумент должен звучать так: «Мне неохота этим заниматься».

Нет, аргумент звучит именно так как звучит.
И приоритет не твоя задача
Сложно/долго — обсуждается отдельно, желательно на нужной активности, где есть другие участники. У меня был прекрасный пример, когда я просто не думал о системных утилитах, и описал почему у меня что-то «сложно/долго». Вопрос решился за минуту + время на описание трудностей, мне указали про что я забыл.

«Это делал не я» или «Это было сделано до меня». Размытие ответственности

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

«Объясни как, тогда сделаю».

Это троллинг тебя, как самого умного в белом плаще на проекте. Хотя могу ошибаться.
Рецепт?
Описываешь как считаешь правильным и угадай что?
не твоя проблема
Есть специально обученные люди, митинг на тебя, разработчика и этих самых людей, где можно будет оценить все 3 стороны этой вечной «быстро-дешево-качественно» проблемы. И расставить приоритеты.

Я немного устал, но общую мысль, я думаю, можно проследить:
Есть классическая модель проекта в виде треугольника. Она включает в себя стоимость, качество и время.

И «manual QA» представляет только одну из сторон. Пусть даже в этом случае молодую и с горящими глазами.

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

Я для себя вижу основной посыл в умении общаться и решать вопросы внутри команды. Просто перекладывание ответственности приведет к конфликтам, постоянное обращение к клиенту к сомнениям в компетенции. Да и банального там времени на все ответы тоже нет.

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

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

Просто перекладывание ответственности приведет к конфликтам, постоянное обращение к клиенту к сомнениям в компетенции. Да и банального там времени на все ответы тоже нет.

перекладывание ответственностей — это результат того, что никто не знает кто за что торчит. не более.

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

Потому что проект говно. А вы им дорожите по какой-то причине.

Треш )))
Автору бы корону поменьше, а знаний — побольше, тогда б не позорил профессию.

Итак:
> Это сложно/дорого.
Тестировщик Михаила: ой, девелопер ленивая скотина не хочет работать
Нормальный тестирировщик: выясняет/прикидывает какой % юзеров аффектится этой багой, какие прямые и непрямые потери? И исходя из этого корректирует приоритет баги, настаивает на ее исправлении/отправляет в топку. Да, иногда это дорого. Сложно. И никому не надо. Не все баги должны быть исправлены.

> Это делал не я
Тестировщик Михаила: ой ужас, багу будет править не тот, кто накосячил
Нормальный тестировщик: у девклоперов есть свои задачи и приоритеты. Это нормально, когда разработчик, в коде которого бага занят/болеет/в отпуске/уволился. Если не срочный фикс (см выше, срочных фиксов реально мало), то можно подожать, а не дергать разработчика. Если реально горит — отдать в общий котел разработчиков/лиду разработчиков/менеджеру — они лучше знают загрузку дев тимы и разберутся, кого можно кинуть на пожар

> Обьясни как, тогла сделаю
Тестировщик Михаила: ой ужас, разработчики не могут выбрать реализацию, ща я им расскажу
Нормальный тестировщик: реализация и ее детали — это ответственность разработчика. Они лучше знают код, знают архитектуру и понимаю, как реализовать ту или иную фичу. Все, что я могу сделать — описать сценарии использования, чтобы они понимали, кто как и при каких условиях будет пользоваться фичей. И то, в том случае, если нет БА.

>Так никто не делает / Это невозможно / Я не знаю, как это делать
Тестировщик Михаила: отправлю-ка девелоперу ссылку на Stack Owerflow
Нормальный тестировщик: комбинация 1 + 3.

> В спеке это не сказано / сказали делать только это / согласовал с менеджером
Тестировщик Михаила: сейчас я вам всем расскажу, как нужно реализовывать! Вот ссылка на Stack Owerflow!!!!
Нормальный тестировщик: комбинация 1+3

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

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

Профит

Мне стало лень на третьем пункте объяснять :)

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

Сам же создаёт их каждый день, разрабатывая какое-то из их апи

Тут даже «возможно» часто, но «нельзя» — у них есть еще и ревью

Выглядит как список отмазок для ПМа. Ну кроме бага спеки и *объясни как*. Последнее к лиду девов. Если у ТСа такое кидают на кюэя, то ой.

Agile і «спека» (специфікація, а не чад) це взагалі-то взаємовиключаючі поняття ;-)

ага — The most efficient and effective method of conveying information to and within a development team is face-to-face conversation — www.agilealliance.org/...​hind-the-agile-manifesto

Що потім документується, по-різному, залежно від прийнятого на проєкті, але прикол спеки в тому, що вона спускається зверху і є істиною в останній істанції.

Ведь в широком смысле тестировщик отвечает за построение системы качества на проекте, а это...

...наглая ложь и добросовестное заблуждение.

Дискусію з приводу багів варто починати з розуміння самої суті цього поняття.

An imperfection or deficiency in a work product where it does not meet its requirements or specifications.

Як наслідок, у випадку відсутності вимог до продукту (або його частини), він (ця частина) не може містити дефектів.

Баг от этого не исчезает. Просто становится багом спеки.

TС работает в небольшой харьковской компании, занимающейся в соответствии с её профилем на ДОУ разработкой игр в вебе, блокчейнами и финансами. Эта статья полезна тем, что описывает организацию процессов в такой компании, где, похоже, в связи с тем, что релиз нужно сделать сегодня на вчера, процессы крайне упрощены, и тестировщик, обнаружив то, что считает багом, не заводит тикет, а идет непосредственно к разработчику, чтобы он пофиксил баг немедленно и чтобы после тестирования исправления отправить исправленную версию в прод. В таких компаниях своя специфика, которую можно понять лишь проработав в них.

А после «понять» предлагается «и простить»?

Нет, просто понять почему ТС пишет о том, как тестировщики просят разработчиков пофиксить то, что им кажется багом.

Тут, мне кажется, болезнь роста. Когда в одной комнате сидят три разраба и два куаки они же техсаппорт — прямая коммуникация ещё годится. С ростом количества задействованных людей без модификации процессов может дойти до того что тебя целый день дергают куаки и ничем другим заниматься тупо невозможно. Естественно, в ход пойдут все возможные отмазки что бы как-то заткнуть этот фонтан.

Когда в одной комнате сидят три разраба и два куаки они же техсаппорт — прямая коммуникация ещё годится.

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

Помню, дали нам один небольшой проект с довольно ограниченными эстимейтами, оценивали не мы. Приступили к работе. Первая итерация, вторая. Тут к работе приступила QA, и началось: то анимация загрузки страницы работает не так, как она считает нужным. То какой-то сторонний плагин поиска по таблице не выдает результатов, если ввести слово с двумя пробелами. То некорректно работают имена студентов, если напихать в них всевозможных знаков препинания. В итоге, на третьей итерации достала эта ситуация изрядно — вместо того, чтобы разрабатывать новые фичи, приходилось фиксить подобную ерунду, которую в реальной жизни юзер и не воспроизведет. Попросила в итоге на очередном стендапе расставлять приоритеты, а иначе дела не будет. Многие из подобных тикетов были закрыты после обсуждения с БА. Поэтому, я прекрасно понимаю тех разработчиков, которые не бросаются фиксить баги по первому зову. Очень часто и баг — не баг, и для проекта подобные тикеты во вред.

в моем личном топе: «не могу, так как нет времени — готовлюсь к собеседованию» от человека, которого попросили исправить свой же косяк за две недели до конца проекта (за счет которого тот ессно билился).

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

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

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

Все смешалось в доме Обломовых. ©

Почему тестировщик решает что нужно починить и какие приоритеты работы разработчика, а не продакт оунер владеющий картой и планом движения производства?

Почему разработчик решает на что ему тратить время, а на что нет? Где план движения, приоритеты, acceptance criteria для того чтобы считать работу законченной?

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

>

Все важнее выйти на рынок быстрее конкурентов чем без багов.

Пойди расскажи об этом ребятам, аутсорсящим какой-то немецкий банк

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

Хм, статья как-то все переусложняет. Алгоритм ведь очень прост:
1) Заводишь тикет на то, что считаешь багом, ждешь реакции девелопера.
2) Если считаешь, что баг прям супер критикал — говоришь об этом на стендапе, или тегаешь причастных в рабочем чатике, или как у вас принято.
3) Если девелопер закрывает тикет как won’t fix, и ты с ним не согласен — подробно расписываешь в комментарии, почему не согласен, переоткрываешь тикет и асайнишь на продакт овнера. Опционально можешь предварительно договориться о созвоне с девелопером и попытаться его переубедить, если у вас коммуникация нормально налажена.
4) Если продакт овнер не соглашается с тобой и снова закрывает тикет — штош, можно либо смириться, либо воспользоваться поводом и уйти на +500 через дорогу.

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

Ага, за умови, що багтрекер працює :) Багато проектів побудовано на принципі «іді і поговорі».

А якщо і там баг-трекер не працює, з наступними +500 може бути облом-с :)

-Причина увольнения с прошлой работы ? -Багтрекер!

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

За релізи відповідають зазвичай ДевОпси :))

Если считаешь

В топку эти считаешь, северити должна определяться правилами

На проекте весьма редко происходит непосредственное взаимодействие между тестером и разработчиком. Более того, если процесс нормально поставлен, то тестер не должен дергать разработчика вроде: «Я тут нашел баг, пойди пофикси его». Тестер создаёт тикет, а дальше уже тикет живёт своей жизнью: его могут обговорить на ближайшем стендапе, ПМ может включить его в беклог проекта, может не включать, счесть некритичным, стейкхолдер может сказать — делайте как в спеке, я не считаю, что этот тикет описывает реальную проблему... Но в любом случае при правильно поставленном процессе тестировщик (и даже тестлид) не будет требовать у разработчика фиксить этот баг и слушать описанные отговорки.

Чомусь не описали кейс, який дуже тригерить особисто мене і в якому я зазвичай відмовляюсь робити.
Є якийсь тікет, з багом чи реквест нової фічі. Ти робиш все що сказано в тікеті, але в процесі тестування куей знаходить новий баг який прямо чи опосередковано відноситься до твоєї роботи.
Моя позиція така — поточний тікет треба закривати і відкривати новий на вже іншу проблему, але зустрічав тестувальників і навіть менеджерів(як правило, нетехнічні) які вважають, що це все має робитися в рамках оригінального тікета і відмовляються його закривати. І ось тут вже розгорається конфлікт :)))

Для улучшения метрик и повышения KPI обоих, конечно лучше открыть новый. Если проблема текущего исправлена. А вот если исправлена не полностью...

не полностью

Ось тут починається людський фактор.
Якщо описана в тікеті поведінка реалізована/пофікшена, тоді нема про що більше говорити і тікет треба закривати.
Для цього на проекті потрібен контроль аби тікети адекватно писались, із step to reproduce && definition of done. Якщо цього в тікеті нема, то девелопер має повне право не брати цей тікет в роботу, так як незрозуміло, що взагалі зробити треба, «шо б було красіво» або потік думок від продукт овнера це не опис тікета.

Само собою, що нові фічі не повинні ломати старі, якщо юніт тести попадали, то це причина повернути тікет назад в роботу.

Хехе, актуальна тема)

Якщо ми приймаємо, що переважна більшість команд працює по скраму або хоча б намагається це робити, то кюєй має заводити тікети які будуть обговорюватись на пленінг мітингу, де буде присутня вся команда і там можна ± об’єктивно обговорити що варто, що ні та скільки це займе, після чого сформувати беклог на спринт і вйо.
Якщо кюєй думає, що знайшов баг але документації на це нема, то треба писати листа на відповідних стейкхолдерів і в процесі листування уточнити що саме має бути зроблено. В цю переписку може включитись девелопер, дати естімейт і скоуп робіт або буде погоджений або ні.

Якщо якийсь тікет було обговорено устно на зустрічі, по завершенню ПМ чи лід чи БА чи куєй має написати листа на стейкхолдерів і залучених девів з мітинг-нотисами де вкаже, що саме буде робитись.

При наявності вищеописаного підходу майже виключається людський фактор і аргументи «хочу/нехочу», «баг/не баг», «правильно/неправильно».

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

Якщо кюєй думає, що знайшов баг але документації на це нема,

та если manual QA нашел что верстка в каком-то браузере разлазится то документации и не надо — и так понятно что это баг

кюєй має заводити тікети які будуть обговорюватись на пленінг мітингу

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

Підхід до роботи повинен бути адекватним.
Якщо кюєй знаходить щось, що визначається продукт овнером чи будь-ким іншим із стейкхолдерів яяк «showstopper» чи хоча б «critical», то з великою ймовірністю будуть відкладені поточні менш пріоритетні таски і цей візьметься в роботу.
Але якщо після цього спринту не буде релізу, а буде просто ще один черговий спринт, то не бачу проблем відкласти цей новий тікет до наступного спринта.

Іншим аспектом є те, наскільки проблема є важливою для бізнеса.
Якщо виявиться, що лише 0,325% юзерів мого продукту юзають сафарі, а 94,576% юзають хром, то я віддам перевагу аби всі тікети по хрому, навіть мінорні, були закриті, а тоді братись до сафарі. Але само собою, що це рішення повинно прийматись не на рівні дева чи кюєя.

що переважна більшість команд працює по скраму

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

А как код может быть зашипленый если там куча багов ?

А як тоді по істинному скраму працюють коли проект все ще в розробці?
Баг це дуже широке поняття, яке може означати як відсутність якоїсь функціональності так і її неправильна робота.
Також до багів може призвести ситуація, коли змінились вимоги і вчорашній обезбаженний код стає вмістилищем такових.

Не варто путати «Ship it» та реліз, пускати в реліз забаговаий продукт дійсно не варто, але робити код фріз в кінці ітерації, навіть якщо не всі тікети закриті та не всі баги пофікшені — вай нот.

Не варто путати «Ship it» та реліз, пускати в реліз забаговаий продукт дійсно не варто

Раскажи это геймдевам с их ЕАП ). Продать недоделанное, забагованное г-но, а там юзеры потестят — это сейчас их все )))

Из статьи сложно понять, что является багом? Явная ошибка (собственно баг) системы/интерфейса/реализации или просто сделали не так как нужно / не совсем так как нужно?

Это делал не я

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

Это было сделано до меня

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

Объясни как, тогда сделаю

Тут тоже все логично, бывает что QA приходит с запросом «сделай, чтобы окно было и закрыто и открыто одновременно» (вариант утрированный, но все же)

Сказали сделать только это
Всегда представляю себе хирурга, который из двух пулевых отверстий зашил только одно

Это некорректный пример. Хирург ведь не может сказать, что клиент платит только за одно пулевое отверстие, а вторая is not in scope of current sprint и вообще тут dependency on other team features.

А як же незамінний «це не баг, це фіча»?

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

Це проблема не тільки на орбіті, а і на землі теж
www.youtube.com/watch?v=AaZ_RSt0KP8

Человек который не занимается написанием коммерческого кода поучает как его писать. Классика.

Это делал не я" или «Это было сделано до меня
А что, я должен?

вон из профессии. (ну или ждать пока повзрослеет)

Объясни как, тогда сделаю
В спеке про это не сказано
Сказали сделать только это
Я согласовал такую реализацию с менеджером

Ссорян, Михаил. Но спеку пишет не QA и не разраб. Отсутствие имплементации отсутствующих реквайрментов — это не вина разработчика. QA в таком случае должен триггерить PO, BA или кто там у вас пишет и приоритезирует требования. Решать такие проблемы по упрощеной схеме типа «Просто пофикси этот баг!» чревато последствиями — начиная с того, что новые требования так нигде и не будут задокументированы, и заканчивая тем, что в результате «фикса» получим еще большее гуано.

Так что разраб в этом случае молодец, что не ведется на такие подкаты.

А если от клиента приходят только бизнес требования. А требования продуктовые мы уже в команде формируем? Тогда либо мы в команде договоримся, либо пойдем с вопросом обратно к клиенту. Клиент может сказать «мне нравится оба решение. Сколько времени займет?» И мы вернёмся решать вопрос обратно внутри команды... (Это я про баги в требованиях).

Хороший разработчик если и не ведётся — то аргументировано. Тогда тестировщик соглашается, иначе идём перекладывать ответственность на третьего

А причем тут клиент к тому, что в команде должен быть кто-то кто возьмет на себя роль BA и PO? Задача разработчика код педалить и фичи деливерить в соответствии с известными требованиями и приоритетами. Определение требований и приоритетов для команды — это обязанность отдельного человека. Причем очень желательно, чтобы такой человек у команды был один, а не целый зоопарк стэйкхолдеров.

PO, BA или кто там у вас пишет и приоритезирует требования.

Не видел не одного проекта, где были бы BA что писалиб приземленные требования. Темболее технические. То что видел это требования в стиле «наш бизнес должен приносить 146% прибили» , потому ситуация где сам дев (собрание девов) определяет как и что должно работать — вполне типична.

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

pics.me.me/...​for-a-reason-67732505.png

Ну ксожалению так и есть. Щас модно куа вообще не нанимать — это тоже кагбы на Васю-девелопера сверху ложиться. А еще девопсъ; клауды-кубирнетисы и прочее г-но. Короче, плохо быть Васей, хорошо быть Колей.

Зависит от ситуации. Некоторые вполне могут быть аргументами, если есть более приоритетные задачи, деплой на носу, временнно нет достаточно разработчиков, у бага низкая стоимость+ его фикс заберёт действительно много времени и т. д.
Это не значит что их никогда не стоит фиксить, но вполне можно отложить.

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

PS
А где же наше любимое: «Это не баг — это фича!»? :)

А где же наше любимое: «Это не баг — это фича!»? :)

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

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

«Это невозможно»

оо, це моє улюблене)))спочатку доказують що це не можливо а тоді виявляється шо там три секунди фіксить))))

подборка неплохая, спасибо большое !

Но есть одно замечание
мне кажется, что у Вас порой странный подход к тому, как трактовать термин «баг»

Баг — это поведение системы, которое отличается от ожидаемого заказчиком поведения, которое весьма часто идет в разрез с общепринятой логике даже в рамках доменной области.

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

Сказали сделать только это

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

Я согласовал такую реализацию

именно так. мы исходим из понимания и приоритетов бизнеса.
особенно в ситуации жесткого лимита времени

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

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

Ааа шикарная подборка, лайк

Подписаться на комментарии