Как правильно ищет ошибку - Ремонт и установка крупной бытовой техники

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

Шаг 1: Занесите ошибку в трекер

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

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

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

Вы должны записать в трекер следующую информацию:

Что делал пользователь.
Что он ожидал увидеть.
Что случилось на самом деле.

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

Шаг 2: Поищите сообщение об ошибке в сети

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

Шаг 3: Найдите строку, в которой проявляется ошибка

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

Шаг 4: Найдите точную строку, в которой появилась ошибка

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

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

Шаг 5: Выясните природу ошибки

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

Ошибка на единицу
Вы начали цикл for с единицы вместо нуля или наоборот. Или, например, подумали, что метод .count() или .length() вернул индекс последнего элемента. Проверьте документацию к языку, чтобы убедиться, что нумерация массивов начинается с нуля или с единицы. Эта ошибка иногда проявляется в виде исключения Index out of range.
Состояние гонки
Ваш процесс или поток пытается использовать результат выполнения дочернего до того, как тот завершил свою работу. Ищите использование sleep() в коде. Возможно, на мощной машине дочерний поток выполняется за миллисекунду, а на менее производительной системе происходят задержки. Используйте правильные способы синхронизации многопоточного кода: мьютексы, семафоры, события и т. д.
Неправильные настройки или константы
Проверьте ваши конфигурационные файлы и константы. Я однажды потратил ужасные 16 часов, пытаясь понять, почему корзина на сайте с покупками виснет на стадии отправки заказа. Причина оказалась в неправильном значении в /etc/hosts, которое не позволяло приложению найти ip-адрес почтового сервера, что вызывало бесконечный цикл в попытке отправить счет заказчику.
Неожиданный null
Бьюсь об заклад, вы не раз получали ошибку с неинициализированной переменной. Убедитесь, что вы проверяете ссылки на null, особенно при обращении к свойствам по цепочке. Также проверьте случаи, когда возвращаемое из базы данных значение NULL представлено особым типом.
Некорректные входные данные
Вы проверяете вводимые данные? Вы точно не пытаетесь провести арифметические операции с введенными пользователем строками?
Присваивание вместо сравнения
Убедитесь, что вы не написали = вместо ==, особенно в C-подобных языках.
Ошибка округления
Это случается, когда вы используете целое вместо Decimal, или float для денежных сумм, или слишком короткое целое (например, пытаетесь записать число большее, чем 2147483647, в 32-битное целое). Кроме того, может случиться так, что ошибка округления проявляется не сразу, а накапливается со временем (т. н. Эффект бабочки).
Переполнение буфера и выход за пределы массива
Проблема номер один в компьютерной безопасности. Вы выделяете память меньшего объема, чем записываемые туда данные. Или пытаетесь обратиться к элементу за пределами массива.
Программисты не умеют считать
Вы используете некорректную формулу. Проверьте, что вы не используете целочисленное деление вместо взятия остатка, или знаете, как перевести рациональную дробь в десятичную и т. д.
Конкатенация строки и числа
Вы ожидаете конкатенации двух строк, но одно из значений — число, и компилятор пытается произвести арифметические вычисления. Попробуйте явно приводить каждое значение к строке.
33 символа в varchar(32)
Проверяйте данные, передаваемые в INSERT, на совпадение типов. Некоторые БД выбрасывают исключения (как и должны делать), некоторые просто обрезают строку (как MySQL). Недавно я столкнулся с такой ошибкой: программист забыл убрать кавычки из строки перед вставкой в базу данных, и длина строки превысила допустимую как раз на два символа. На поиск бага ушло много времени, потому что заметить две маленькие кавычки было сложно.
Некорректное состояние
Вы пытаетесь выполнить запрос при закрытом соединении или пытаетесь вставить запись в таблицу прежде, чем обновили таблицы, от которых она зависит.
Особенности вашей системы, которых нет у пользователя
Например: в тестовой БД между ID заказа и адресом отношение 1:1, и вы программировали, исходя из этого предположения. Но в работе выясняется, что заказы могут отправляться на один и тот же адрес, и, таким образом, у вас отношение 1:многим.

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

