Lesson 94

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

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

Слово Канеру:

Проверяйте исправления быстро.


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

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

Lesson 93

Слово Канеру:

Когда программист что-то починил, убедитесь, что оно все еще не сломано.

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

Lesson 92

Слово Канеру:

Лучшим способом может быть демонстрация бага программисту

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

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

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

Lesson 91

Слово Канеру:

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


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

Lesson 90

Кто негугля знает что такое пик Балмера?
http://xkcd.com/323/

Слово Канеру:

Просматривайте каждый чужой багрепорт

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

Этот тестировщик может также просмотреть:
- Все дефекты
- Все дефекты в своей области
- Все дефекты коллеги

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

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

Радости и весны псто

С подачи Максима cartmendum сотворили:

Раз

Альбом: office

Два

Альбом: office

И три

Альбом: office

Lesson 89

Я бы просклонял дефект по падежам так:

Именительный: Баг.
Родительный: Бага.
Дательный: Баге.
Винительный: Багу.
Творительный: Багом.
Предложный: Баге.

У вас есть свои версии?
UPD: Путаю мужской и женский род дефекта, но некоторые баги те еще суки, не так ли?

Слово Канеру:

Используйте рекламную информацию или данные техподдержки для разъяснения.

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

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

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

Lesson 88

Из тестировщика получится саппорт лучше чем из саппорта тестировщик? Или нет?

Слово Канеру:

Улучшайте навыки багрепортинга

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

Lesson 87

Никто так и не ответил. Давайте попробуем еще раз, а?

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

Куплю сегодня яблок.

Альбом: randompics4lj

Слово Канеру:

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

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

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

Lesson 86

Слово Канеру:

Будь осторожен со своим тоном. Каждый, кого вы критикуете, увидит ваш багрепорт.

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

Например, репорт, ПОЛНОСТЬЮ НАПИСАННЫЙ КАПСОМ читается как крик. Если вы не уверены в том, как будуть читать ваше репорт, попросите прочитать доклад кого-нибудь и ВНИМАТЕЛЬНО ПОСЛУШАЙТЕ его комментарии.

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

Lesson 85

Слово Канеру:

Сообщайте о проблеме, не пытайтесь ее решить.

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

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

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

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

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

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

Lesson 84

Слово Канеру:

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

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

У вашей компании критичности баг: минорные, серьезные, критические. Мы не будем определять их тут, так как они меняются от компании к компании. Вне зависимости от того, как определила нормы компания — работайте по ним. Не определяйте как серьезный баг, который обычно является минорным только для того, чтоб привлечь внимание. Если вы считаете, что схему критичности вашей компании было бы неправильно применить к данной баге, используйте схему, правильную с вашей точки зрения, но в конце репорта поясните ваше понимание проблемы («я знаю, что обычно такая поблема классифицируется как минорная, но в данном случае она должна классифицироваться как серьезная, так как... »).

Chief ConfeT&QA

http://confetqa.ru/program-chief-2012/

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

Поехали, ведь мое мнение так важно для вас.


Definition of done или ставим задачи по S.M.A.R.T., Анна Скумина.
Ничего нового, но все равно редко кто правильно ставит задачи. Я вот по смарту - почти ни разу, обычно 2 из 5. Мне 3 или 4 из пяти.
Манагерам - слушать по утрам вместе с зарядкой, ага.

Читаем багтрекер между строк или тестирование процесса разработки, Сергей Вербенко
Вау, мы умеем строить прикольные графики и считать разные цыфирьки! А что с ними делать после подсчета - не рассказал. Жаль.

Google Docs как инструмент ежедневного тест менеджмента, Ксения Лещенко
Как вариант. Но -всплывет масса проблем, ох всплывет...

JIRA: dashboards и SOAP API, Никита Налютин
см. Сергей Вербенко

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

Внедрение новичка в команду тестировщиков, Жанна Битюкова
Бодро, дельно. Зачет.

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

Тестировщик и заказчик – заклятые друзья?, Татьяна Зинченко
При чем тут менеджеры и при чем тут тестировщики? Не, конечно, Таня молодец, что зарулила, но все-таки...

Жизнь без тестировщиков: миф или реальность?, Николай Алименков
Всем слушать до просветления, а затем дружно сбрасываться с горы. Сам пересмотрю и коллегам разошлю.

Планирование тестирования как ежедневная активность тест-менеджера, Наталья Руколь
Как и всегда, доклад мне не понравился, а сама Наташа - очень даже.

Требования в Jira: Just do it!., Даша Гармаш
Простая и добрая история о том, как человек взял и запилил версионирование требований в jire. Молодец.

