Комментарии 104
А кот-то где?
А вот кто дочитал статью до конца — тот нашёл ссылку!
По ссылке «вот тут» находится картинка, где черным квадратом и красным кружком обведены области с белым цветком, который по форме напоминает нос кота. Кот по ссылке не найден.
Там ухо торчит.
А второе ухо скрыто травинками, которые находятся позади головы? И всё тело до последней шерстинке скрыто в невысокой траве. Также обращает на себя внимание отсутствие глаз, которые должны были бы выделяться на фото. На многочисленных картинках типа «найди кота» зачастую именно глаза выдают зверька. Поэтому вполне можно предположить парейдолию.
— вы знаете, а хабр глючит, к первому комментарию не идёт ответ
Пойду баг репортить )
Пойду баг репортить )
Чуть ниже середины фото и правее.
Где кот!?
Программы для снятия скриншотов
Из личных предпочтений я бы добавил GreenShot (бесплатный под вин) и LightShort если у вы работаете на маке или винде (хотя он полайтовее)
FastStone Capture тоже на их уровне, судя по скриншотам. Все у всех всё своровали.
Встроенный Snipping Tool в винде часто просто достаточен.
Вырезать, обвести, нарисовать стрелку — все есть, бесплатно, уже установлено, доступно в самой анально огороженной политиками организации.
Вырезать, обвести, нарисовать стрелку — все есть, бесплатно, уже установлено, доступно в самой анально огороженной политиками организации.
НЛО прилетело и опубликовало эту надпись здесь
Проблема описания багов относится не только к программированию, а и ко всем отраслям по ремонту.
Когда работал по ремонту техники (телефоны, планшеты, ноутбуки), то очень часто приносили с неисправностью «глючит» и приходилось часто искать котов. На приемке строго запретил принимать в ремонт с неисправностями типа: «глючит», «тупит», «плохо работает» и т.п., только с явным описанием проблемы, поиск котов резко сократился.
(на картинке кота нашел без подсказки =) )
Когда работал по ремонту техники (телефоны, планшеты, ноутбуки), то очень часто приносили с неисправностью «глючит» и приходилось часто искать котов. На приемке строго запретил принимать в ремонт с неисправностями типа: «глючит», «тупит», «плохо работает» и т.п., только с явным описанием проблемы, поиск котов резко сократился.
(на картинке кота нашел без подсказки =) )
Всем тестировщикам в уши. А то после одного тестировщика бэклог полон багов, которые непонятно как непонятно где воспроизвести, а у другого спрашиваешь — ты видел этот краш?, а он отвечает — да, но не заносил как баг потому что еще не нашел четкие степы.
Сразу видно, что вы — хороший тестировщик.
Сразу видно, что вы — хороший тестировщик.
Спасибо!
Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
Прямо игра в одни ворота. Не всякий программист читает описание бага внимательно, обходится одним заголовком. Я уже молчу про комментарии, когда находишь важную информацию по дефекту и заносишь её вне описания, чтобы была видна историчность. Или же когда дефект воспроизводится после починки и его гоняют туда-сюда по статусу, комментарии тоже не всегда читают.
это просто невнимательность, но у девелоперов все же с годами вырабатывается больше скиллов дочитать описание до конца, слишком часто он будет себя чувствовать глупо не дочитав детали.
P.s. есть хоть одна причина, почему некоторые тестеры называют баги дефектами?
P.s. есть хоть одна причина, почему некоторые тестеры называют баги дефектами?
НЛО прилетело и опубликовало эту надпись здесь
По поводу видео только для анимаций поспорю — нет, нет и еще раз нет. Очень часто и только на видео я замечаю множество аспектов, которые можно пропустить в степах. Например, на телефоне выбран 3g, а данный вид групповых чатов работает только на wi-fi. Я вижу iPhoneX, на котором данные заехали под монобровь, а у меня в распоряжении только iPhone 7. И еще множество нюансов, которые тестировщик от лени, от неведения, от ужасного владения английским может не указать, видно на видео.
В остальном я категорически согласен со всем, особенно с тем что нужно выкидывать лишние степы и перевоспроизводить баг несколько раз. Уж сколько было от разных тестировщиков «от бога» баг содержания «вот иногда крашится когда заходишь на эту вьюшку, не всегда воспроизводится», а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?
В остальном я категорически согласен со всем, особенно с тем что нужно выкидывать лишние степы и перевоспроизводить баг несколько раз. Уж сколько было от разных тестировщиков «от бога» баг содержания «вот иногда крашится когда заходишь на эту вьюшку, не всегда воспроизводится», а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?
Ну, да, бывали случаи, когда видео оказывалось прям полезно-полезно-полезно. То есть если бы не оно, то и фикса могло бы не быть, потому что проблема оказалось бы не понятной в принципе.
Но это всё же от бедности )
Ну и для себя вывел, что если вот так благодаря видео пришло таки озарение — то надо его хотя бы самому в комментах к багу записать. Чтобы все будущие читатели были благодарны.
Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
Но это всё же от бедности )
Ну и для себя вывел, что если вот так благодаря видео пришло таки озарение — то надо его хотя бы самому в комментах к багу записать. Чтобы все будущие читатели были благодарны.
Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это противопоставление неверно. Как мне недавно подсказали, оно называется теоремой Эскобара. Ссылку давать не буду, потому что она сформулирована в обсценённой лексике, но она хорошо гуглится )
Вы подменяете тезис о том, что баг должен быть записан хорошо, тезисом о том, что баг должен быть записан только с шагами и никак иначе.
В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.
Вы подменяете тезис о том, что баг должен быть записан хорошо, тезисом о том, что баг должен быть записан только с шагами и никак иначе.
В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.
НЛО прилетело и опубликовало эту надпись здесь
то есть тестировщики то не мучаются искать такие последовательности?
У тестировщика это, как бы, должностная обязанность.
НЛО прилетело и опубликовало эту надпись здесь
А у программиста должностная обязанность писать корректный и рабочий код
А у тестировщика находить все-все баги и ошибки программы тогда уж, не допуская их проявления в продакшине.
Все ошибки делают. И программисты баги допускают, и тестировщики ошибки пропускают. Это нормально.
Не нормально — это когда программист получил тикет и решил его не делать/делать не полностью. Также и тестировщик — если нашел ошибку, ее надо описать поймать и описать. У всех свои обязанности и все (надеюсь) их выполняют в меру своих возможностей.
НЛО прилетело и опубликовало эту надпись здесь
Я поддержу, что в определенных аспектах реально работа программиста переоценена и некоторые программисты считают себя небожителями, которых должны обслуживать все остальные — админы, тестировщики и пр. Я думаю, что здесь не стоит забывать, что разработка ПО — это коллективная работа, что хороший продукт не получится без слаженной работы всех участников процесса, что ответственность за качество так же на всех, а не на конкретных "крайних".
Ещё раз, не все баги четко привязаны к жесткой последовательности. Или последовательность действий — это десяток различных не связанных действий подряд.Абсолютно любой баг — результат жесткой последовательности действий, если вам действия кажутся несвязанными — вы не разобрались в причинах бага.
QA всегда лучше знают приложение, т.к. девелопер варится в своей части, а QA по всему приложению.
В итоге это была связка с типом теста и какой-то обработкой тестов вообще для другого приложения печати результатов.
Код тестов связан с кодом продакшна? Где вы вообще работаете?
Абсолютно любой баг — результат жесткой последовательности действий, если вам действия кажутся несвязанными — вы не разобрались в причинах бага.
Это неверно. Во-первых, может быть несколько совершенно разных багов, которые манифестируются одним образом и проявляются при схожих условиях. Во-вторых, внешняя среда, в которой выполняется программный код, не является статичной. Можно сколько угодно говорить о том, что нужно фиксировать зависимости и пр., но влияние среды очень велико и какая-нибудь минимальная настройка может приводить к каскадному эффекту. В третьих, можно опровергнуть утверждение, что проявление бага является жесткой последовательностью действий, кстати, чьих? Пользователя или компьютера? В крайнем случае, давайте проапеллируем к тому, что в коде есть рандом (а такое действительно может быть).
есть хоть одна причина, почему некоторые тестеры называют баги дефектами?
А как их надо называть? Баг — это отличие в наблюдаемом поведении программы от желаемого. Значит, это дефект. Если же поведение не определено, то есть мы не знаем, что мы хотим… То это проблема технического задания. Если же программа ведет себя так, как мы ожидаем, то это не баг, а фича )
Слова девопса, но не девелопера
Баг — это отличие в наблюдаемом поведении программы от желаемого. Значит, это дефект.Это только малая часть багов такая. При этом даже в них далеко не всегда верно желаемое (даже если это четко прописано в задаче). Дефектом баг становится в момент когда ответственный за эту часть исправляет его и все соглашаются что да, вот так и должно все работать. На моей практике таких багов меньше половины, что-то решается оставить как фичу, где-то меняется задача, где-то придумывается вообще третий вариант отличающийся и от изначальной задачи и от реализации. Половина вообще идет как улучшение а не фикс. Зачастую даже за деньги клиента и с его согласия (никакого обмана естественно, просто нормальное описание клиенту почему так, почему это будет стоить дополнительных денег и какие проблемы это улучшение будет решать). Но когда тестеры и девелоперы начинают называть баги дефектами, то они обычно начинают использовать это слово как синоним, а не как название совершенно конкретной небольшой категории возможных проблем.
НЛО прилетело и опубликовало эту надпись здесь
На Upwork, когда попадается какой-то подходящий по скиллам мелкий проект, но заказчик предлагает посмотреть видео с описанием задачи, прохожу мимо. Лучше текстом объяснить что не так.
P.S. Голосовым или видеочатом вообще ненавижу пользоваться, такое тоже пропускаю. Пусть лучше заказчик текстом напишет задание, тогда уже не забудешь мелких деталей.
P.S. Голосовым или видеочатом вообще ненавижу пользоваться, такое тоже пропускаю. Пусть лучше заказчик текстом напишет задание, тогда уже не забудешь мелких деталей.
Я их тоже голосовые сообщения терпеть не могу… но, кажется, нам придётся с ними жить
Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGU
Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGU
Текст длинный и запутанный. Выглядит как перевод. Все хорошо до примеров. Потом — плохо.
Но все равно за статью спасибо, кину коллегам.
Но все равно за статью спасибо, кину коллегам.
Стэк трейс / ошибки в консоли при явном экспешене
Ну, это и так почти все понимают и прикладывают, пишу только для завершённости списка.
Нет, это понимают не все. И, если упорядочить по важности, это должно идти первым пунктом, а не предпоследним! Очень часто для починки бага достаточно одного только стектрейса. Вот в тех случаях когда его уже не достаточно — тогда уже нужны шаги для воспроизведения, ожидаемое и наблюдаемое поведение, и прочие скришоты.
>Очень часто для починки бага достаточно одного только стектрейса.
Ну, это только в первые пять лет жизни продукта!.. :-D
Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.
Но потом, когда функционал начинает жить своей жизнью, и пользователи нагибают его так, как автору и не снилось… вот там уже без шагов зачастую не разберёшься.
Если бы все программы были stateless — было бы проще, но увы :(
Ну, это только в первые пять лет жизни продукта!.. :-D
Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.
Но потом, когда функционал начинает жить своей жизнью, и пользователи нагибают его так, как автору и не снилось… вот там уже без шагов зачастую не разберёшься.
Если бы все программы были stateless — было бы проще, но увы :(
а «цветорые» это нормально? (баг с наложением стрелки на текст)
:) да, это пофикшено в версиях 19.1.4 и 18.2.9, как я только что убедился, проверив свой тикет.
Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).
По хорошему, одна проблема — один багрепорт.
Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).
По хорошему, одна проблема — один багрепорт.
И один мастер тикет на всех со ссылками на связаные проблемы.
А вот тут тоже вопрос дискуссионный
Мастер-тикеты уже начинают искажать статистику по количеству багов )
Да и вообще… так ли они нужны?
Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
В каждом из них в комментах проставляем ссылки.
Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.
Мастер-тикеты уже начинают искажать статистику по количеству багов )
Да и вообще… так ли они нужны?
Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
В каждом из них в комментах проставляем ссылки.
Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.
А так ли нужна статистика по количеству багов? Я вроде уже не один год работаю тестировщиком, в том числе строю процессы, а не только тестирую таски, но я так и не смог придумать ни одной адекватной причины зачем нузна статистика по количеству багов. Ну кроме того что это успокаивает менеджера и он начинает считать что вы работаете а не дурака валяете.
А касательно мастер тикета — я как раз люблю записывать список багов в один тикет с которым потом ПМ с лидом разбираются — что фиксить, как и когда. Довольны все — мне приходится тратить меньше усилий на бюрократию вроде создания отдельных тасков, менеджеру и лиду проще понять объем работы и распланировать следующую итерацию.
А касательно мастер тикета — я как раз люблю записывать список багов в один тикет с которым потом ПМ с лидом разбираются — что фиксить, как и когда. Довольны все — мне приходится тратить меньше усилий на бюрократию вроде создания отдельных тасков, менеджеру и лиду проще понять объем работы и распланировать следующую итерацию.
Статистика — ну, чтобы понять — вот тут мы работали полгода, и после этого накопилось просроченных багов
А вот тут мы полгода работали по-другому, и тогда завала багов не было
То есть это больше для последующего анализа, а не для тактических решений…
А вот тут мы полгода работали по-другому, и тогда завала багов не было
То есть это больше для последующего анализа, а не для тактических решений…
Возможно мне не везло с проектами (или везло), но количество багов за первый квартал могло кардинально отличаться от количества багов за второй квартал независимо от того работали мы также или иначе. Просто потому что разные фичи пилятся в разный момент и имеют разные шансы быть забагованными. И это даже не начиная разговор о неопределенности понятия «баг».
Нет, я не говорю что вы что-то делаете неправильно, если для вас это работает — замечательно. Просто у меня ситуаций когда такой анализ мог бы сработать пока не возникало и мне было интересно как у вас получается эту метрику использовать.
Нет, я не говорю что вы что-то делаете неправильно, если для вас это работает — замечательно. Просто у меня ситуаций когда такой анализ мог бы сработать пока не возникало и мне было интересно как у вас получается эту метрику использовать.
Не столько дискуссионно, сколько кейсозависимо. Если связных проблем три штуки, то и смысла нет городить огород. А, если поломался условный BGP, и повылазили проблемы в десятках независимых систем, то смело линкуем их к одному единственному тикету.
Странно, что не упомянули
- встроенный скриншоттер в Маке. Он прекрасен (за одной небольшой деталью) и даже позволяет рисовать поверх скриншотов. P — PRODUCTIVITY
- под виндой — PicPick
- В линуксе — есть две альтернативы Spectacle & KSnapshot. Они ТОЛЬКО для снятия скринов и по умолчанию забиндены на PrntScrn.
Естественно, что продвинутые тулзы вроде Слака тоже помогают…
под виндой — PicPick
В Windows 10 — встроенный по сочетанию Win+Shift+S
Под Linux мое сердце покорил flameshot.js.org
Минималистичный интерфейс, набор всех необходимых инструментов, возможность гибко выбирать куда сохранять получившийся скриншот (автоматически зааплоадить и получить ссылку, скопировать в буфер обмена, сохранить на диск).
Минималистичный интерфейс, набор всех необходимых инструментов, возможность гибко выбирать куда сохранять получившийся скриншот (автоматически зааплоадить и получить ссылку, скопировать в буфер обмена, сохранить на диск).
Я правильно понял по видео, что у них, грубо говоря, инлайн-редактирование скриншота прямо как будто бы до его снятия?
Выглядит и вправду забавно, доберусь дома до убунту — попробую.
Выглядит и вправду забавно, доберусь дома до убунту — попробую.
Все верно, работает именно так. Выделяется область (либо фулл скрин), после чего можно выбрать необходимые действия из набора доступных функций. Можно добавить текст, заблурить, что-нибудь нарисовать и после этого сохранить/скопировать в буфер/зааплоаадить изображение.
Под Ubuntu использую уже больше года, безумно доволен.
Под Ubuntu использую уже больше года, безумно доволен.
О, flameshot реально находка. Спасибо.
Странно, но почему-то никто не упомянул Joel Spolsky и его трактат «Painless Bug Tracking»: www.joelonsoftware.com/2000/11/08/painless-bug-tracking
В OS Windows есть встроенный инструмент «problem steps recorder». Запускается из коммандной строки алиасом PSR. Автоматом делает скрины с пометками, где какие действия совершались, позволяет вставлять текстовые комментарии. Результат сохраняет в виде архива с .mht файлом. В Win 7 уже точно есть.
Парочка приветов из геймдева :)
В крупных компаниях обычно очень серьезно к этому подходят, потому что время программистов, которые ищут котов вместо починки багов, дорогое. Когда прилетает тикет — к нему обычно есть и скриншоты, и видео, и трейсы, и текстовое описание, и точная версия билда… и все равно иногда не помогает ¯\_(ツ)_/¯ потому что баги бывают хитросделанные.
А один мой хороший знакомый делал убер-фичу: в редакторе уровней один из объектов — это джира-тикет. Кликаешь на него — попадаешь в джиру, ну и в обратную сторону можно. Очень удобная штука.
Этого кота без увеличительного стекла найти невозможно
Пока ехал в метро, читал статью со смартфона, и кота разглядеть не удалось. А когда глянул на ту же картинку на большом мониторе — нашел его сразу же.
По делу: В общем-то все правильно написано. Меня, как разработчика ПО, сильно раздражают багрепорты типа «программа г-но, ни хрена не работает».
Вообще-то тестировщику за то и зарплату платят, чтобы он баги не только находил, но и мог по человечески объяснить, как их воспроизвести. Обычно для этого достаточно написать несколько строк (типа: «если случайно ввести в поле ВЛАЖНОСТЬ значение больше 100%, то никаких предупреждений при вводе не выдается, а потом в процессе работы произойдет ошибка Float Point Error»).
Ну а дальше все зависит от того, что это за ошибка.
Иногда нужно приложить какой-нибудь файл, с комментарием. (Например, «этот файл конфигурации открывается и отображается правильно, но при попытке изменить любой параметр происходит ошибка Out Of Memory»).
Скриншот может быть совсем необязателен (достаточно сказать, что именно делается неправильно), но иногда бывает необходим (когда причина ошибки — банальное отсутствие в тестируемой системе какого-нибудь шрифта).
Правильный тестировщик не только подробно опишет ошибку, но и сможет подсказать разработчику направление поиска, уточнив какие-нибудь детали. (например, «Эта фигня начала происходить только на прошлой неделе в среду, когда у заказчика в цеху ремонт кровли начали. Возможно, как-то с этим связано, потому что до того все работало нормально»).
Потому что сбои софта не всегда оказываются вызваны ошибками программиста. (я недавно в комментариях на Хабре уже рассказывал про случай, когда множественные зависания программы были вызваны неправильным подключением компьютера к электросети.)
Но самое интересное начинается, когда в роди тестировщика выступает обычный пользователь, не имеющий специальной подготовки… Вот в этом случае возможны знатные казусы. Есть личный опыт, когда моя программа вполне нормально работала у всех, а «грохалась» только у одного единственного пользователя. Причем это проявлялось на разных компьютерах, но только у одного человека! Дело осложнялось тем, что он находился в другом городе, и просто так пронаблюдать за его действиями не удавалось. По его словам — «Я просто щелкаю мышой в этом окне и программа падает!» А все мои и не только мои попытки воспроизвести эту ошибку ни к чему такому не приводили. (как мы только не извращались с мышками разных моделей и разным числом кнопок). В конце концов оказалось, что этому человеку легко удавалось делать не просто щелчок мышкой, и даже не двойной, а пяти — восьми — десятикратный! А та программа управляла технологической установкой, и в ответ на щелчки мыши отправлялась серия команд различным исполнительным механизмам (в данном случае — всяким клапанам, задвижкам, вентилям, и пр. Команды отправлялись в определенной последовательности и с нужными задержками) Поступления такого количества событий технологическая установка не успевала «переварить», и все начинало работать совсем не так, как задумывалось.
Конечно, это был мой баг, который и был немедленно исправлен, как только проблема была осознана. А дело было в середине 90-х, когда и компьютеры были не такие шустрые, и до полезных инструментов (типа Problem Steps Recorder) еще не додумались. Поэтому осознал я эту проблему не сразу.
По делу: В общем-то все правильно написано. Меня, как разработчика ПО, сильно раздражают багрепорты типа «программа г-но, ни хрена не работает».
Вообще-то тестировщику за то и зарплату платят, чтобы он баги не только находил, но и мог по человечески объяснить, как их воспроизвести. Обычно для этого достаточно написать несколько строк (типа: «если случайно ввести в поле ВЛАЖНОСТЬ значение больше 100%, то никаких предупреждений при вводе не выдается, а потом в процессе работы произойдет ошибка Float Point Error»).
Ну а дальше все зависит от того, что это за ошибка.
Иногда нужно приложить какой-нибудь файл, с комментарием. (Например, «этот файл конфигурации открывается и отображается правильно, но при попытке изменить любой параметр происходит ошибка Out Of Memory»).
Скриншот может быть совсем необязателен (достаточно сказать, что именно делается неправильно), но иногда бывает необходим (когда причина ошибки — банальное отсутствие в тестируемой системе какого-нибудь шрифта).
Правильный тестировщик не только подробно опишет ошибку, но и сможет подсказать разработчику направление поиска, уточнив какие-нибудь детали. (например, «Эта фигня начала происходить только на прошлой неделе в среду, когда у заказчика в цеху ремонт кровли начали. Возможно, как-то с этим связано, потому что до того все работало нормально»).
Потому что сбои софта не всегда оказываются вызваны ошибками программиста. (я недавно в комментариях на Хабре уже рассказывал про случай, когда множественные зависания программы были вызваны неправильным подключением компьютера к электросети.)
Но самое интересное начинается, когда в роди тестировщика выступает обычный пользователь, не имеющий специальной подготовки… Вот в этом случае возможны знатные казусы. Есть личный опыт, когда моя программа вполне нормально работала у всех, а «грохалась» только у одного единственного пользователя. Причем это проявлялось на разных компьютерах, но только у одного человека! Дело осложнялось тем, что он находился в другом городе, и просто так пронаблюдать за его действиями не удавалось. По его словам — «Я просто щелкаю мышой в этом окне и программа падает!» А все мои и не только мои попытки воспроизвести эту ошибку ни к чему такому не приводили. (как мы только не извращались с мышками разных моделей и разным числом кнопок). В конце концов оказалось, что этому человеку легко удавалось делать не просто щелчок мышкой, и даже не двойной, а пяти — восьми — десятикратный! А та программа управляла технологической установкой, и в ответ на щелчки мыши отправлялась серия команд различным исполнительным механизмам (в данном случае — всяким клапанам, задвижкам, вентилям, и пр. Команды отправлялись в определенной последовательности и с нужными задержками) Поступления такого количества событий технологическая установка не успевала «переварить», и все начинало работать совсем не так, как задумывалось.
Конечно, это был мой баг, который и был немедленно исправлен, как только проблема была осознана. А дело было в середине 90-х, когда и компьютеры были не такие шустрые, и до полезных инструментов (типа Problem Steps Recorder) еще не додумались. Поэтому осознал я эту проблему не сразу.
Мы при виде видео в тикете обычно восклицаем: «ну вот, начинается: «следите за руками»!»
getgreenshot.org же!
Вопрос скриншотов оным закрыт давно и надолго :)
Вопрос скриншотов оным закрыт давно и надолго :)
6) Стэк трейс / ошибки в консоли при явном экспешенеУ меня предохранитель перегорел на последнем слове :)
И вот одно из моих правил: разработчикам без тебя неясности хватает, изьясняйся недвусмысленно, и точно.
В приведенной цитате: то ли это «экспектейшн» хотели написать, то ли «эксепшн», ведь ожидания тоже бывают явные и неявные. И уже лишние ватты разработчика тратятся не на решение проблемы, а на осмысление твоего небрежного наброска.
Ведь плох тот тестировщик который не хочет чтобы его тикет быстро решили. «Так что ж ты тогда, падла, даже шанса не оставляешь разработчику чтобы его решить» — думаю я, когда читаю некоторые «наброски».
И, следом, еще одно мое правило: по возможности без англицизмов и технических терминов. Тестировщик это в первую очередь пользователь. А раз пользователь вот и не вы*вайся. Пиши как маме.
Описание ошибки должно содержать кратчайший известный путь воспроизведения.
Да, это работа тестировщика найти этот путь. Да, это трудно и долго. Но это и есть тестирование. Вообще если ты не воспроизвел ошибку хотя бы еще раз, ее нельзя репортить.
В заголовке я пишу, что не так и при каком условии. Если насобачиться можно всегда уложиться в одно предложение. Например: «Профиль пользователя отображается неверно при возврате из меню настроек пользователя.» Описание не должно давать полной картины, но оно должно, при беглом прочтении, давать общее представление так чтобы можно было отличить этот тикет от другого, или упомянуть его в разговоре. Обратная проверка заголовка — если из него можно напрямую сформулировать запись в релизный журнал именений. Например: «Исправлена ошибка когда профиль пользователя в некоторых случаях отображался неверно».
Описанию ошибок меня научил один коллега, сам того не желая. Он был разработчиком трейс-монитора для нашей проги. И вот у меня этот трейс-монитор однажды перестал реагировать на ввод мыши. Я завел тикет, и написал, что у программы «фриз». Он пришел и сказал мне на повышенных тонах, что это не фриз. Оболочка не реагирует, но программа продолжает работать. А ушел сказав: «Просто пиши то что ты видишь, а не то что ты думаешь.»
С тех пор прошло пять лет, а это золотое правило я вспоминаю каждый раз по сей день когда вдруг сомневаюсь как описать ошибку. Просто пиши то, что видишь.
А это кстати совсем нетривиальная задача.
Ну и конечно при собеседовании тестировщика, я бы в первую очередь, проверял владение челвоеческим языком. Если человеку трудно изьясняться, (ну бывает такое, что слабое место) то ему нельзя быть тестировщиком.
Я хотел написать «эксепшене»
В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.
Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.
Что же до англицизмом… что ж, меня тоже бомбит, когда англицизмы используют для имеющихся в русском языке понятий, вводя тем самым новые термины взамен русских устоявшихся.
Но в такой области языка, как разработка ПО…
> Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
Серьёзно? Стало понятнее? )
— Дальше довольно много претензий про то, что тестировщик должен и не должен.
Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.
— >Просто пиши то что ты видишь, а не то что ты думаешь
Это хорошее дополнение, спасибо за него.
В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.
Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.
Что же до англицизмом… что ж, меня тоже бомбит, когда англицизмы используют для имеющихся в русском языке понятий, вводя тем самым новые термины взамен русских устоявшихся.
Но в такой области языка, как разработка ПО…
> Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
Серьёзно? Стало понятнее? )
— Дальше довольно много претензий про то, что тестировщик должен и не должен.
Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.
— >Просто пиши то что ты видишь, а не то что ты думаешь
Это хорошее дополнение, спасибо за него.
Вспомнил, полностью фраза звучала так: «пиши что ты делаешь и что видишь, а не то что ты думаешь ты видишь».
довольно много претензий про тоБоже упаси, какие претензии, счастье, что вообще такие статьи есть. Я просто по роду профессиональной деятельности занимаюсь тестированием, вот и решил поделиться мыслями в тему. Вдруг кому-то пригодится. Бывает так, у тебя есть какие-то убеждения, но их никто не разделяет. А так раз, прочтешь комментарий на хабре и на душе легче — значит все-таки ты не сумасшедший :)
Если дело касается бизнеса, то можно писать программы так, чтобы они самодиагностировались на наличие противоречий
habr.com/ru/post/342302
habr.com/ru/post/342302
Программы для снятия скриншотов
На macOS удобнее всего использовать встроенный инструмент создания скриншотов:
- Нажать ⌘⇧4
- Выделить нужную область экрана
- В нижнем правом углу экрана появится сделанный скриншот, нажать на него
- Нарисовать от руки нужные пометки
Либо сохранить скриншот как файл:
- Нажать Done
Либо скопировать в буфер обмена (многие сайты позволяют вставлять изображение из буфера обмена):
- Сбросить выделение пометки
- Нажать ⌘C
- Нажать иконку мусорки
Видео можно записать, нажав комбинацию клавиш ⌘⇧5.
Описанный автором подход верен, но крайне трудозатратен. С практической точки зрения баги делятся на 2 типа:
1. «Найди на картинке слона», когда слон красный на зелёном фоне, по центру и занимает 3/4 экрана (баг существует, воспроизводится всегда) — таким багам не нужно всё то детальное описание, которое просит автор, если его писать и читать — мы просто потратим время зря.
2. «Найди на картинке кота» — вот как в статье. Можно потребовать детально, статьей на 5 абзацов описать местоположение кота, его породу и родословную до 5-го колена. Или можно одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию.
В общем, коммуникации в команде рулят.
1. «Найди на картинке слона», когда слон красный на зелёном фоне, по центру и занимает 3/4 экрана (баг существует, воспроизводится всегда) — таким багам не нужно всё то детальное описание, которое просит автор, если его писать и читать — мы просто потратим время зря.
2. «Найди на картинке кота» — вот как в статье. Можно потребовать детально, статьей на 5 абзацов описать местоположение кота, его породу и родословную до 5-го колена. Или можно одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию.
В общем, коммуникации в команде рулят.
>о одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию
Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Даже во время внутренней дискуссии мне писали про это сразу несколько человек :)
А ещё бывает, что его за эти две недели пофиксил кто-то другой, как сайд эффект от починки другой проблемы / рефакторинга / нечаянно.
Но — да, аргументы в пользу быстрой коммуникации и мгновенного фикса тоже были.
Просто не всегда получается.
Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Даже во время внутренней дискуссии мне писали про это сразу несколько человек :)
Практика “Заведи на меня (заведу на себя) карточку в трелло с описанием проблемы без детального описания (ведь мы же оба будем ‘помнить’ о чем она, когда до нее руки дойдут)” так же очень порочна и должна пресекаться при первых же мыслях о ней.
В терминах Андрея оба участника на момент записи карточки знают где сейчас кот, а спустя время как правило забывают даже кого искать — кота или собаку.
Про заведение уже согласованных багов
Да, я не сказал сразу, что баги хорошо бы сначала проговаривать с человеком в теме.
Но:
баг будут читать и другие люди. Списки багов просматривает потом зачастую весь сквад, включая разработчиков, суппортёров и техрайтеров
И каждый из них будет искать кота, потому что с одним каким-то человеком решили, что он поймёт и так.
даже этот понимающий человек через месяц тоже не вспомнит (Станислав меня опередил на минуту, чорт.)
Я бы от себя ещё добавил, что проблемы желательно описывать так, чтобы ты сам через месяц мог понять, что там в баге написано, когда детали забудешь
А ещё бывает, что его за эти две недели пофиксил кто-то другой, как сайд эффект от починки другой проблемы / рефакторинга / нечаянно.
Могу дополнить. Очень часто приходится не только “искать кота на картинке” но и проверять что “кота на картинке больше нет”. И в этом случае steps to reproduce и expected results вдвойне полезны.
Но — да, аргументы в пользу быстрой коммуникации и мгновенного фикса тоже были.
Именно поэтому баг лучше всего фиксить сразу. Кроме теории разбитых окон, которая тоже важна, здесь простая экономика.
В этом треде описывается как лучше всего зафиксировать понимание сути бага на потом. Но имея это понимание и разработчика, способного пофиксить этот баг, или хотя бы написать юнит тест, воспроизводящий его, фикс может занять меньше времени и энергии, чем запись этого бага.
Важно помнить что результатом всего процесса является отсутствие бага. А не скриншоты, тексты и примеры. Поэтому, я считаю, важно пытаться перед записью бага поговорить с разработчиком, и возможно, сразу пофиксить его.
Просто не всегда получается.
Быстрая коммуникация нужна именно для решения фиксить баг сразу или описывать. Если разработчик сразу понял о чём речь и может пофиксить это здесь и сейчас — отлично, мы сэкономили кучу времени тестировщика и разработчика. Если баг непонятен или не приоритетен — может быть принято решение о его детальном описании.
Разработчик в момент нахождения бага может быть занят (и он почти наверняка будет занят). А когда он доберется до собственно бага занят чем-то другим будет уже тестировщик, у него вряд ли есть время сидеть и ждать пока до его очередного бага доберутся ответственные за фичу люди. И когда тебе в середине очередного поиска прилетает приглашение в видео чат, то цензурные слова для такого человека находятся далеко не сразу. Тестировщик это не бездельник который всегда готов потрындеть об очередном баге и у него тоже вполне себе бывает состояние потока. Видеочаты без предварительной договоренности — зло.
Я в курсе о проблеме входа в поток и переключения контекстов внимания. Но тут же чистая математика: если мне для входа в поток надо 15 минут, а для полного описания и изучения багрепорта мне и тестировщику нужно по 20 минут, то лучше вырваться из потока, 25 минут экономии. Плюс в половине случаев баг будет исправлен «здесь и сейчас», а не отложен на неделю.
Хорошо если у вас эта математика работает, без сарказма. Если меня в определенные моменты выбить из такого потока, то я могу потом полдня назад на работу настраиваться. И я совсем не уверен чей случай правильнее считать за правило. Обычно считается что программистов отвлекать не стоит — я придерживаюсь аналогичного правила для тестировщиков. Тем более что если я сам к программисту не пришел сразу после нахождения бага (лично или в чате, неважно), то скорее всего это не продакшн упал, а какая-то проблема которую совершенно необязательно решать вот прямо сейчас, большинство таких проблем великолепно подождут до следующей недели, где их решение будет запланировано и не пойдет в ущерб ничему из текущих планов. Вообще, по моему опыту, половина случаев сдвигания сроков готовности чего бы то ни было происходит в основном из-за попыток решения проблем в неподходящее для этого время.
Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Ну что-что… помочь тестировщику (если это был он) составить багрепорт или составить его самому. В тех терминах, которые понятны тем, кто будет багу править.
Не в виде: «Я что-то нажал и все сломалось», а «При открытом модальном окне приветствия я нажал F1 и в форме исчезли ОК и крестик закрытия».
А дальше очевидно.
Плюс находясь в контексте бага на машине, где он воспроизвелся, бывает достаточно кликнуть пару кнопок, посмотреть пару файлов и становится понятно, что сломалось. Тестировщик не знает, куда смотреть, а разработчику потом, возможно, нужно будет долго воспроизводить окружение и шаги по воспроизведению.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Итак:
Вы забыли с самого начала добавить пункт «объяснить контекст».
То, что вам кажется очевидным, программисту/менеджеру/Сотоне может быть вообще неочевидно, даже несмотря на детальные полотна Рембрандта в разделе «2) Шаги для воспроизведения».
1) Ключевые слова в заголовке бага
2) Шаги для воспроизведения
3) «ожидаемое поведение» vs «наблюдаемое поведение»
4) Скриншот
5) Видео
6) Стэк трейс / ошибки в консоли при явном эксепшене
7) Пример для воспроизведения.
На этом в первом приближении всё.
Вы забыли с самого начала добавить пункт «объяснить контекст».
То, что вам кажется очевидным, программисту/менеджеру/Сотоне может быть вообще неочевидно, даже несмотря на детальные полотна Рембрандта в разделе «2) Шаги для воспроизведения».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О записи багов, или Найди кота