Шаг 6: Метод исключения

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

Попробуйте отключать компоненты системы один за другим, пока не найдете минимальную конфигурацию, которая будет работать. Затем подключайте их обратно по одному, пока ошибка не вернется. Таким образом вы вернетесь на шаг 3.

Шаг 7: Логгируйте все подряд и анализируйте журнал

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

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

Шаг 8: Исключите влияние железа или платформы

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

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

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

Если у вас возникает одна и та же ошибка вне зависимости от среды, то она в вашем коде.

Шаг 9: Обратите внимание на совпадения

Ошибка появляется всегда в одно и то же время? Проверьте задачи, выполняющиеся по расписанию.
Ошибка всегда проявляется вместе с чем-то еще, насколько абсурдной ни была бы эта связь? Обращайте внимание на каждую деталь. На каждую. Например, проявляется ли ошибка, когда включен кондиционер? Возможно, из-за этого падает напряжение в сети, что вызывает странные эффекты в железе.
Есть ли что-то общее у пользователей программы, даже не связанное с ПО? Например, географическое положение (так был найден легендарный баг с письмом за 500 миль).
Ошибка проявляется, когда другой процесс забирает достаточно большое количество памяти или ресурсов процессора? (Я однажды нашел в этом причину раздражающей проблемы «no trusted connection» с SQL-сервером).

Шаг 10: Обратитесь в техподдержку

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

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

Полезные советы (когда ничего не помогает)

Позовите кого-нибудь еще.
Попросите коллегу поискать ошибку вместе с вами. Возможно, он заметит что-то, что вы упустили. Это можно сделать на любом этапе.
Внимательно просмотрите код.
Я часто нахожу ошибку, просто спокойно просматривая код с начала и прокручивая его в голове.
Рассмотрите случаи, когда код работает, и сравните их с неработающими.
Недавно я обнаружил ошибку, заключавшуюся в том, что когда вводимые данные в XML-формате содержали строку xsi:type='xs:string', все ломалось, но если этой строки не было, все работало корректно. Оказалось, что дополнительный атрибут ломал механизм десериализации.
Идите спать.
Не бойтесь идти домой до того, как исправите ошибку. Ваши способности обратно пропорциональны вашей усталости. Вы просто потратите время и измотаете себя.
Сделайте творческий перерыв.
Творческий перерыв — это когда вы отвлекаетесь от задачи и переключаете внимание на другие вещи. Вы, возможно, замечали, что лучшие идеи приходят в голову в душе или по пути домой. Смена контекста иногда помогает. Сходите пообедать, посмотрите фильм, полистайте интернет или займитесь другой проблемой.
Закройте глаза на некоторые симптомы и сообщения и попробуйте сначала.
Некоторые баги могут влиять друг на друга. Драйвер для dial-up соединения в Windows 95 мог сообщать, что канал занят, при том что вы могли отчетливо слышать звук соединяющегося модема. Если вам приходится держать в голове слишком много симптомов, попробуйте сконцентрироваться только на одном. Исправьте или найдите его причину и переходите к следующему.
Поиграйте в доктора Хауса (только без Викодина).
Соберите всех коллег, ходите по кабинету с тростью, пишите симптомы на доске и бросайте язвительные комментарии. Раз это работает в сериалах, почему бы не попробовать?

Что вам точно не поможет

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

Ошибка, которую я недавно исправил

Это была загадочная проблема с дублирующимися именами генерируемых файлов. Дальнейшая проверка показала, что у файлов различное содержание. Это было странно, поскольку имена файлов включали дату и время создания в формате yyMMddhhmmss. Шаг 9, совпадения: первый файл был создан в полпятого утра, дубликат генерировался в полпятого вечера того же дня. Совпадение? Нет, поскольку hh в строке формата — это 12-часовой формат времени. Вот оно что! Поменял формат на yyMMddHHmmss, и ошибка исчезла.