Один человек на нескольких проектах: как не запороть всё, Андрей Мясников
Хорошая версия, интересный вариант. Норм.

Ждем

Lesson 83

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

Мой итог:
Всего слов - 104
Выкинул слов - 41

(А в рабочей почте еще хрен найдешь письмо даже из 15 слов...)

Слово Канеру:

Заголовок бага— самое важное поле багрепорта.


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

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

Хороший заголовок дает читателю достаточно информации, чтоб решить, следует ли обратиться за разъяснениями. Он должен включать:
- Достаточно конкретное краткое описание, чтоб читатель мог представить себе сбой.
- Краткое описание ограничений и зависимостей бага (В каких обстоятельствах появляется баг?)
- Краткое описание влияния и последствий бага.

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

Lesson 82

В кинотеатре "Буревестник",
После той, большой войны
За полпачки "Беломора"
проходили пацаны.



Спасибо estel-oscora за историю этой песни.

Автор – поэт-песенник Александр Вратарев, и композитор – Владимир Быстряков

Оказывается, песня целиком и полностью основана, как это принято говорить, «на реальных событиях».

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

Слово Канеру:

Каждый баг заслуживает репорта

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

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

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

Lesson 81

О чем кричат воробушки
В последний день зимы?
Мы выжили! Мы выжили!
Мы живы, живы мы!

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

Как писал поэт:
Есть такой город Екатеринбург. Это там где под окнами откроки по вечерам до часу, примерно, дерутся, а с часу до трех ночи, примерно, целуются... И там еще стоят удивительно красивые проститутки. Таких больше нет нигде. Чудный город Екатеринбург.


Слово Канеру:

Дублирующиеся багрепорты — саморегулирующаяся проблема.


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

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

- Не позволяйте времени такого поиска выйти из под контроля. Если база багов велика, ты можешь непродуктивно потратить много времени на поиск дубликатов. Управляй своим временем.
- Каждый хорошо написанный репорт дает новую информацию, которая может помочь исправить баг.
- То, что два репорта являются дубликатами — это лишь чье-то мнение. Или несколько проблем могут быть причиной одного сбоя. Пока проблема решается и баг правится — сохраняйте всю собранную информацию (Pettichord 2000a).

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

Lesson 80

Слово Канеру:

Спросите перед тем как репортить баг в прототипе или локальной версии/ветке приложения.


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

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

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

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

Рутина

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

Я решил устроить все модно и запилил голосование - что я и мои коллеги будем нести в массы:

Альбом: office

Если у вас есть свои версии - озвучьте. Интересно же.

Рутина

Школы тестирования. Открытое будущее

Положу это здесь, чтоб не потерять.

Lesson 79

Как все-таки жаль, что Катя Кудринская отдалась в хорошие руки и больше не снимается в кино.
Такую солнечную мордаху сыграла... Фильм отстой, но она - лица необщим выраженьем - вытягивает.

Альбом: films

Эх.

Слово Канеру:

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

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

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

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

Перед тем как зарепортить много таких баг, поговорите с человеком, которому вы доверяете, который много знает о лежащей в основе системе.
Также рекомендуем использовать инструменты, делающие снимки конфигурации на которой появился сбой. Например, Rational распространяет бесплатный анализатор установки в Windows (VeriTest-Rational, http://www.rational.com/products/testfoundation). Аналогичный инструмент InCtrl5, доступнен на zdnet.com.

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

Lesson 78

Gaudeamus igitur,
Juvenes dum sumus!

Нелегко таки жилось студентам, гимн грустный...

И даже
Vivat Academia!
Vivant professores!

не спасают от
Nemini parcetur!

Ну а в целом,
Transeas ad inferos, Quivis antiburschius atque irrisores!

Слово Канеру:

Знай процессную стоимость отчета об ошибке.

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

Багрепорты участвуют в процессе. Они требуют времени на написание. Затем программист и/или менеджер проекта читает их. В некоторых компаниях группа Контроля За Изменениями просматривает их, чтоб оценить их. В других компаниях репорты попадают в группу Контроля после того как программист или менеджер решат, что баг не нужно исправлять. Это очень много читателей. Сложите все это время и вы обнаружите, что компания потратила 8 человеко-часов на рассмотрение и отклонение небольшой ошибки. В контексте проекта, если ты флудишь некритичными багрепортами, то ты можешь в одиночку уничтожить производительность команды программистов или менеджеров. Вы можете вызвать удивительный объем негодования и обиды небольшим количеством репортов о незначительных(или неясно описанных) проблемах.

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

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