Загорелась ошибка чек в чем причина и как сбросить

Загорелась ошибка чек в чем причина и как сбросить?

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

Как вас могут обмануть на СТО

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

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

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

От чего подобная ошибка возникает

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

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

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

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

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

Способы сброса

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

Да оборудования море, стоит оно дорого, научиться им работать – длительно по времени. По сравнению с такими затратами, пусть лучше на СТО немножко обманут, сбросив ошибку. Такую ошибку можно сбросить самостоятельно несколькими способами, выберите удобный для вас:

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

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

Баг чек код ошибки

Что пишут в блогах

Онлайн-тренинги

Конференции

TestCon Moscow 2021
Конференция по тестированию и обеспечению качества ПО
7-9 сентября, Онлайн

Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Автор: Алексей Потемкин, QA engineer компании «JetRuby Agency»

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

Каналы поступления багов

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

Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.

Направления работы отдела QA

С каналами поступления информации о багах мы определились. Теперь перейдем к направлениям работы QA инженеров. Их несколько:

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

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

Написание bug report — один из кирпичиков, которые закладываются в фундамент достижения этих целей. Он должен быть ровным и красивым. В противном случае мы сталкиваемся с проблемами: разработчикам приходится тратить время на воспроизведение бага, вместо того чтобы писать код.

Написание bug report: как это происходит

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

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

Чего делать нельзя? Нельзя информировать сразу о нескольких проблемах в пределах одного баг репорта. Закон джунглей: один bug report = одна проблема. Не ленитесь.

Чем плох баг репорт с несколькими проблемами в пределах одной задачи? Это значительно замедляет процесс их устранения. Следите за руками: после починки дефекта разработчик переназначает задачу на QA специалиста для проверки. Если мы имеем несколько проблем в одной задаче – разработчик не сможет отдать их на проверку, пока не устранит каждую из них. Чувствуете как утекает время? Когда же все баги упакованы в отдельную задачу, QA специалист может приступить к проверке исправлений значительно раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и программное обеспечение быстрее продвигается к релизу.

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

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

К слову, баг репорт состоит не только из описания. Любое сообщение о дефекте включает в себя два элемента:

Рассмотрим каждый из них в отдельности.

Заголовок

При составлении заголовка мы используем золотое правило: “Что? Где? При каких условиях?”. Заголовок — это первое, что увидят разработчики, менеджер проекта или ваши коллеги — QA специалисты. Сделав его максимально простым, точным и понятным, вы сразу же зададите верное направление. Итак, заголовок отчета об ошибке должен:

Давайте рассмотрим работу с заголовком на простом примере:

Небольшой комментарий к информации об окружении и проектных традициях. Приведем простой пример. Мы имеем дело с проектом, в пределах которого разрабатывается мобильное приложение под две платформы: iOS и Android. В зависимости от того, к какой платформе привязан баг, в заголовке указываем: iOS или Android. Например, “iOS. Application accepts dates of birth from the future.”.

Дополнительный вариант — использование так называемых ярлыков (labels). Некоторые системы отслеживания ошибок предоставляют соответствующий функционал.

Описание

Переходим ко второму компоненту bug report. Описание должно содержать следующую информацию:

При работе с Pivotal Tracker мы привыкли маркировать уровни проблемы цифровым значением от 1 до 4, это значение указывается в качестве label. По уровням градация следующая: 1 — это Blocker и Critical, 2 — это Major, 3 — это Minor и 4 — это Trivial. Такая градация уровня проблемы используется на всех проектах, которые ведутся в Pivotal Tracker.

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

Примеры

Пример #1

Один из баг репортов для мобильного приложения. Проект ведется в Pivotal Tracker. Уровню проблемы присваивается значение в диапазоне от 1 до 4, где наиболее важные моменты — это “1” и далее по убыванию. Приложение разрабатывалось сразу под две платформы — Android и iOS. Поэтому мы решили прописывать платформу в заголовок задачи.

Переходим к составляющим баг репорта:

Заголовок — Android. About Track screen. Nothing happens after tap on the Label. Как было сказано выше, мы указываем платформу, тем самым отвечая на вопрос “где?”. То есть: на платформе Android, на экране About Track. Далее мы отвечаем на вопросы “что?” и “когда?” — Nothing happens after tap on the Label.

Так как отдельных полей о тестовом окружении в Pivotal Tracker не предусмотрено, мы добавляем информацию о билде (Build v2.0.6) и версии Android, на которой был воспроизведен баг (Android 6.0), в поле Description.

В этом же поле прописываем шаги воспроизведения бага:

И ожидаемый результат: Expected behaviour: Label screen should be opened.

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

Пример #2

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

Кликните на изображение для увеличения

Проект также велся в Pivotal Tracker, поэтому уровень проблемы был указан с помощью label. Использовалась аналогичная шкала (от 1 до 4). Мы присвоили проблеме уровень “2”, так как отсутствие данной в ответе метода не позволяло выполнить некоторые операции в профиле пользователя.

Итак, заголовок — The method «View User Profile» should return information about user’s location. Мы совершенно отчетливо указываем на метод и проблему. Далее в поле Description мы даем понять, что речь идет о стейджинге.

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

Email: user@user. com

Password: qwerty

Token: xVjowqgm-FHjNwB9tAbG

Описываем проблему и добавляем техническую информацию: пример вызова метода при помощи curl и текущий ответ.

Наконец, указываем что мы ожидали увидеть в ответе недостающие атрибуты.

Выводы

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

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

Использование общих шаблонов и практик дизайна отчетов об ошибках в пределах компании позволяет существенно сократить время коммуникации между разработчиками и QA специалистами. Дело в том, что согласование задач (то есть случаи, когда разработчики возвращают тестировщикам задачи со статусами rejected, can’t reproduce, more info) зачастую существенно затягивается. Соблюдение же правил написания bug reports позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.