_{Перевод статьи «How to fix bugs, step by step»}

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

Поэтому это не белое SEO, потому что серое SEO специально ищет ошибки поисковых систем, чтобы использовать их.

Когда проигрываешь по объективным причинам, тогда можно искать ошибки в себе, исправлять их, предъявлять требования к игрокам.

Дело в том, что мы настолько привыкаем искать ошибки, быть виноватыми за то, что несовершенны, что доброе к нам отношение просто не можем принять.

Начинаем искать ошибки в наших решениях.

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать
Карту слов. Я отлично
умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я стал чуточку лучше понимать мир эмоций.

Вопрос: вертухай — это что-то нейтральное, положительное или отрицательное?

Иногда несколько дней приходится искать ошибку.

В противном случае ищем ошибку.

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

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

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

Их наиболее великое заблуждение – искать ошибку там, где её нет, и увлекаться формами, когда их надо избегать, дабы углубиться в сущность.

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

Я долго искал ошибку и пришёл к выводу о том, что была и другая история.

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

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

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

А главное – в такой ситуации мало шансов всё исправить, потому что нет никакого стимула искать ошибки в собственном поведении, ведь всегда наготове удобное объяснение: «Это всё потому, что ребёнок неродной».

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

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

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

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

– Почему вам так нравится искать ошибки в моих утверждениях?

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

Если же я где ошибусь, то могу часами искать ошибку.

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

Не ищи ошибки строителей или забытого подземного хода.

Юрист ищет ошибки в документе, ищет всё время, борется с чужой точкой зрения.

–Что за ошибка? – заинтересовался я, как-то с последними событиями закрутился и перестал искать ошибки самостоятельно.

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

Единственное, что я хочу добиться, чтобы люди искали ошибки в своих действиях, а не в действиях партнёра.

Жертвы ищут ошибку в себе.

Тебе приходится искать ошибки.

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

Стал искать ошибки в органах чувств, сравнивать их с приборами – глаза с микроскопами, уши с акустическими датчиками, а мозг с центром обработки информации.

Начинать искать ошибки с момента внедрения нельзя категорически.

Отец очень долго искал ошибку.

Вдохновлённый прочитанным я упёрся в шар руками и стал искать ошибку в попытках.

Будем искать ошибки и зацепки.

Всюду ищешь ошибки и чертишь штрихи.

Особых ошибок не видел, да и есть ли смысл искать ошибки в том, что уже давно свершилось?

Ошибался, часами искал ошибку.

Какой вариант выбрать: «ищат» или «ищут»? Что характерно для устной речи, а что — для письменной, какая вариация считается правильной, с точки зрения правил русского языка? Чтобы ответить на поставленные вопросы, нужно разобрать глагол «искать», проспрягать его и найти единственно верный вариант написания. Для закрепления рассмотрим примеры предложений.

Читайте в статье

Как пишется правильно: «ищат» или «ищут»?
Примеры предложений
«Ищет» или «ищит»: как правильно пишется слово?
Неправильное написание слова «ищут»
Заключение

Как пишется правильно: «ищат» или «ищут»?

В разговорной и письменной речи используются два варианта:

«Ищат», когда во втором слоге указывается гласная буква «а».
«Ищут», когда во втором слоге пишется гласная буква «у».

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

Единственно верный вариант использования рассматриваемого слова таков: «ищут».

Это связано с тем, что глагол «искать» первого спряжения и не относится к глаголам-исключениям. Если его поставить в третье лицо множественного числа, то интересующее слово будет написано через букву «у» во втором слоге: «ищут».

Примеры предложений

Закрепить рассмотренное правило помогут примеры предложений:

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

«Ищет» или «ищит»: как правильно пишется слово?

Чтобы ответить на этот вопрос, нужно снова вспомнить, к какому спряжению относится рассматриваемый глагол. Поставим его в неопределенную форму: «искать». Поскольку он заканчивается на «-ать» и не относится к глаголам-исключениям, то относится к первому спряжению.

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

