Статистика — ну, чтобы понять — вот тут мы работали полгода, и после этого накопилось просроченных багов
А вот тут мы полгода работали по-другому, и тогда завала багов не было
То есть это больше для последующего анализа, а не для тактических решений…
Да, это уже другой кейс. Эти десять тикетов ведь не связаны — это суть один и тот же тикет.
В нашем багтрекере это зовётся «дупликатами». И — да, мы сразу все, кроме одного основного, закрываем, при этом автоматически подписывая авторов дубликатов на уведомления по основному тикету
>о одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию
Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Даже во время внутренней дискуссии мне писали про это сразу несколько человек :)
Практика “Заведи на меня (заведу на себя) карточку в трелло с описанием проблемы без детального описания (ведь мы же оба будем ‘помнить’ о чем она, когда до нее руки дойдут)” так же очень порочна и должна пресекаться при первых же мыслях о ней.
В терминах Андрея оба участника на момент записи карточки знают где сейчас кот, а спустя время как правило забывают даже кого искать — кота или собаку.
Про заведение уже согласованных багов
Да, я не сказал сразу, что баги хорошо бы сначала проговаривать с человеком в теме.
Но:
баг будут читать и другие люди. Списки багов просматривает потом зачастую весь сквад, включая разработчиков, суппортёров и техрайтеров
И каждый из них будет искать кота, потому что с одним каким-то человеком решили, что он поймёт и так.
даже этот понимающий человек через месяц тоже не вспомнит (Станислав меня опередил на минуту, чорт.)
Я бы от себя ещё добавил, что проблемы желательно описывать так, чтобы ты сам через месяц мог понять, что там в баге написано, когда детали забудешь
А ещё бывает, что его за эти две недели пофиксил кто-то другой, как сайд эффект от починки другой проблемы / рефакторинга / нечаянно.
Могу дополнить. Очень часто приходится не только “искать кота на картинке” но и проверять что “кота на картинке больше нет”. И в этом случае steps to reproduce и expected results вдвойне полезны.
Но — да, аргументы в пользу быстрой коммуникации и мгновенного фикса тоже были.
Именно поэтому баг лучше всего фиксить сразу. Кроме теории разбитых окон, которая тоже важна, здесь простая экономика.
В этом треде описывается как лучше всего зафиксировать понимание сути бага на потом. Но имея это понимание и разработчика, способного пофиксить этот баг, или хотя бы написать юнит тест, воспроизводящий его, фикс может занять меньше времени и энергии, чем запись этого бага.
Важно помнить что результатом всего процесса является отсутствие бага. А не скриншоты, тексты и примеры. Поэтому, я считаю, важно пытаться перед записью бага поговорить с разработчиком, и возможно, сразу пофиксить его.
Я хотел написать «эксепшене»
В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.
Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.
Что же до англицизмом… что ж, меня тоже бомбит, когда англицизмы используют для имеющихся в русском языке понятий, вводя тем самым новые термины взамен русских устоявшихся.
Но в такой области языка, как разработка ПО…
> Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
Серьёзно? Стало понятнее? )
— Дальше довольно много претензий про то, что тестировщик должен и не должен.
Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.
— >Просто пиши то что ты видишь, а не то что ты думаешь
Это хорошее дополнение, спасибо за него.
Это противопоставление неверно. Как мне недавно подсказали, оно называется теоремой Эскобара. Ссылку давать не буду, потому что она сформулирована в обсценённой лексике, но она хорошо гуглится )
Вы подменяете тезис о том, что баг должен быть записан хорошо, тезисом о том, что баг должен быть записан только с шагами и никак иначе.
В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.
Я правильно понял по видео, что у них, грубо говоря, инлайн-редактирование скриншота прямо как будто бы до его снятия?
Выглядит и вправду забавно, доберусь дома до убунту — попробую.
А вот тут тоже вопрос дискуссионный
Мастер-тикеты уже начинают искажать статистику по количеству багов )
Да и вообще… так ли они нужны?
Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
В каждом из них в комментах проставляем ссылки.
Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.
:) да, это пофикшено в версиях 19.1.4 и 18.2.9, как я только что убедился, проверив свой тикет.
Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).
Забавная штука.
Полноценную скриншотилку не заменит (нет стрелочек из коробки, нарисованное не является векторным — его править тяжело, нет текста)
Но на голой чужой машине — может быть очень даже ничего, спасибо
>Очень часто для починки бага достаточно одного только стектрейса.
Ну, это только в первые пять лет жизни продукта!.. :-D
Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.
Но потом, когда функционал начинает жить своей жизнью, и пользователи нагибают его так, как автору и не снилось… вот там уже без шагов зачастую не разберёшься.
Если бы все программы были stateless — было бы проще, но увы :(
Я их тоже голосовые сообщения терпеть не могу… но, кажется, нам придётся с ними жить
Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGU
Ну, да, бывали случаи, когда видео оказывалось прям полезно-полезно-полезно. То есть если бы не оно, то и фикса могло бы не быть, потому что проблема оказалось бы не понятной в принципе.
Но это всё же от бедности )
Ну и для себя вывел, что если вот так благодаря видео пришло таки озарение — то надо его хотя бы самому в комментах к багу записать. Чтобы все будущие читатели были благодарны.
Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
Спасибо!
Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
Если в момент взятия интервью интервьюер не бухал с интервьюируемым, то использование термина «нахер» в вопросах выглядит странно.
Я бы после этого на вопросы уже отвечать не стал :)
Если бухали — то вопросов нет, это нормально в дружеском общении. Но тогда это в статье стоило бы уточнить.
А вот тут мы полгода работали по-другому, и тогда завала багов не было
То есть это больше для последующего анализа, а не для тактических решений…
В нашем багтрекере это зовётся «дупликатами». И — да, мы сразу все, кроме одного основного, закрываем, при этом автоматически подписывая авторов дубликатов на уведомления по основному тикету
Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Даже во время внутренней дискуссии мне писали про это сразу несколько человек :)
А ещё бывает, что его за эти две недели пофиксил кто-то другой, как сайд эффект от починки другой проблемы / рефакторинга / нечаянно.
Но — да, аргументы в пользу быстрой коммуникации и мгновенного фикса тоже были.
Просто не всегда получается.
В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.
Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.
Что же до англицизмом… что ж, меня тоже бомбит, когда англицизмы используют для имеющихся в русском языке понятий, вводя тем самым новые термины взамен русских устоявшихся.
Но в такой области языка, как разработка ПО…
> Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
Серьёзно? Стало понятнее? )
— Дальше довольно много претензий про то, что тестировщик должен и не должен.
Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.
— >Просто пиши то что ты видишь, а не то что ты думаешь
Это хорошее дополнение, спасибо за него.
Вы подменяете тезис о том, что баг должен быть записан хорошо, тезисом о том, что баг должен быть записан только с шагами и никак иначе.
В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.
Выглядит и вправду забавно, доберусь дома до убунту — попробую.
Мастер-тикеты уже начинают искажать статистику по количеству багов )
Да и вообще… так ли они нужны?
Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
В каждом из них в комментах проставляем ссылки.
Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.
Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).
По хорошему, одна проблема — один багрепорт.
Полноценную скриншотилку не заменит (нет стрелочек из коробки, нарисованное не является векторным — его править тяжело, нет текста)
Но на голой чужой машине — может быть очень даже ничего, спасибо
Ну, это только в первые пять лет жизни продукта!.. :-D
Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.
Но потом, когда функционал начинает жить своей жизнью, и пользователи нагибают его так, как автору и не снилось… вот там уже без шагов зачастую не разберёшься.
Если бы все программы были stateless — было бы проще, но увы :(
Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGU
Но это всё же от бедности )
Ну и для себя вывел, что если вот так благодаря видео пришло таки озарение — то надо его хотя бы самому в комментах к багу записать. Чтобы все будущие читатели были благодарны.
Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
Пойду баг репортить )
Я бы после этого на вопросы уже отвечать не стал :)
Если бухали — то вопросов нет, это нормально в дружеском общении. Но тогда это в статье стоило бы уточнить.
Дэшбоарды от ДевЭкспресса
www.devexpress.com/Products/NET/Dashboard
С веб-дизайнером, которые мы сотоварищи пилим последнюю пару лет
demos.devexpress.com/Dashboard/?mode=viewer
Сервак обязательно на .NET (можно .NET Core под линухом), клиентская часть — просто js, можно встроить в любой фреймворк.
Если щас мой коммент сочтут не просветительским, а рекламным — прощайте, друзья чачкасы.