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

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

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

Конференции

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 позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.

Kernel Security Check Failure — как исправить BSOD и что он значит

Каждый пользователь Windows хоть раз сталкивался с синим экраном, возвещающим о поломке системы. В десятой версии операционной системы возникает ошибка BSOD K ernel S ecurity C heck F ailure. Она также появляется вместе с синим экраном и вводит в ступор пользователей. Разберемся, как избавиться от этой ошибки.

Почему возникает ошибка BSOD Kernel Security Check Failure?

Важно понимать, почему возникает неисправность компьютера, так как это позволит сократить время на поиск способа ее устранения. Разберемся, почему возникает ошибка K ernel S ecurity C heck F ailure. Причины следующие:

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

Что делать, если ошибка проявляется в момент запуска ОС?

Если у вас возникли проблемы во время загрузки системы, то вам необходимо провести процедуру восстановления. В этом случае есть два способа, как решить проблему K ernel S ecurity C heck F ailure. Расскажем о каждом подробнее.

Восстановление при помощи загрузочной флешки

Проверка файлов и драйверов до запуска системы

Во время запуска системы нажмите F 8, чтобы перед вами появилось меню с вариантами загрузки. Выберите «Включить безопасный режим», нажав 4. Дальнейшая работа по устранению K ernel S ecurity C heck F ailure W indows 10 происходит по инструкции:

Такой подход помогает решить проблему K ernel S ecurity C heck F ailure. Что делать, если ошибка проявляется не постоянно – расскажем дальше.

Решаем проблему с периодически появляющейся BSOD Kernel Security Check Failure

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

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

Acronis Drive Monitor

Эта программа предназначена для тестирования жесткого диска. После проверки обратите внимание на раздел Disk. В нем рассказывается о работе винчестера и его проценте здоровья. Чем выше этот процент, тем лучше. Рядом с результатом находится ссылка, открывающая страницу со списком ошибок диска (также их можно посмотреть во вкладке Critical Elements ). Чем больше критических ошибок – тем хуже. Если сканирование этим приложением показало низкий результат, то синий экран K ernel S ecurity C heck F ailure исчезнет после замены жесткого диска.

CCleaner

Эта утилита единственная, которая вам поможет безопасно проверить записи реестра и исправить ошибки в них. Для этой работы достаточно скачать бесплатную версию, а потом открыть в ней вкладку «Реестр». Запустите анализ реестра и после его окончания щелкните по кнопке «Исправить отмеченные». После этого утилита предложит вам сохранить копии вносимых изменений, по желанию можете создать этот файл для отката системы. Завершается работа программы тем, что ошибочные записи реестра удаляются или исправляются.

Drivers mini

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

Теперь вы знаете все о проблеме K ernel S ecurity C heck F ailure: как исправить эту ошибку и почему она возникает. Если у вас остались вопросы, пишите нам комментарии. Поделитесь статьей с друзьями, чтобы они могли убрать со своего компьютера синий экран.