Использовать глагол в виде «ищит» не допускается.

Неправильное написание слова «ищут»

Часто в рассматриваемом слове допускаются ошибки:

Ишат.
Ишут.
Ищат.
Ищит.
Ишит.

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

Заключение

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

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

Онлайн проверка орфографии Advego — это сервис по проверке текста на ошибки. Оценивайте грамотность и правописание статей бесплатно! Мультиязычная проверка ошибок в тексте орфо онлайн! Корректировка текста онлайн — ваш инструмент и ежедневный помощник!

Язык: по умолчанию — русский

Текст: обязательно

длина текста, символов: 0

Напишите текст для проверки орфографии и нажмите кнопку «Проверить»

Максимальная длина текста — 100 000 символов.

Проверьте грамотность текста онлайн, чтобы исправить все орфографические ошибки. Сервис проверки правописания Адвего работает на 20 языках совершенно бесплатно и без регистрации.

Какие ошибки исправляет проверка орфографии и корректор текста?

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

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

На каком языке проверяется правописание и ошибки?

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

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

Пример отчета проверки орфографии и грамматики онлайн

Отчет проверки орфографии и грамматики онлайн

Какой объем текста можно проверить на орфографию?

Максимальный объем текста для одной проверки — 100 000 символов с пробелами. Чтобы проверить статью или документ большего размера, разбейте его на фрагменты и проверьте их по очереди.

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

Проверка пунктуации онлайн — исправление ошибок в тексте от Адвего

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

Адвего рекомендует проверить орфографию и пунктуацию онлайн на русском, украинском, английском и еще более чем 20 языках в своем качественном мультиязычном сервисе орфо онлайн!

Дебаг и поиск ошибок

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

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

Как обнаружить ошибку

Прочитай информацию об исключении

Если выполнение программы прерывается исключением, то это первое место откуда стоит начинать поиск.

В каждом языке есть свои способы уведомления об исключениях. Например в JavaScript для обработки ошибок связанных с Web Api существует DOMException. Для пользовательских сценариев есть базовый тип Error. В обоих случаях в них содержится информация о наименовании и описании ошибки.

Для .NET существует класс Exception и каждое исключение в приложении унаследовано от данного класса, который представляет ошибки происходящие во время выполнения программы. В свойстве Message читаем текст ошибки. Это даёт общее понимание происходящего. В свойстве Source смотрим в каком объекте произошла ошибка. В InnerException смотрим, нет ли внутреннего исключения и если было, то разворачиваем его и смотрим информацию уже в нём. В свойстве StackTrace хранится строковое представление информации о стеке вызова в момент появления ошибки.

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

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

Пример неявного переопределения параметров — использование интерцептора, который изменяет этот параметр в запросе и о котором вы не знаете.

Разверните стек

Когда выбрасывается исключение, помимо самого описания ошибки полезно изучить стек выполнения. Для .NET его можно посмотреть в свойстве исключения StackTrace. Для JavaScript аналогично смотрим в Error.prototype.stack (свойство не входит в стандарт) или можно вывести в консоль выполнив console.trace(). В стеке выводятся названия методов в том порядке в котором они вызывались. Если то место, где падает ошибка зависит от аргументов которые пришли из вызывающего метода, то если развернуть стек, мы проследим где эти аргументы формировались.

Загуглите текст ошибки

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

Прочитайте документацию

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

Проведите исследовательское тестирование

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

Бинарный поиск

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

Где обитают ошибки

Ошибки в своём коде

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

Ошибки в чужом коде

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

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

Ошибки в библиотеках

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

Первый случай хотя и редкий, но не стоит о нём забывать. В этом случае можно откатиться на другую версию библиотеки и создать Issue с описанием проблемы. Если это open-source и нет времени ждать обновления, можно собрать свою версию исправив баг самостоятельно, с последующей заменой на официальную исправленную версию.

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

Ошибки не воспроизводимые локально

