Эта статья родилась из поста на внутреннем форуме нашей конторы, немножко пообсуждалась, слегка дополнилась, а потом я решил выложить её в итоговом виде тут, чтобы ссылаться было удобнее.
Да, пост капитанский, это ожидаемое поведение :) я просто хочу это иметь собранным, упорядоченным и общедоступным.
Введение: найди кота
В продуктах, которые мы разрабатываем, есть баги.
Мы их иногда находим. Иногда даже записываем.
Для того, чтобы помочь нашим коллегам, сделать их продукт лучше.
И очень обижаемся, когда коллеги нам пишут – "я нихрена не понял", "у меня не воспроизводится", "приди покажи".
Иногда так говорю я.
Потому что достаточно часто баги выглядят как картинка "найди кота".
Тот, кто записал баг, точно знает, где кот. Он его уже нашёл. Он уже не может его развидеть.
А я должен сидеть, пыриться в монитор и искать грёбаного кота.
Часто к багу прикладывают видео. Ведь на видео всё видно!
Там всё то же самое, только ещё травка колышется (двигается мышка) и ворота открываются (открывают не относящиеся к делу диалоги).
В этот момент я рассказываю о правилах записи багов, которым я стараюсь следовать для себя, и которые рекомендую другим.
Мои личные правила записи багов
1) Ключевые слова в заголовке бага
Чтобы можно было быстро понять, к чьей области компетенции относится баг.
2) Шаги для воспроизведения
И это очень очень важно. И да, их составление занимает самую большую часть времени при записи.
Потому что достаточно часто, начиная, записывать шаги и выкидывая "лишние", ты понимаешь, что баг воспроизводится совсем не всегда.
3) «ожидаемое поведение» vs «наблюдаемое поведение» в тех шагах, где, собственно, баг.
Это критично. Потому что не всегда то, что человек ожидает увидеть, соответствует тому, как оно есть на самом деле. Тогда искать кота можно бесконечно.
4) Скриншоты – это хорошо
Картинки дают визуальный контекст, показывают разработчику части продукта с проблемами, и он сразу понимет необходимую область знаний. Картинка в этом плане работает в паре с ключевыми словами (см. п. 1)
5) Видео – это хорошо, но только когда показываем баг на анимацию
И – видео это то, с чем можно в принципе жить, когда автор бага не может написать шаги для воспроизведения.
Или ошибка недетерминированная, и нужны доказательства.
В остальных случаях видео избыточно.
Видео для бага должно быть для бага. Длиной секунд 10, без открытия левых окон.
6) Стэк трейс / ошибки в консоли при явном эксепшене
Ну, это и так почти все понимают и прикладывают, пишу только для завершённости списка.
7) Пример для воспроизведения.
Если мы говорим о какой-то десктоп системе — то нужен архив, на котором воспроизводится проблема.
В вебе проще — часто можно дать ссылку на онлайн-демку (или на развёрнутый staging environment).
На этом в первом приближении всё.
Я делюсь этим с другими людьми – и часто они мне верят и начинают делать так же.
Дальше примеры и 20% деталей, которые занимают 80% статьи :)
Примеры
Пример бага – как я их записываю, и который более-менее :)
dxTreeView creates redundant loading indicators in Virtual mode
- Open http://js.devexpress.com/Demos/WidgetsGallery/#demo/navigation-tree_view-virtual_mode
- Navigate to the leaf nodes using double clicks
- Double-click on leaf nodes multiple times
- expected results: nothing happens
- actual results: a loading indicator is created on every double click and never removed
- Web Dashboard – The Reset and Submit buttons disappear in the Parameter custom item after submitting the parameter value
To reproduce the issue, run the attached project, change the parameter value in the Parameter custom item and click the Submit button.
Actual Result: The Reset and Submit buttons disappear.
Expected Result: The Reset and Submit buttons should be shown.
- Web Dashboard Viewer – Toolbar buttons are shown when any part of the control is clicked on a touch-enabled monitor and item captions are hidden
Run the project and click any part of the viewer to reproduce the issue.
Actual Result: Toolbar buttons are shown.
Expected Result: Toolbar buttons should be shown only when hovering over them.
As a workaround, execute the following (internal) code in the OnInit event handler:
function onInit(s, e) { DevExpress.Dashboard.Internal.DashboardLayoutModeHelper.isTouch = false; }
- ASPxDashboardViewer/MVCxDashboardViewer- An exception is raised if you open dashboards with tabs (тут нет expected, но он очевиден из тайтла бага. Такое бывает, ладно.)
The old ASPxDashboardViewer control and the MVCxDashboardViewer extension do not support the Tab container dashboard item as compared to ASPxDashboard / MVCxDashboard. When ASPxDashboardViewer / MVCxDashboardViewer opens a dashboard with a tab container, a client-side exception occurs. It is necessary to show the corresponding pop-up message in a dashboard UI instead.
- Dashboard Web – Binding panel remains transparent in certain cases (тут видео, потому что тут реально поганый баг, мы его полтора года пытались поймать)
Steps to reproduce:
- Create dashboard with an item. Make sure that binding panel will overlap the item when opened.
- Select the item.
- Open the binding panel (e.g. click on the 'Options' button) and move a cursor over the panel to the moment when the cursor placed over the item. Binding panel become transparent (expected)
- Click on the dashboard item. Binding panel closed.
- Click 'Options' button again.
Actual result:
Binding panel is transparent.
Expected result:
Binding panel is not transparent.
The main step is to close the binding panel by clicking to the item while is is transparent.
Screencast is attached.
- Web Dashboard – Fullscreen item — Pivot operates incorrectly in the maximized state
- Open the RevenueAnalysis demo.
- Expand the Pivot's "Bikes" column.
- Collapse the Pivot's "Bikes" column.
- Maximize the Pivot dashboard item.
Expected result: The Pivot's "Bikes" column should be collapsed in the maximized state.
Result: The Pivot's "Bikes" column is expanded in the maximized item.
- Chart's tooltip can be clipped if a custom container is used
Steps to reproduce:
- Use the chart's container as the tooltip container;
- Show a tooltip on some points close to the edge of the chart;
- WRONG. The tooltip is shown outside the container or can be clipped depending on the container's overflow setting.
EXPECTED. The tooltip should be shown inside its container until it fits container size.
И др.
Философствования и мелкие определяющие детали
Подготовка скриншотов
Картинки должны быть с большими красными стрелками или даже с подписями.
Скриншот должен быть частью тела бага, прямо в тексте.
Если баг репортится в большинство современных систем — то это делается просто вставкой картинки из буфера обмена по Ctrl + V
Почему нельзя просто дать ссылку на картинку? Потому что происходит потеря контекста. Если ты смотришь на картинку, ты не видишь текст. Если ты видишь текст, то ты не видишь картинку. Если ты видишь и то и то — вероятность, что в мозгу что-то щёлкнет, значительно выше.
Минутка профессиональной деформации
Именно поэтому становятся популярны дашбоарды как явление анализа данных :)
Когда человек видит одни и те же данные в разных форматах и с разных углов, к нему может прийти озарение (insight).
Подробности см. у Стивена Фью и других авторов.
Размер скриншота – всегда компромисс.
Когда маленький, проблему лучше видно, и места занимает мало. Но не всегда ясно, откуда вообще этот кусок взят.
Захватили область экрана чуть побольше – влезают посторонние детали. Экран, с которого открыли попап, на котором ошибка. Браузер, в котором ошибка. Кнопка пуск той винды, на которой ошибка. DPI того монитора, на котором ошибка… ой, а самой ошибки-то уже и не видно. Кот стал двухпиксельным и неопределимым даже внутри красного кружка.
Где остановиться, обрезая скриншот – это всегда искусство )
Примеры скриншотов, от малого к большому:
багрепорт в УК, перила сломались
Проблема хорошо видна, но контекст потерян. Если б не было надписи словами, что это около парадного входа, сварщик ходил бы в маске по участку, искал бы.
в личном общении, вопрос про реализацию TreeView
Показано, какой элемент я имею в виду (плюсик… ну, идите переведите extend button лучше :)), виден контекст (экран нового визарда)
- Проблема с маштабированием демок дашбоардов на DPI=125%
Видно, что это за браузер и URL сайта
Замазаны ненужны вкладки, чтобы не отвлекать. Оставлена статья про Windows 10 Creators Update (в котором 125% DPI и стал дефолтом на ноутбуках 15,6?), чтобы я, глядя на этот скриншот, вспомнил об этом и смог выпендриться и про это рассказать.
Давайте ещё раз подчеркнём. При нормальных инструментах, время подготовки каждого из этих скриншотов составляет от 5 до 30 секунд.
Это не плод долгой художественной работы. Это быстро и эффективно. Можно упороться и довести каджый из них до совершенства… но как правило это не требуется.
Программы для снятия скриншотов
- Яндекс.Диск я вот нежно люблю его скриншотилку. Ну вот так вот. Она почему-то оказалась лучшим из того, что я пробовал, чтобы делать стрелочки, обводить кружочком-квадратиком и добавлять читатабельные надписи. На ней сделаны все примеры из статьи.
- Monosnap (бесплатная, с платным планом). В принципе очень ничего, но (субъективизм!) стрелочки страшненькие;
- ShareX (совсем бесплатная);
- Jing широко использовался нашими инженерами техподдержки; потихоньку уходит, потому что пишет видео в богомерзкий флэш.
- В Windows 10 — встроенный по сочетанию Win+Shift+S # Комментарий автора: действительно вполне неплохо
- встроенный скриншотер на Mac #,
- GreenShot — Win #, #
- LightShot — Mac/Win #
- FastStone Capture #
- FlameShot (Linux, на гитхабе обсуждают возможность Windows) #
- Snipping Tool — встроен в Windows #
- gooncam #
- PicPick (Windows) #
- Spectacle & KSnapshot (Linux) #
- Problem Steps Recorder — встроен в Windows, запускается по PSR из командной строки #
Записываем проблему, а не решение
Этот пункт возник в результате внутренней дискуссии. Очень неожиданно он оказался не всем ясен, поэтому – пример.
Вот например тестирую я дашбоард дизайнер и вижу такую штуку:
И пишу баг:
"Отсутствует горизонтальный скролл"
Могу даже написать его с шагами и ожидаемым результатом :smiley:
Ожидаемый результат: название правила должно скроллироваться горизонтально
реальный результат: название правила не скроллируется
Баг оформлен нормально, но это не помешает разработчику посчитать меня дебилом. И он окажется прав :)
Есть проблемы: "текст не виден целиком; текст накладывается на иконку"
Но вместо записи этой проблемы я записал своё решение этой проблемы. Одно из многих, и точно не самое лучшее.
И вот такая подмена происходит не сказать чтобы редко. Даже себя я иногда ловлю на этом.
Ведь я-то знаю точно, как надо фиксить. А значит, так и напишу!
(ну, иногда действительно знаю. И стараюсь писать свои предложения в теле бага, после собственно описания проблемы. Но не как единственное возможное решение)
Про пример для воспроизведения
В desktop-разработке этот пункт является дискуссионным. С одной стороны, полезность выполняющегося примера кода, воспроизводящего проблему, всем понятна.
С другой, создание примера уже значительно увеличивает срок записи бага, до порядка.
В общем, в моей голове так: для сложных случаев это обязательно, в простых случаях — может быть избыточным.
Меня в универе учили, что если система безопасности становится слишком сложной и приносит вред и неудобства, то ей просто перестают пользоваться.
Если на каждый баг обязать делать пример — то через месяц забьют даже на примеры для сложных багов )
С другой стороны, на простых багах можно тренироваться делать примеры…
Короче, вопрос дискуссионный.
Сюда же в копилку добавлю десятилетней давности статью CTO нашей конторы, где он объясняет, почему мы наших кастомеров просим о примерах.
A request for simple example programs 10 by Julian
А ещё есть такой момент с упрощёнными примерами, цитата:
Сильно упрощенный пример это конечно хорошо, но и плохо. Неоднократно были случаи, что упрощенный пример:
– не покрывает всех сценариев проявления бага;
– не отражает реального сценария, что может привести к неподходящему решению.
В идеале лучше иметь и упрощенный и исходный сэмпл.
Теперь вы знаете, что:
- подготовливать примеры – очень полезно;
- это сложно;
- главное, не переборщить.
Время записи бага
Получилось очень много букв. Может показаться сложной, долгой и нудной бюрократической процедурой.
Так вот, это не должно быть сложно и долго.
Медиана времени записи бага, удовлетворяющего портянке требований выше – около минуты.
Дааа, в тех случаях, когда оказывается, что шаги-то не воспроизводят баг; или что они не все важны, и захотелось убрать лишнее; или в процессе вскрылся новый шаг — тогда время увеличивается.
Зато верояность, что ваш баг пофиксят, а не закроют с комментом "can not be reproduced", значительно растёт.
Оппозиция
Что мне говорят, когда я делюсь своим видением:
баг же очевиден
Он очевиден тому, кто уже нашёл кота.
Без подробного описания и шагов всем остальным придётся его искать. Недетерминированное время.
Да, моя жена и VYudachev нашли кота в первые три секунды. Двое из моей выборки.
А остальные люди (примерно с десяток), в мониторы которых я подглядывал, искали кота до пяти минут.
А я в общем-то плюнул и сразу открыл отгадку.
И с плохо записанными багами то же самое.
видео достаточно, там всё видно
Во-первых, для читающего баг это долго. Намного дольше, чем прочитать список шагов, просканировать его на ключевые слова.
Во-вторых, чтобы выяснить мельчайшие детали, нужно его пересматривать по многу раз, пытаясь остановить, поймать паузу именно на критичных моментах.
В-третьих, часто на плохо подготовленных видео очень много лишних деталей. И ты не знаешь, что из этого вправду лишнее, а что нет. Необходимо ли для воспроизводимости бага закрывать нотификацию из вконтакта?.. Нет ли там взаимодействия с операционной системой, которое и вызвало баг отрисовки?.. Можно ли вместо вконтакта использовать телеграмм?...
(Справедливости ради, бывало в моей практике, что на прикреплённом видео автор функционала находил другие баги)
записывать так баги очень долго
Записать баг с шагами занимает больше времени, это правда.
Зачастую оттого, что, записывая точные шаги, невольно начинаешь выполнять работы по отладке.
Пробуешь, можешь ли выкинуть какой-то шаг, или же он является критичным.
Да, этим ты тратишь своё время и экономишь чужое.
Список литературы
Список требований к записи багов родился у меня на основе:
- Bug report writing guidelines (Mozilla); (по этой ссылке на форуме было очень мало переходов, а зря, отличная статья :) );
- How To Ask Questions The Smart Way 10. Эту статью коллега подкинул как коммент к первому варианту, прочёл с удовольствием:
если выкинуть форумно-мэйллистовую-опенсорсную специфику, то ценно почти всё. Включая мои любимые “Describe the problem’s symptoms, not your guesses” и “Be explicit about your question”;
- и туда же от Stack Overflow – How do I ask a good Questions;
- опыта интернета;
- личного опыта и многолетней боли.
Конец
Этим своим мнением по поводу записи багов я делился со своими командами. Сейчас решил выйти уже на более широкую аудиторию.
Спасибо дочитавшим.
Вот тут отгадка картинки с котом (взято тут).
Кстати, картинка не моя, но подготовлена неплохо – есть стрелка, и есть увеличение области с багом котом.
UPD 28.06.2019
Программы-скриншотилки из комментариев добавлены в общий список
Исправлены опечатки, даже вызвавшие дискуссию в комментах
Комментарии (93)
Sky3d
25.06.2019 10:54+2Программы для снятия скриншотов
Из личных предпочтений я бы добавил GreenShot (бесплатный под вин) и LightShort если у вы работаете на маке или винде (хотя он полайтовее)
perfect_genius
25.06.2019 15:55+1FastStone Capture тоже на их уровне, судя по скриншотам. Все у всех всё своровали.
saboteur_kiev
26.06.2019 13:22Встроенный Snipping Tool в винде часто просто достаточен.
Вырезать, обвести, нарисовать стрелку — все есть, бесплатно, уже установлено, доступно в самой анально огороженной политиками организации.
GennPen
25.06.2019 11:10Проблема описания багов относится не только к программированию, а и ко всем отраслям по ремонту.
Когда работал по ремонту техники (телефоны, планшеты, ноутбуки), то очень часто приносили с неисправностью «глючит» и приходилось часто искать котов. На приемке строго запретил принимать в ремонт с неисправностями типа: «глючит», «тупит», «плохо работает» и т.п., только с явным описанием проблемы, поиск котов резко сократился.
(на картинке кота нашел без подсказки =) )kaatula Автор
25.06.2019 11:35Ну вот я пытаюсь так даже в управляющую компанию так заявки оставлять на ремонт оборудования нашего дома, иногда помогает )
iago
25.06.2019 11:18Всем тестировщикам в уши. А то после одного тестировщика бэклог полон багов, которые непонятно как непонятно где воспроизвести, а у другого спрашиваешь — ты видел этот краш?, а он отвечает — да, но не заносил как баг потому что еще не нашел четкие степы.
Сразу видно, что вы — хороший тестировщик.kaatula Автор
25.06.2019 11:36Спасибо!
Строго говоря, тестировщиком я никогда не был, я был программистом ) Потом был тимлидом, доносящим обшибки до своей команды ) и прочувствовал в общем-то с обеих сторон, да.
iago
25.06.2019 11:24+1По поводу видео только для анимаций поспорю — нет, нет и еще раз нет. Очень часто и только на видео я замечаю множество аспектов, которые можно пропустить в степах. Например, на телефоне выбран 3g, а данный вид групповых чатов работает только на wi-fi. Я вижу iPhoneX, на котором данные заехали под монобровь, а у меня в распоряжении только iPhone 7. И еще множество нюансов, которые тестировщик от лени, от неведения, от ужасного владения английским может не указать, видно на видео.
В остальном я категорически согласен со всем, особенно с тем что нужно выкидывать лишние степы и перевоспроизводить баг несколько раз. Уж сколько было от разных тестировщиков «от бога» баг содержания «вот иногда крашится когда заходишь на эту вьюшку, не всегда воспроизводится», а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?kaatula Автор
25.06.2019 11:40Ну, да, бывали случаи, когда видео оказывалось прям полезно-полезно-полезно. То есть если бы не оно, то и фикса могло бы не быть, потому что проблема оказалось бы не понятной в принципе.
Но это всё же от бедности )
Ну и для себя вывел, что если вот так благодаря видео пришло таки озарение — то надо его хотя бы самому в комментах к багу записать. Чтобы все будущие читатели были благодарны.
Нам приходят баги не только внутренние, но и от наших кастомеров. И вот там мы взяли себе за правило дополнять баг необходимой технической информацией в приватных комментарих.
Am0ralist
25.06.2019 11:47а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?
Эм, ну да, правильно. Ведь лучше все юзеры страдают, потому что четко воспроизвести баг не всегда возможно, а девелопер, написавший данный код, ни в чем не виноват?Am0ralist
25.06.2019 20:49То есть в этой теме люди серьезно считают, что репотить о багах, которые не имеют четкого воспроизведения не надо, потому что программист такой хороший работает, а его отвлекают по ерунде и заставляют, такие нехорошие люди, баги в старом коде править вместо написания новых?
И пофиг, например, что благодаря этому пациенту будет выдан не верный результат анализа, из-за чего врач не верно может продиагностировать оного и назначит не верное лечение? Потому что баг, оказывается, завязан не на последовательность действий человека, а на криво написанный запрос к базе данных, который зависит от положения марса в раке. Потому что половине случаев именно так можно описать те ошибки, которые программист находил по нашим багам «иногда случается фигня», когда врачи прибегали к нам и показывали неверный результат в системе.
И да, пару таких багов наш программист уже полгода отловить не может, исправив по пути десятки других мест.kaatula Автор
25.06.2019 23:04+1Это противопоставление неверно. Как мне недавно подсказали, оно называется теоремой Эскобара. Ссылку давать не буду, потому что она сформулирована в обсценённой лексике, но она хорошо гуглится )
Вы подменяете тезис о том, что баг должен быть записан хорошо, тезисом о том, что баг должен быть записан только с шагами и никак иначе.
В описанной ситуации, когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
И логи должны быть, да. Обычно после таких невоспроизводимых багов и добавляются на продакшене новые логи.Am0ralist
26.06.2019 08:03Уж сколько было от разных тестировщиков «от бога» баг содержания «вот иногда крашится когда заходишь на эту вьюшку, не всегда воспроизводится», а на деле оказывается там специфическая платежная система, на экран нужно вернуться второй раз и по кнопке успеть кликнуть очень быстро. Почему девелопер должен гадать вместо того, чтобы заниматься своей работой?
знаете, мне тут стока минусов в карму понапихали, что мне стало интересно — где я что подменил? вот, перечитываю исходное сообщение, на которое отвечал. и вижу ровно то, что описал — тестировщик должен поймать уникальную последовательность действий. а разраб, видите ли, мучается. то есть тестировщики то не мучаются искать такие последовательности? или они должны обладать даром предвидения?
поэтому подмену совершил не я.
когда баг пришёл с продакшена от нормальных людей, я бы спрашивал базу данных (то есть пример для воспроизведения).
в базе только результат. запросы в по забиты.mayorovp
26.06.2019 09:04то есть тестировщики то не мучаются искать такие последовательности?
У тестировщика это, как бы, должностная обязанность.
Am0ralist
26.06.2019 10:44А у программиста должностная обязанность писать корректный и рабочий код. Странно, почему тестировщики должны быть подобны богам и уметь находить любые последовательности, приводящие к ошибкам, а программисты писать без ошибок — не, не могут.
Ещё раз, не все баги четко привязаны к жесткой последовательности. Или последовательность действий — это десяток различных не связанных действий подряд. Или к действиям добавляется внешние факторы. Или это вообще зависит от того, что с прибора в этот момент пришли свои числа в базу, пользователь на другом компе сделал то-то, а на этом — то-то. И всё пошло не так, как надо. И кучу таких моментов можно понять только зная, как и что внутри крутится. Так что именно должен найти тестировщик в этом случае? Что программист даже с логами найти не мог неделю?
Вот у меня баг: тесты с одного отдела постоянно поступали с неверно оцененным вхождением в нормы. Во всех отделах нормально, а от них — как не норма шпарит числа в диапазоне нормы. В итоге это была связка с типом теста и какой-то обработкой тестов вообще для другого приложения печати результатов. И что я, как тестирующий и оформляющий баги мог там найти?
«Вот в этом месте у нас какая-то ошибка, воспроизвести лично не получается».Volodar
26.06.2019 14:05А у программиста должностная обязанность писать корректный и рабочий код
А у тестировщика находить все-все баги и ошибки программы тогда уж, не допуская их проявления в продакшине.
Все ошибки делают. И программисты баги допускают, и тестировщики ошибки пропускают. Это нормально.
Не нормально — это когда программист получил тикет и решил его не делать/делать не полностью. Также и тестировщик — если нашел ошибку, ее надо описать поймать и описать. У всех свои обязанности и все (надеюсь) их выполняют в меру своих возможностей.
vdem
25.06.2019 11:49На Upwork, когда попадается какой-то подходящий по скиллам мелкий проект, но заказчик предлагает посмотреть видео с описанием задачи, прохожу мимо. Лучше текстом объяснить что не так.
P.S. Голосовым или видеочатом вообще ненавижу пользоваться, такое тоже пропускаю. Пусть лучше заказчик текстом напишет задание, тогда уже не забудешь мелких деталей.kaatula Автор
25.06.2019 11:55Я их тоже голосовые сообщения терпеть не могу… но, кажется, нам придётся с ними жить
Я как раз на днях смотрел доклад c новосибирского КодФеста парня из ВКонтактика, ответственного за мессенджер. Он рассказывает, что голосовые сообщения в мессенджерах сейчас начинают побеждать текстовые.
Вот тут смотрел: www.youtube.com/watch?v=2LaP4pqTqGUvdem
25.06.2019 12:55Не-не-не, нередко даже носители англ. языка текст неграмотно пишут, а уж речь разобрать, со всем этим сленгом и разнообразием акцентов… Последний раз когда общался голосом — их двое было, к тому же еще и перебивали друг друга, я только через слово мог разбирать, что они говорят.
Arris
25.06.2019 12:39Текст длинный и запутанный. Выглядит как перевод. Все хорошо до примеров. Потом — плохо.
Но все равно за статью спасибо, кину коллегам.esaulenka
26.06.2019 09:04-1В вашем комментарии не хватает раздела «ожидаемое поведение».
Arris
26.06.2019 11:34Как скажете.
Не хватает примеров, вызывающих улыбку. Не скриншотов непонятно чего с непонятно какими багами, а примеров, где ошибка очевидна и понятна сразу. К такому примеру нужны подписи «Как багу отрепортили» и «Как багу должны были отрепортить».
mayorovp
25.06.2019 12:46Стэк трейс / ошибки в консоли при явном экспешене
Ну, это и так почти все понимают и прикладывают, пишу только для завершённости списка.Нет, это понимают не все. И, если упорядочить по важности, это должно идти первым пунктом, а не предпоследним! Очень часто для починки бага достаточно одного только стектрейса. Вот в тех случаях когда его уже не достаточно — тогда уже нужны шаги для воспроизведения, ожидаемое и наблюдаемое поведение, и прочие скришоты.
kaatula Автор
25.06.2019 13:11>Очень часто для починки бага достаточно одного только стектрейса.
Ну, это только в первые пять лет жизни продукта!.. :-D
Сарказм, но всё же: очевидные ошибки, которые воспроизводятся быстро, потому что они в основном функционале, ловятся быстро, в первые дни/недели после релиза нового функционала; и там, действительно, стектрейса хватает.
Но потом, когда функционал начинает жить своей жизнью, и пользователи нагибают его так, как автору и не снилось… вот там уже без шагов зачастую не разберёшься.
Если бы все программы были stateless — было бы проще, но увы :(
Valeratal
25.06.2019 13:36а «цветорые» это нормально? (баг с наложением стрелки на текст)
kaatula Автор
25.06.2019 15:19:) да, это пофикшено в версиях 19.1.4 и 18.2.9, как я только что убедился, проверив свой тикет.
Который, кстати, имеет ещё одну проблему, о которой я совсем забыл сказать. Я в одном багрепорте записал три разные проблемы (хоть все они и были связаны).
По хорошему, одна проблема — один багрепорт.RedTalon
25.06.2019 17:27И один мастер тикет на всех со ссылками на связаные проблемы.
kaatula Автор
25.06.2019 17:44А вот тут тоже вопрос дискуссионный
Мастер-тикеты уже начинают искажать статистику по количеству багов )
Да и вообще… так ли они нужны?
Нам последнее время, если встречаются связанные баги — что в общем-то происходит таки достаточно редко — хватает линкования peer-to-peer
В каждом из них в комментах проставляем ссылки.
Низкоорганизовано, ненормализованно… но в большинстве случаев — достаточно.dimm_ddr
26.06.2019 10:18А так ли нужна статистика по количеству багов? Я вроде уже не один год работаю тестировщиком, в том числе строю процессы, а не только тестирую таски, но я так и не смог придумать ни одной адекватной причины зачем нузна статистика по количеству багов. Ну кроме того что это успокаивает менеджера и он начинает считать что вы работаете а не дурака валяете.
А касательно мастер тикета — я как раз люблю записывать список багов в один тикет с которым потом ПМ с лидом разбираются — что фиксить, как и когда. Довольны все — мне приходится тратить меньше усилий на бюрократию вроде создания отдельных тасков, менеджеру и лиду проще понять объем работы и распланировать следующую итерацию.kaatula Автор
26.06.2019 14:38Статистика — ну, чтобы понять — вот тут мы работали полгода, и после этого накопилось просроченных багов
А вот тут мы полгода работали по-другому, и тогда завала багов не было
То есть это больше для последующего анализа, а не для тактических решений…dimm_ddr
26.06.2019 16:17Возможно мне не везло с проектами (или везло), но количество багов за первый квартал могло кардинально отличаться от количества багов за второй квартал независимо от того работали мы также или иначе. Просто потому что разные фичи пилятся в разный момент и имеют разные шансы быть забагованными. И это даже не начиная разговор о неопределенности понятия «баг».
Нет, я не говорю что вы что-то делаете неправильно, если для вас это работает — замечательно. Просто у меня ситуаций когда такой анализ мог бы сработать пока не возникало и мне было интересно как у вас получается эту метрику использовать.
RedTalon
26.06.2019 14:09Не столько дискуссионно, сколько кейсозависимо. Если связных проблем три штуки, то и смысла нет городить огород. А, если поломался условный BGP, и повылазили проблемы в десятках независимых систем, то смело линкуем их к одному единственному тикету.
kaatula Автор
26.06.2019 14:37Да, это уже другой кейс. Эти десять тикетов ведь не связаны — это суть один и тот же тикет.
В нашем багтрекере это зовётся «дупликатами». И — да, мы сразу все, кроме одного основного, закрываем, при этом автоматически подписывая авторов дубликатов на уведомления по основному тикету
gecube
25.06.2019 13:36Странно, что не упомянули
- встроенный скриншоттер в Маке. Он прекрасен (за одной небольшой деталью) и даже позволяет рисовать поверх скриншотов. P — PRODUCTIVITY
- под виндой — PicPick
- В линуксе — есть две альтернативы Spectacle & KSnapshot. Они ТОЛЬКО для снятия скринов и по умолчанию забиндены на PrntScrn.
Естественно, что продвинутые тулзы вроде Слака тоже помогают…
GennPen
25.06.2019 13:46под виндой — PicPick
В Windows 10 — встроенный по сочетанию Win+Shift+Skaatula Автор
25.06.2019 14:33Забавная штука.
Полноценную скриншотилку не заменит (нет стрелочек из коробки, нарисованное не является векторным — его править тяжело, нет текста)
Но на голой чужой машине — может быть очень даже ничего, спасибо
Am0ralist
25.06.2019 17:13Под виндой есть ножницы.
Но я предпочитаю gooncam для создания гифок, дабы последовательность была наглядно видна (с учетом, как программисты иногда не читают последовательность действий, делая как им показалось верно в данном случае, в итоге не получая ошибку)
Jokerzp
25.06.2019 16:16Под Linux мое сердце покорил flameshot.js.org
Минималистичный интерфейс, набор всех необходимых инструментов, возможность гибко выбирать куда сохранять получившийся скриншот (автоматически зааплоадить и получить ссылку, скопировать в буфер обмена, сохранить на диск).kaatula Автор
25.06.2019 17:47Я правильно понял по видео, что у них, грубо говоря, инлайн-редактирование скриншота прямо как будто бы до его снятия?
Выглядит и вправду забавно, доберусь дома до убунту — попробую.Jokerzp
25.06.2019 17:58Все верно, работает именно так. Выделяется область (либо фулл скрин), после чего можно выбрать необходимые действия из набора доступных функций. Можно добавить текст, заблурить, что-нибудь нарисовать и после этого сохранить/скопировать в буфер/зааплоаадить изображение.
Под Ubuntu использую уже больше года, безумно доволен.
nk11k
25.06.2019 14:31+1Странно, но почему-то никто не упомянул Joel Spolsky и его трактат «Painless Bug Tracking»: www.joelonsoftware.com/2000/11/08/painless-bug-tracking
Mikhael1979
25.06.2019 14:36В OS Windows есть встроенный инструмент «problem steps recorder». Запускается из коммандной строки алиасом PSR. Автоматом делает скрины с пометками, где какие действия совершались, позволяет вставлять текстовые комментарии. Результат сохраняет в виде архива с .mht файлом. В Win 7 уже точно есть.
Static_electro
25.06.2019 15:12Парочка приветов из геймдева :)
В крупных компаниях обычно очень серьезно к этому подходят, потому что время программистов, которые ищут котов вместо починки багов, дорогое. Когда прилетает тикет — к нему обычно есть и скриншоты, и видео, и трейсы, и текстовое описание, и точная версия билда… и все равно иногда не помогает ?\_(?)_/? потому что баги бывают хитросделанные.
А один мой хороший знакомый делал убер-фичу: в редакторе уровней один из объектов — это джира-тикет. Кликаешь на него — попадаешь в джиру, ну и в обратную сторону можно. Очень удобная штука.
maxkomp
25.06.2019 15:57+1Пока ехал в метро, читал статью со смартфона, и кота разглядеть не удалось. А когда глянул на ту же картинку на большом мониторе — нашел его сразу же.
По делу: В общем-то все правильно написано. Меня, как разработчика ПО, сильно раздражают багрепорты типа «программа г-но, ни хрена не работает».
Вообще-то тестировщику за то и зарплату платят, чтобы он баги не только находил, но и мог по человечески объяснить, как их воспроизвести. Обычно для этого достаточно написать несколько строк (типа: «если случайно ввести в поле ВЛАЖНОСТЬ значение больше 100%, то никаких предупреждений при вводе не выдается, а потом в процессе работы произойдет ошибка Float Point Error»).
Ну а дальше все зависит от того, что это за ошибка.
Иногда нужно приложить какой-нибудь файл, с комментарием. (Например, «этот файл конфигурации открывается и отображается правильно, но при попытке изменить любой параметр происходит ошибка Out Of Memory»).
Скриншот может быть совсем необязателен (достаточно сказать, что именно делается неправильно), но иногда бывает необходим (когда причина ошибки — банальное отсутствие в тестируемой системе какого-нибудь шрифта).
Правильный тестировщик не только подробно опишет ошибку, но и сможет подсказать разработчику направление поиска, уточнив какие-нибудь детали. (например, «Эта фигня начала происходить только на прошлой неделе в среду, когда у заказчика в цеху ремонт кровли начали. Возможно, как-то с этим связано, потому что до того все работало нормально»).
Потому что сбои софта не всегда оказываются вызваны ошибками программиста. (я недавно в комментариях на Хабре уже рассказывал про случай, когда множественные зависания программы были вызваны неправильным подключением компьютера к электросети.)
Но самое интересное начинается, когда в роди тестировщика выступает обычный пользователь, не имеющий специальной подготовки… Вот в этом случае возможны знатные казусы. Есть личный опыт, когда моя программа вполне нормально работала у всех, а «грохалась» только у одного единственного пользователя. Причем это проявлялось на разных компьютерах, но только у одного человека! Дело осложнялось тем, что он находился в другом городе, и просто так пронаблюдать за его действиями не удавалось. По его словам — «Я просто щелкаю мышой в этом окне и программа падает!» А все мои и не только мои попытки воспроизвести эту ошибку ни к чему такому не приводили. (как мы только не извращались с мышками разных моделей и разным числом кнопок). В конце концов оказалось, что этому человеку легко удавалось делать не просто щелчок мышкой, и даже не двойной, а пяти — восьми — десятикратный! А та программа управляла технологической установкой, и в ответ на щелчки мыши отправлялась серия команд различным исполнительным механизмам (в данном случае — всяким клапанам, задвижкам, вентилям, и пр. Команды отправлялись в определенной последовательности и с нужными задержками) Поступления такого количества событий технологическая установка не успевала «переварить», и все начинало работать совсем не так, как задумывалось.
Конечно, это был мой баг, который и был немедленно исправлен, как только проблема была осознана. А дело было в середине 90-х, когда и компьютеры были не такие шустрые, и до полезных инструментов (типа Problem Steps Recorder) еще не додумались. Поэтому осознал я эту проблему не сразу.
Portnov
25.06.2019 17:39+2Мы при виде видео в тикете обычно восклицаем: «ну вот, начинается: «следите за руками»!»
lxsmkv
25.06.2019 21:436) Стэк трейс / ошибки в консоли при явном экспешене
У меня предохранитель перегорел на последнем слове :)
И вот одно из моих правил: разработчикам без тебя неясности хватает, изьясняйся недвусмысленно, и точно.
В приведенной цитате: то ли это «экспектейшн» хотели написать, то ли «эксепшн», ведь ожидания тоже бывают явные и неявные. И уже лишние ватты разработчика тратятся не на решение проблемы, а на осмысление твоего небрежного наброска.
Ведь плох тот тестировщик который не хочет чтобы его тикет быстро решили. «Так что ж ты тогда, падла, даже шанса не оставляешь разработчику чтобы его решить» — думаю я, когда читаю некоторые «наброски».
И, следом, еще одно мое правило: по возможности без англицизмов и технических терминов. Тестировщик это в первую очередь пользователь. А раз пользователь вот и не вы*вайся. Пиши как маме.
Описание ошибки должно содержать кратчайший известный путь воспроизведения.
Да, это работа тестировщика найти этот путь. Да, это трудно и долго. Но это и есть тестирование. Вообще если ты не воспроизвел ошибку хотя бы еще раз, ее нельзя репортить.
В заголовке я пишу, что не так и при каком условии. Если насобачиться можно всегда уложиться в одно предложение. Например: «Профиль пользователя отображается неверно при возврате из меню настроек пользователя.» Описание не должно давать полной картины, но оно должно, при беглом прочтении, давать общее представление так чтобы можно было отличить этот тикет от другого, или упомянуть его в разговоре. Обратная проверка заголовка — если из него можно напрямую сформулировать запись в релизный журнал именений. Например: «Исправлена ошибка когда профиль пользователя в некоторых случаях отображался неверно».
Описанию ошибок меня научил один коллега, сам того не желая. Он был разработчиком трейс-монитора для нашей проги. И вот у меня этот трейс-монитор однажды перестал реагировать на ввод мыши. Я завел тикет, и написал, что у программы «фриз». Он пришел и сказал мне на повышенных тонах, что это не фриз. Оболочка не реагирует, но программа продолжает работать. А ушел сказав: «Просто пиши то что ты видишь, а не то что ты думаешь.»
С тех пор прошло пять лет, а это золотое правило я вспоминаю каждый раз по сей день когда вдруг сомневаюсь как описать ошибку. Просто пиши то, что видишь.
А это кстати совсем нетривиальная задача.
Ну и конечно при собеседовании тестировщика, я бы в первую очередь, проверял владение челвоеческим языком. Если человеку трудно изьясняться, (ну бывает такое, что слабое место) то ему нельзя быть тестировщиком.kaatula Автор
25.06.2019 23:15Я хотел написать «эксепшене»
В общем-то, мне про эту опечатку сказали несколько часов назад. Но я её предпочёл уже не править — времени после написания прошло много, и это слегка некорректно — править давно написанный текст без явных оповещений о том.
Что такой стэк трейс при ожиданиях — мне не совсем понятно, а оттого и суть двусмысленности мне не ясна.
Что же до англицизмом… что ж, меня тоже бомбит, когда англицизмы используют для имеющихся в русском языке понятий, вводя тем самым новые термины взамен русских устоявшихся.
Но в такой области языка, как разработка ПО…
> Последовательность вызов / ошибки в инструментах браузера при явном возникновении исключительной ситуации
Серьёзно? Стало понятнее? )
— Дальше довольно много претензий про то, что тестировщик должен и не должен.
Тут дело в том, что я не тестировщик, и писал не для тестировщиков. Я писал для разработчиков ПО, техрайтеров… для всех своих коллег.
Конечно, некоторые из них могут стать в определённый момент работы тестировщиками, и это будет хорошо.
— >Просто пиши то что ты видишь, а не то что ты думаешь
Это хорошее дополнение, спасибо за него.lxsmkv
26.06.2019 01:24Вспомнил, полностью фраза звучала так: «пиши что ты делаешь и что видишь, а не то что ты думаешь ты видишь».
довольно много претензий про то
Боже упаси, какие претензии, счастье, что вообще такие статьи есть. Я просто по роду профессиональной деятельности занимаюсь тестированием, вот и решил поделиться мыслями в тему. Вдруг кому-то пригодится. Бывает так, у тебя есть какие-то убеждения, но их никто не разделяет. А так раз, прочтешь комментарий на хабре и на душе легче — значит все-таки ты не сумасшедший :)
dim2r
26.06.2019 10:38Если дело касается бизнеса, то можно писать программы так, чтобы они самодиагностировались на наличие противоречий
habr.com/ru/post/342302
Finesse
26.06.2019 10:52Программы для снятия скриншотов
На macOS удобнее всего использовать встроенный инструмент создания скриншотов:
- Нажать ??4
- Выделить нужную область экрана
- В нижнем правом углу экрана появится сделанный скриншот, нажать на него
- Нарисовать от руки нужные пометки
Либо сохранить скриншот как файл:
- Нажать Done
Либо скопировать в буфер обмена (многие сайты позволяют вставлять изображение из буфера обмена):
- Сбросить выделение пометки
- Нажать ?C
- Нажать иконку мусорки
Видео можно записать, нажав комбинацию клавиш ??5.
tangro
26.06.2019 11:03Описанный автором подход верен, но крайне трудозатратен. С практической точки зрения баги делятся на 2 типа:
1. «Найди на картинке слона», когда слон красный на зелёном фоне, по центру и занимает 3/4 экрана (баг существует, воспроизводится всегда) — таким багам не нужно всё то детальное описание, которое просит автор, если его писать и читать — мы просто потратим время зря.
2. «Найди на картинке кота» — вот как в статье. Можно потребовать детально, статьей на 5 абзацов описать местоположение кота, его породу и родословную до 5-го колена. Или можно одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию.
В общем, коммуникации в команде рулят.kaatula Автор
26.06.2019 11:20>о одник кликом открыть видеочат с тестировщиком, сказать голосом «так, покажи мне этого кота» и, потратив по 3 секунды времени разработчика и тестировщика получить всю ту же информацию
Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Даже во время внутренней дискуссии мне писали про это сразу несколько человек :)
Практика “Заведи на меня (заведу на себя) карточку в трелло с описанием проблемы без детального описания (ведь мы же оба будем ‘помнить’ о чем она, когда до нее руки дойдут)” так же очень порочна и должна пресекаться при первых же мыслях о ней.
В терминах Андрея оба участника на момент записи карточки знают где сейчас кот, а спустя время как правило забывают даже кого искать — кота или собаку.
Про заведение уже согласованных багов
Да, я не сказал сразу, что баги хорошо бы сначала проговаривать с человеком в теме.
Но:
баг будут читать и другие люди. Списки багов просматривает потом зачастую весь сквад, включая разработчиков, суппортёров и техрайтеров
И каждый из них будет искать кота, потому что с одним каким-то человеком решили, что он поймёт и так.
даже этот понимающий человек через месяц тоже не вспомнит (Станислав меня опередил на минуту, чорт.)
Я бы от себя ещё добавил, что проблемы желательно описывать так, чтобы ты сам через месяц мог понять, что там в баге написано, когда детали забудешь
А ещё бывает, что его за эти две недели пофиксил кто-то другой, как сайд эффект от починки другой проблемы / рефакторинга / нечаянно.
Могу дополнить. Очень часто приходится не только “искать кота на картинке” но и проверять что “кота на картинке больше нет”. И в этом случае steps to reproduce и expected results вдвойне полезны.
Но — да, аргументы в пользу быстрой коммуникации и мгновенного фикса тоже были.
Именно поэтому баг лучше всего фиксить сразу. Кроме теории разбитых окон, которая тоже важна, здесь простая экономика.
В этом треде описывается как лучше всего зафиксировать понимание сути бага на потом. Но имея это понимание и разработчика, способного пофиксить этот баг, или хотя бы написать юнит тест, воспроизводящий его, фикс может занять меньше времени и энергии, чем запись этого бага.
Важно помнить что результатом всего процесса является отсутствие бага. А не скриншоты, тексты и примеры. Поэтому, я считаю, важно пытаться перед записью бага поговорить с разработчиком, и возможно, сразу пофиксить его.
Просто не всегда получается.tangro
26.06.2019 11:38Быстрая коммуникация нужна именно для решения фиксить баг сразу или описывать. Если разработчик сразу понял о чём речь и может пофиксить это здесь и сейчас — отлично, мы сэкономили кучу времени тестировщика и разработчика. Если баг непонятен или не приоритетен — может быть принято решение о его детальном описании.
dimm_ddr
26.06.2019 13:40Разработчик в момент нахождения бага может быть занят (и он почти наверняка будет занят). А когда он доберется до собственно бага занят чем-то другим будет уже тестировщик, у него вряд ли есть время сидеть и ждать пока до его очередного бага доберутся ответственные за фичу люди. И когда тебе в середине очередного поиска прилетает приглашение в видео чат, то цензурные слова для такого человека находятся далеко не сразу. Тестировщик это не бездельник который всегда готов потрындеть об очередном баге и у него тоже вполне себе бывает состояние потока. Видеочаты без предварительной договоренности — зло.
tangro
26.06.2019 15:21Я в курсе о проблеме входа в поток и переключения контекстов внимания. Но тут же чистая математика: если мне для входа в поток надо 15 минут, а для полного описания и изучения багрепорта мне и тестировщику нужно по 20 минут, то лучше вырваться из потока, 25 минут экономии. Плюс в половине случаев баг будет исправлен «здесь и сейчас», а не отложен на неделю.
dimm_ddr
26.06.2019 16:22Хорошо если у вас эта математика работает, без сарказма. Если меня в определенные моменты выбить из такого потока, то я могу потом полдня назад на работу настраиваться. И я совсем не уверен чей случай правильнее считать за правило. Обычно считается что программистов отвлекать не стоит — я придерживаюсь аналогичного правила для тестировщиков. Тем более что если я сам к программисту не пришел сразу после нахождения бага (лично или в чате, неважно), то скорее всего это не продакшн упал, а какая-то проблема которую совершенно необязательно решать вот прямо сейчас, большинство таких проблем великолепно подождут до следующей недели, где их решение будет запланировано и не пойдет в ущерб ничему из текущих планов. Вообще, по моему опыту, половина случаев сдвигания сроков готовности чего бы то ни было происходит в основном из-за попыток решения проблем в неподходящее для этого время.
Arris
26.06.2019 11:41Да, но что с ней делать потом?
Если у вас zero bugs, и вот именно сейчас других багов нет — чудесно! Баг будет прям сразу же и починен.
Но что если это случилось сразу перед/сразу после выпуска новой версии, и других багов висит навалом, с более высоким приоритетом?
И очередь фикса подойдёт только через две недели?
Ну что-что… помочь тестировщику (если это был он) составить багрепорт или составить его самому. В тех терминах, которые понятны тем, кто будет багу править.
Не в виде: «Я что-то нажал и все сломалось», а «При открытом модальном окне приветствия я нажал F1 и в форме исчезли ОК и крестик закрытия».
А дальше очевидно.tangro
26.06.2019 15:24Плюс находясь в контексте бага на машине, где он воспроизвелся, бывает достаточно кликнуть пару кнопок, посмотреть пару файлов и становится понятно, что сломалось. Тестировщик не знает, куда смотреть, а разработчику потом, возможно, нужно будет долго воспроизводить окружение и шаги по воспроизведению.
barsuksergey
26.06.2019 11:07+1Для тех, кому только кота.
GennPen
26.06.2019 12:08Для начала нужно понять: кот ли это на самом деле, или цветочки-трава так выстроились и мозг думает, что это кот. Нужна более детальная фотография этого места.
dimm_ddr
26.06.2019 13:42Необязательно. Нам же кот не нужен чтобы его кастрировать или покормить. Поэтому цветочки похожие на кота — тоже ответ на вопрос где же тут кот.
testopatolog
27.06.2019 23:19Кстати, про запись бага. Всегда есть выбор того, что важнее в данный момент при соответствующих условиях — клише или оптимальное для задействованных сторон содержание, стереотипное мышление или понимание «пульса, дыхания, с полуслова» работы системы и команды.
Говорят, что кот обязательно сам найдёт любящего и понимающего его хозяина — надеюсь, Вы видите, что я здесь не пытаюсь выдавать известные знания за свои новые мысли и идеи.
Arcuen
А кот-то где?
kaatula Автор
А вот кто дочитал статью до конца — тот нашёл ссылку!
dolovar
По ссылке «вот тут» находится картинка, где черным квадратом и красным кружком обведены области с белым цветком, который по форме напоминает нос кота. Кот по ссылке не найден.
EvilFox
Там ухо торчит.
dolovar
А второе ухо скрыто травинками, которые находятся позади головы? И всё тело до последней шерстинке скрыто в невысокой траве. Также обращает на себя внимание отсутствие глаз, которые должны были бы выделяться на фото. На многочисленных картинках типа «найди кота» зачастую именно глаза выдают зверька. Поэтому вполне можно предположить парейдолию.
Am0ralist
Это парейдолия смотрит на вас, как:
kaatula Автор
— вы знаете, а хабр глючит, к первому комментарию не идёт ответ
Пойду баг репортить )
perfect_genius
Чуть ниже середины фото и правее.
Sergey_Kovalenko
Есть еще один кот рыжего цвета.
perfect_genius
И где он?
Sergey_Kovalenko
Лежит на крыльце возле стеклянной двери в верхнем левом углу фотографии
perfect_genius
Хорошо, осталось найти на фото эту стеклянную дверь.
Я ещё рыжего котёнка нашёл ниже середины фото.