Ошибка воспроизводится на develop стенде или в production, но не воспроизводится локально. Такие ошибки сложнее отлавливать потому что не всегда есть возможность запустить дебаг на удалённой машине. Поэтому убеждаемся, что ваше окружение соответствует внешнему.

Проверьте версию приложения

На стенде и локально версии приложения должны совпадать. Возможно на стенде приложение развёрнуто из другой ветки.

Проверьте данные

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

Проверьте соответствие окружений

Если проект на стенде развёрнут в контейнере, то в некоторых IDE (JB RIder) можно дебажить в контейнере. Если проект развёрнут не в контейнере, то воспроизводимость ошибки может зависеть от окружения. Хотя .Net Core мультиплатформенный фреймворк, не всё что работает под Windows так же работает под Linux. В этом случае либо найти рабочую машину с таким же окружением, либо воспроизвести окружение через контейнеры или виртуальную машину.

Коварные ошибки

Метод из подключенной библиотеки не хочет обрабатывать ваши аргументы или не имеет нужных аргументов. Такие ситуации возникают, когда в проекте подключены две разных библиотеки содержащие методы с одинаковым названием, а разработчик по привычке понадеялся, что IDE автоматически подключит правильный using. Такое часто бывает с библиотеками расширяющими функционал LINQ в .NET. Поэтому при автоматическом добавлении using, если всплывает окно с выбором из нескольких вариантов, будьте внимательны.

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

Дополнительные материалы

Алгоритм отладки

Повтори ошибку.
Опиши проблему.
Сформулируй гипотезу.
Проверь гипотезу — если гипотеза проверку не прошла то п.3.
Примени исправления.
Убедись что исправлено — если не исправлено, то п.3.

Подробнее ознакомиться с ним можно в докладе Сергея Щегриковича «Отладка как процесс».

Чем искать ошибки, лучше не допускать ошибки. Прочитайте статью «Качество вместо контроля качества», чтобы узнать как это делать.

Итого

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

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

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

Инструмент поддерживает 8 языков.

Символов в тексте
0

Без пробелов
0

Количество слов
0

Вставьте ваш текст для проверки

Ваш текст проверяется

Орфография

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

Что входит в проверку текста?

грамматические ошибки;
стиль;
логические ошибки;
проверка заглавных/строчных букв;
типографика;
проверка пунктуации;
общие правила правописания;
дополнительные правила;

Грамматика

Для поиска грамматических ошибок инструмент содержит более 130 правил.

Деепричастие и предлог
Деепричастие и предлог
«Не» с прилагательными/причастиями
«Не» с наречиями
Числительные «оба/обе»
Согласование прилагательного с существительным
Число глагола при однородных членах
И другие

Грамматические ошибки вида: «Идя по улице, у меня развязался шнурок»

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

Пунктуация

Чтобы найти пунктуационные ошибки и правильно расставить запятые в тексте, инструмент содержит более
60 самых важных правил.

Пунктуация перед союзами
Слова не являющиеся вводными
Сложные союзы не разделяются «тогда как», «словно как»
Союзы «а», «но»
Устойчивое выражение
Цельные выражения
Пробелы перед знаками препинания
И другие

Разберем предложение, где пропущена запятая «Парень понял как мальчик сделал эту модель»

Пунктуационная ошибка, пропущена запятая: Парень понял,
«Парень понял, как мальчик сделал эту модель»

Какие языки поддерживает инструмент?

Для поиска ошибок вы можете вводить текст не только на Русском
языке, инструмент поддерживает проверку орфографии на Английском, Немецком и Французском

Приложение доступно в Google Play

Введите текст (не больше 10000 символов, вы набрали 0):

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

Как пользоваться: чтобы проверить текст на орфографические ошибки, введите слово или текст, затем нажмите «Проверить». Сервис предложит исправление ошибок в написании слов, в которых обнаружены ошибки, а также подчеркнет неправильные слова. Поддерживаются русский, английский и украинский языки. Знаки препинания не учитываются. Сервис незаменим на ЕГЭ, контрольных, словарных диктантах (особенно поможет исправитель).

За эту неделю орфографию проверили 22976 раз.
Число ваших проверок за всё время: 0.
Если вы хотите улучшить этот online сервис, помогающий бесплатно исправлять ошибки, пишите предложения в комментарии. Сервисов, позволяющих полноценно и бесплатно проверять правильность пунктуации (запятые, тире и т.п.) в интернете нет, но есть помощник для проверки пунктуации на 5-ege.ru/. Если вам нужно часто проверять тексты, сохраните эту страницу.

→

ищет — глагол, наст. вр., 3-е лицо,

Часть речи: инфинитив — искать

Часть речи: глагол

Часть речи: деепричастие

Несовершенный вид	Совершенный вид
ища

Часть речи: причастие

Действительное причастие:

Страдательное причастие:

Часть речи: кр. причастие

Страдательное причастие:

Настоящее время
Единственное число	Множественное число
Мужской род	Женский род	Средний род
ищем	ищема	ищемо	ищемы

Прошедшее время
Единственное число	Множественное число
Мужской род	Женский род	Средний род
искан	искана	искано	исканы

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

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

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

Если все же не кому посмотреть на твой текст свежим редакторским взглядом, то придется справляться самостоятельно. Поэтому мы спросили у преподавателей Школы журналистики имени Владимира Мезенцева при ЦДЖ о том, как искать ошибки в собственных текстах, чтобы материал можно было смело публиковать.

Олеся Остапчук, журналист, лауреат премии «Редколлегия», преподавала в Медиашколе журфака МГУ им. М.В. Ломоносова.

«Первое, что нужно сделать после того, как ты написал текст, это пропустить его через какой-нибудь редактор. Через ворд, текст ру, где тебе покажут, какой процент уникальности. Не так важно для журналиста, но на первоначальных этапах важно, потому что когда со стороны видно, что ты переписал чужую статью своими словами — понятно, что это не журналистский материал, и над ним ещё стоит работать.

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

Редактор потом все равно увидит ваш текст, но лучше первоначально сдавать его в «причесанном» виде. Изначально пользоваться вот такими бесплатными сервисами.

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

Григорий Прутцков, кандидат филологических наук, доцент кафедры зарубежной журналистики и литературы журфака МГУ им. Ломоносова:

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

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

3.Отправив текст в редакцию, спросите редактора, всё ли в материале понятно, логично, не нужно ли что-то исправить, дополнить, уточнить.
В результате ваш материал получится практически безупречным!»

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

Источник

Автор: Слава Кирлан

Преамбула

Ошибки есть всегда. Если ошибок нет — это значит, что их еще не нашли. Если в программе не найдено ни одной ошибки – значит эта программа никому не нужна, и никто ей не пользуется :).

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

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

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

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

1. А был ли мальчик?

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

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

2. Разделяй и властвуй

Ошибка есть (увидели, убедились, поверили). Она стабильная (повторяется из раза в раз). Теперь мы пытаемся ее «упростить». В разных ситуациях делаем по разному, но суть одна – уменьшить пространство поиска.

2.1 К примеру оборотно-сальдовая ведомость за год показывает неправильные цифры. Начинаем уменьшать период, к примеру, по методу дихотомии золотого сечения (режем пополам и смотрим есть ли ошибка). Берем первое полугодие и смотрим, есть в нем ошибка. Если нет, значит ошибка во втором полугодии (лучше проверить это). Потом второе полугодие делим на кварталы и т.д. и т.п. – старый проверенный способ.

2.2 Другой пример при обмене данными через WEB-сервер в конечную программу попадают неправильные данные. Тут режем по алгоритму:

Запрос формируется в исходной базе
Данные перегоняются по сетке в базу приемник
База приемник получает данные и записывает их

Считаем что каждый этап «Черный ящик» со своим входом и выходом. Вот и проверяем эти входы и выходы (в последовательности кому как нравится).

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

2.3 Если у нас сложный многотабличный запрос – беспощадно его режем. Любой самый сложный запрос всегда состоит из конечного количества маленьких и легких запросиков, которые очень легко анализировать. Убедившись, что отдельные запросики возвращают «правильные» данные, начинаем потихонечку их склеивать в большой и сложный (аккуратно, поочередно), и каждый раз смотрим – правильный ли результат мы получаем

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

пользовательском режиме у конфигурации должна стоять опция «Параметры / Системные / Отладка разрешена».
запустить ту же самую конфигурацию в режиме конфигурирования и через «Отладка / Подключение» подключится к нужному пользовательскому сеансу.

Отдельно скажу, что для отладки процедур выполняемых на сервере необходимо запустить сервер с параметром «-debug».

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

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

Наверно, бывают ситуации, когда отладчиком пользоваться невозможно. Тогда предлагаю менять код (только всегда предварительно делайте копии). Используйте сообщения, запись в какие-нибудь регистры, файлы. Да и просто убирайте куски кода. Благо мы не врачи – мы можем себе позволить отрезать «руку» и посмотреть «не перестанет ли болеть голова».

В общем, главное локализовать ошибку (упростить ее).

3. Спасение утопающих

Нашли ошибку. При ее решении исходим из того, что в 99.9% это ошибка разработчика конфигурации, а не платформы, и исправить ее можно. Более того, решение этой ошибки есть

в синтакс-помощнике (среди описания операторов)
в пресловутых «желтых книгах»
в других конфигурациях (по принципу «как там так и у меня должно быть»)
в интернете.

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

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

Если уж вы отчаялись и решили спросить, то вопрос должен быть информативным. Бессмысленно спрашивать «Почему у меня в СКД не выводится группировка?». Поясните, что из себя представляет схема, какая группировка у вас не выводится. Если программа выдает ошибку – напишите какую ошибку (прямо тот текст, который выдает программа). Ясно формулируйте, что у вас есть и что вы хотите. Чем понятней будет вопрос – тем больше шансов, что на него будет адекватный ответ. Но тут нужно чувствовать меру: вряд ли кто-то будет читать сообщение, состоящее из 1000 строк с описанием всей ситуации «от сотворения мира».

Вопрос должен быть кратким (читаемым) и конкретным, а иначе получится просто заспаменную тему с ехидными замечаниями «о жизни».

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

А тем кто отвечает очень хочется напомнить фразу «Мы все одинаково невежественные, но в разных областях» (Феликс Райчак не помню автора). Если спрашивают – это не значит что тот кто спрашивает глупее, он может быть просто менее опытный в этом вопросе. Хорошо что он пытается учиться, и мерзко его за это гнобить. Если не можешь ответить по теме (более чем пустой фразой «гугл найдет все») – лучше промолчать.

Заключение

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

Или я в чем-то ошибаюсь?

ЗЫ. Если текст бесполезный – можно снять публикацию. Во вложении, тот же текст но виде файла WORD (на всякий случай)

ЗЫЗЫ. Исправил обнаруженые ошибки

Источник

Дебаг и поиск ошибок

Время на прочтение
6 мин

Количество просмотров 5.5K

Как обнаружить ошибку

Прочитай информацию об исключении

Если выполнение программы прерывается исключением, то это первое место откуда стоит начинать поиск.

Разверните стек

Загуглите текст ошибки

Прочитайте документацию

Проведите исследовательское тестирование

Бинарный поиск

Где обитают ошибки

Ошибки в своём коде

Ошибки в чужом коде

Ошибки в библиотеках

Ошибки не воспроизводимые локально

Проверьте версию приложения

Проверьте данные

Проверьте соответствие окружений

Коварные ошибки

Дополнительные материалы

Алгоритм отладки

Повтори ошибку.
Опиши проблему.
Сформулируй гипотезу.
Проверь гипотезу — если гипотеза проверку не прошла то п.3.
Примени исправления.
Убедись что исправлено — если не исправлено, то п.3.

Подробнее ознакомиться с ним можно в докладе Сергея Щегриковича «Отладка как процесс».

Итого

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

Источник

Главная цель создания бага (дефекта) – рассказать “миру” об ошибке, которую вы нашли. И важно, чтобы тот, кто будет исправлять и проверять этот баг, понял вас с первого раза. Плохо описанный баг вызывает лишние телодвижения и обсуждения, которых можно избежать и сэкономить время для полезных задач.

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

И да, в этой статье баг-репорт = баг = дефект = ошибка. Кто-то эти понятия разделяет, кто-то использует как синонимы. Мы решили использовать второй вариант синонимов.

У дефектов есть следующие атрибуты, которые нужно заполнять:

Заголовок

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

Глагол – Не работает
Что – кнопка сохранения нового пароля
Где – в настройках учетной записи
Когда – после ввода нового пароля и подтверждения

или

Не отображается сообщение об успешной смене Email после перехода по ссылке из письма в IE10

Согласитесь такой заголовок гораздо понятнее, чем “Не работает кнопка” или “Сообщение о смене email”. Часто такие заголовки пишут тестировщики, и чтобы понять суть ошибки приходится читать детальное описания бага.

Но ведь разработчики все равно будут читать детали бага! – возразите вы и будете правы. Разработчики в любом случае читают баг целиком. Зачем тогда писать красивый заголовок? А вот зачем:

Правильное название бага облегчает его поиск.

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

Отчеты по найденным багам более понятны

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

Шаги для воспроизведения

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

Пример “все шаги в одном”:

Шаги для воспроизведения: Войти в профиль аккаунта и там в настройках изменить email и сохранить

Пример “пошагово”:

Войти в профиль аккаунта
Перейти в раздел Настройки
Ввести новый email в поле для смены email
Нажать на кнопку Сохранить

Строгих правил конечно нет, но представление по пунктам понятнее и легче воспринимается при чтении.

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

Ожидаемый результат

Что должно произойти, согласно требованиям. Как должна отработать программа в этом случае. Обязательный пункт, даже если он выглядит очевидным для вас. Разработчик может не понять, как же должно быть, поленится смотреть в требованиях и вернет баг вам для уточнения. Чтобы избежать такого “пинг-понга” лучше сразу писать ожидаемый результат (или модно по-английски Expected Result)

Фактический результат

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

Окружение

Здесь указывается:

браузер и операционная система
боевой или тестовый стенд

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

Версия билда/сборки, в которой найден баг

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

Тестовые данные

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

Автор бага

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

Исполнитель

Тот, на кого назначена бага. Это либо аналитик для правки требований, или разработчик для правки кода, или дизайнер для правки макетов, или тестировщик для проверки бага.

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

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

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

Если мы не знаем, в каком модуле ошибка и матрицы ответственности у нас нет? Есть другой вариант

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

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

Скриншоты, видео

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

Лог-файлы или трейсы

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

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

Критичность / Серьезность

Серьезность (Severity) — показывает влияние дефекта на работоспособность приложения и определяется тестировщиком.

Выделяют, как правило, от 3 от 5 степеней критичности.

Рассмотрим 4:

S1 Critical — тестирование заблокировано
S2 Major — важная функция не работает
S3 Minor — менее важная функция не работает
S4 Trivial — проблема несущественна + косметические правки

В разных багтрекерах степени критичности могут называться по-разному:

1, 2, 3, 4
Blocked / Critical / Major / Minor / Trivial
Critical / High / Normal / Low

Приоритет

Приоритет (Priority) — это порядок, в котором дефекты должны быть исправлены. Определяются бизнесом (выставляет менеджер проекта или менеджер продукта). Чем выше стоит приоритет, тем скорее нужно исправить дефект.

P1 Высокий (High) — исправить немедленно
P2 Средний (Medium) — попозже
P3 Низкий (Low) – в следующей пятилетке

Часто используют только 1 параметр – критичность – и часто в багтрекерах он называется приоритетом. Понятия схожие и многие путают.

И другие 🙂 В багтрекерах еще выделяют дополнительные поля, такие как:

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

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

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

Источник