типы багов в тестировании
Развиваем интуицию в тестировании или где искать баги
Опытный тестировщик, особенно если он со своим проектом знаком давно, накидывает список тест кейсов довольно ловко. Но если вы еще только формируете свой профессиональный стиль или пришли в новый продукт, или просто открыты обмену опытом то, вероятно, вы найдете что-то значимое для себя в списке моих профессиональных приемов работы.
Вступление
И когда вы принимаете решения, не опираясь на аргументы, вы опираетесь на интуицию, которую приобрели просто проживая жизнь.
Изучаем use cases пользователей
Дружим с командой техподдержки
Берем в тщательную работу баги клиентов
Изучаем белый ящик
Подмечаем слабые части продукта
Разработка не бывает одинаково ровной. Иногда что-то делается в режиме прессинга, быстрей-быстрей. Такие части продукта могут давать о себе знать багами довольно долго. Здесь хорошо не терять из виду этот функционал.
Наблюдаем за разработчиками
Знать, кто какой кусок кода сделал, а главной какой он разработчик, на самом деле, очень удобно. Встречаются те, которые откровенно не любят тесты, мало их пишут, ничего не перепроверяют (это не значит, что он «плохой», у него могут быть другие таланты). Если вы узнали, что этот кусок функционала работа такого человека, нужно быть дотошнее. А есть те, кто очень скрупулезно все сверяет и выверяет. Проверять такой функционал спокойнее. Можно создать внутренний рейтинг для себя (с кем нужно быть внимательнее, а кто делает работу чисто).
Погружаемся в тему продукта
Каждый продукт существует для какой-то сферы жизни. А там целый мир: свои термины, свои понятия “хорошо” и “плохо”, свой рынок. Бывает полезно понимать эту лексику, что-то знать/читать об индустрии, наблюдать за продуктами конкурентов. Когда ты “в теме”, мозг быстро прикидывает на что нужно обратить внимание. А продукты конкурентов иногда могут научить, как сделать лучше, например, если тестируемые изменения касаются интерфейса.
Изучаем теорию тестирования
И для черноящичного и для белоящичного уже есть разработанные приемы написания тестов, они всегда могут стать отправной точкой, когда не знаешь с чего начать. (Equivalence Partitioning, Boundary Value Analysis, Decision Table, State Transition, Use Cases VS Statements testing)
Как дополнение этому пункту напишу, что вдохновение для написания тест кейсов можно черпать еще из следующих областей:
каждый acceptance criteria;
области, которые будут отправлять свои данные в новый функционал;
области, которые будут отправлять свои данные в новый функционал;
вариации коммуникации функционала с остальными модулями: через ftp, через aws, конфиги и прочее;
Каноны, стандарты, общепринятые удобства;
информативность сообщений об ошибках; представьте, что вы впервые видите продукт и столкнулись с ошибкой; сообщение вам помогло предпринять следующий шаг для ее решения?
информативность успеха; пользователь понял, что достиг желаемой цели?
единый стиль с остальными частями продукта: списки, фильтры, таблицы;
Заключение
Конечно, простой ежедневный опыт тоже откладывается в интуицию. Чем больше времени ты на проекте, тем острее его чувствуешь. А еще бывает как с вождением автомобиля, чем дольше за рулем, тем больше притупляется осторожность. В такие времена меня спасает пробежаться по чеклисту выше и проверить саму себя на тему, а не упустила ли что-то важное в новом функционале.
Эти заметки не претендуют на какую-то научность, этакий обмен опытом с моей стороны, поэтому я буду рада вашим дополнениям на заявленную тему, делитесь, пожалуйста.
Типы багов: этимология и энтомология
1. Немного этимологии и энтомологии
Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» — сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.
Еще в 1878 году, Томас Альва Эдисон (да-да, тот самый!) в письмах к своему соратнику Пускасу писал: «It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that ‘Bugs’ — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached». Тем же словом, инженеры называли и сбои радарной электроники во время второй Мировой Войны. Конечно, более распространена история о том, что в 1946 году разработка компьютера Марк-2 (Mark-II) были приостановлена из-за сбоя его функционирования, вызванного попаданием мотылька между контактов. Трупик мотылька был извлечен и приклеен к отчету липкой лентой с комментарием «First actual case of bug being found.» («Первый реальный случай нахождения жучка»). Как нетрудно догадаться, примерно оттуда же «растут уши» и слова «дебаггер» (debugger) – буквально «избавитель от жучков».
2. Виды багов.
Простейший (не как инфузория-туфелька, а самый простой для понимания, модно сказать «классический») баг – это несоответствие между ожидаемым результатом (ОР) и фактическим результатом (ФР). Разберем это на примере:
| Действия | Ожидаемый результат | Фактический результат |
|---|---|---|
| Ввести в ячейку выражение «=2+2*2» (без кавычек) и нажать ENTER | 6 | 8 БАГ. |
(это, кстати, реальный баг старого Microsoft Excel – он не учитывал приоритета математических операций, по которому умножение имеет высший приоритет по сравнению со сложением)
Все просто. Ждем одно – получаем другое. Баг.
Я не буду перечислять все подвиды бага классического – от опечаток в данных и опечаток в коде до бесконечных циклов, от использования оператора присвоения вместо оператора проверки равенства до использования неинициализированной переменной, от состояния гонки (race condition) в мультипоточных приложения до переполнения буфера, и так далее, и тому подобное – все это достаточно обыденные и ясные явления. Обратимся к малознакомой экзотике.
2.1. Гейзенбаг (Heisenbug)
Баг, названный в честь Гейзенбергского Принципа неопределенности – концепции квантовой физики. Простым (хоть слово «просто» здесь и не очень применимо) примером подобного бага будет являться ошибка, проявляющаяся, когда программа запускается на исполнение в рабочей среде, но исчезающая, когда программу запускают в дебаггере.
2.2. Борбаг (Bohrbug)
Тип бага, названный так в честь атомной модели Бора. В противоположность Гейзенбагу, он проявляется постоянно при одном и том же стечении обстоятельств. Вопрос в том, что весь набор обстоятельств бывет невозможно (или очень трудно) отследить.
2.3. Мандельбаг (Mandelbug)
Назван в честь Бенуа Мандельброта, внесшего огромный вклад в теорию фракталов. Мандельбагами называют ошибки, чьи причины настолько сложны и неясны, что фактически кажутся хаотичными и не поддающимися описаниями. (ключевое слово «кажутся»). Подобное, может быть вызвано, например, медленной реакцией системы – то есть ошибка уже произошла, но об этом вы узнаете только через некоторое время, что сильно затруднит локализацию причин.
2.4. Шрединбаг (Schroedinbug)
Шрединбаг назван в честь известного парадокса с кошкой Шредингера (или эта несчастная животина – кот?). Он заключается в том, что кто-нибудь читает код программы (работающей уже некоторое время) и восклицает «Да этого не может быть! Она просто не может функционировать!», после чего программа прекращает свое функционирование пока данная ошибка не будет исправлена. Будучи, казалось бы, абсолютно фантастической, данная ошибка попадается в реальности – спросите знакомых ветеранов- разработчиков, они подтвердят. Хотя, конечно, последующий анализ, как правило, позволяет отнести ошибку к разделам 2.1, 2.2 или 2.3, это удается не всегда.
2.5. Фазы луны
На самом деле такой ошибки не существует – это популярная отговорка тех, кто не хочет (не имеет желания и/или времени) разбираться в сложных причинах возникновения ошибки. Тем не менее, в истории существует пара примеров, когда ошибки возникали буквально из-за фаз луны. Я не буду приводить здесь эти истории, надеясь, что никому из нас не придется работать со столь сложными устройствами. Тем не менее, в любом случае, хотелось бы предостеречь всех от неосторожных умозаключений и попросить быть более внимательными, настойчивыми и скрупулезными в своей работе.
2.6. Статистический (более известный как количественный) баг
Баг возникающий при произведении программой большого количества каких-либо действий. Примером данной ошибки может служить запуск программы, которая должна равномерно расположить на плоскости некоторое количество точек. Если, например, при большом количестве точек программа не только неправильно располагает их, но и норовит расположить все на одной стороне плоскости (при этом до определенного количества точек работая прекрасно) – вуаля, количественный баг.
2.7. Демонстрационный эффект.
Ну и конечно, известный всем, «эффект первого показа», не раз случавшийся и с вашим покорным слугой. Как только приходит пора показать, например, прекрасно функционировавший на тестовом стенде юнит, обязательно происходит что-то ужасное. Причны, как правило, тривиальны – пропуск «незначительных» тест-кейсов, невнимательность к деталям и неучтенные юз-кейсы. Опять же – будьте внимательней.
На этом я закончу краткий обзор багов, буду рад Вашим замечаниям и предложениям.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Баг и баг репорт
Как Вы думаете, какой навык тестировщика — самый важный?
Может автоматизация тестирования?
Что-то из soft-skills?
Умение работать в команде?
Как насчет поиска багов?
Написание хороших баг репортов — это самый важный навык тестировщика!
Потому что хороший баг репорт это:
Ни один другой навык не приносит столько пользы, как этот)
Вы можете быть супер-аналитиком, находить по 100 багов за день, общаться и дружить со всеми разработчиками. Но, если Вы не умеете создавать баг репорты — баги не будут исправляться. А если баги не будут исправляться… Вы сами можете догадаться, что произойдет 🙂
Научиться писать качественные баг репорты — просто!
Каким образом и что для этого нужно?
Читайте в этой статье)
Что такое Баг / Дефект?
Перед тем, как начать разговор о баг репортах, стоит очень хорошо разобраться, что такое “баг”, ведь его мы и будем описывать 🙂
Слово “баг” — это технический жаргон [1] [2]. Оно используется в разговорах, статьях и приложениях (Jira, TestRail и т.п.)
Стандарты [3] и книги [4] используют другое название — “дефект”, оно более профессиональное.
Так как это не научная статья, мы будем использовать слово “баг”, как более распространенное и привычное 🙂
Существует несколько определений бага:
Данные определения описывают баги в коде и их сложно применить к багам в требованиях, UI / UX и т.п.
На этапе проверки требований у нас нет компонента, системы (см. определение 1,3) или приложения (определение 2). У нас есть только текст, который их описывает, если он вообще существует 😂
Более универсальное и доступное определение приведено в книге [4]:
Баг — это отклонение фактического результата от ожидаемого результата.
Давайте рассмотрим несколько примеров багов.
Откуда берутся баги?
Баги являются следствием ошибок.
В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам [4].
Причин возникновения ошибок множество [5]:
Ошибки делают все и делают их всегда.
Это неотъемлемая часть природы человека и ее невозможно изменить или обойти.
Лучшие спортсмены, ученые, инженеры, политики, актеры, музыканты — ошибаются. Бизнес-аналитики, разработчики, тестировщики, дизайнеры, администраторы, переводчики и т.п. — не исключение…
Все ли баги нужно исправлять?
Нет, не все.
В идеальном мире — наверное да, но мы не знаем где он 🙂
Что мы знаем, так это то, что все люди ошибаются. Тестировщики тоже. Иногда Вы можете замечать вещи, которые багами не являются.
Это может происходить потому что вы:
Ситуация, когда Вы создаете “ложный” баг репорт — называется false-fail result [3].
Такие “моменты” характеризуют качество документации, качество подготовки к тестированию, качество проведения тестирования и анализируются QA (Вы ведь уже знаете, что QA ≠ тестирование?)
Если баг на самом деле существует, то перед исправлением всегда нужно оценивать его критичность, срочность и сложность исправления.
Zero bug policy — отличный процесс работы с багами при использовании гибкой разработки
Жизненный цикл бага
Каждый найденный баг всегда проходит через конкретные “этапы”, которые называются жизненный цикл бага.
Цикл, его этапы и переходы между ними сильно зависят от процесса тестирования и разработки, используемого в компании. Поэтому здесь приводится базовый процесс, этапы которого существуют в 99% случаев. Он прост для понимания, но помните, в реальном мире все немного сложнее 🙂
Не путайте жизненный цикл бага и жизненный цикл ПО — это не связанные вещи!
Давайте рассмотрим каждый этап и переходы между ними подробнее.
Этапы жизненного цикла бага
1. Открыт (Open) — баг создан, оформлен и передан разработчику / команде разработки
2. В Работе (In Progress) — ведутся работы по исправлению
3. Исправлен (Ready for check) — баг исправлен и передан тестировщику на повторную проверку
4. Закрыт (Closed) — баг проверен и больше не воспроизводится
Переходы бага между этапами жизненного цикла
Переходы между этапами жизненного цикла пронумерованы в соответствии с нумерацией списка ниже.
1. Открыт — Закрыт. Если баг — это “не баг”, он может сразу быть закрыт, без промежуточных операций.
Иногда этот переход выносят в отдельный этап жизненного цикла, который называется Отклонен (Rejected). Он используется для анализа процесса тестирования или оценки работы тестировщиков / разработчиков.
На некоторых сайтах можно прочитать, что “баг отклоняется разработчиком, если он считает, что дефект не важен”.
Мы считаем, что это не верно, потому что мнение разработчика — субъективное. Теоретически, он может “отклонять” баг если:
Если происходит отклонение бага, разработчик должен аргументированно описать, почему он не считает найденную неточность багом, а решение про исправление или закрытие должен принимать человек, который отвечает за качество (QA, PO, PM).
2. Открыт — В Работе. Баг подтвержден и передан разработчикам, которые начали работу над исправлением.
3. В Работе — Закрыт. Бывает, что в ходе исправления ошибки разработчик понимает, что это не ошибка, а что-то другое. (фича / неточность в требованиях, которую обсудили без тестировщиков и т.п.) В этом случае разработчик описывает, почему это не баг, и закрывает задачу.
Иногда этот переход выносят в отдельный этап жизненного цикла, Не Баг (Not A Bug). В таком случае задача возвращается тестировщикам, они ее пересматривают и либо закрывают, соглашаясь с разработчиком, либо исправляют описание и заново открывают.
Появление большого количества багов в статусе “Не Баг” говорит о проблемах в коммуникации и / или документации.
4. В Работе — Исправлен. Ошибку локализовали и исправили, она передана тестировщику.
5. Исправлен — Открыт. Тестировщик проверил исправление, баг все еще воспроизводится, то есть не исправлен. Он возвращается разработчику (возможно с указанием каких-то дополнительных деталей)
Этот переход может существовать как отдельный этап жизненного цикла бага — Переоткрыт (Reopened).
Появление большого количества багов в статусе “Переоткрыт” может говорить о проблемах в оформлении багов и использоваться для анализа качества работы тестировщиков.
6. Исправлен — Закрыт. Тестировщик проверил исправление, баг больше не воспроизводится.
7. Закрыт — Открыт. Если баг случайно закрыли, должна быть возможность его переоткрыть.
Не стоит переоткрывать закрытые баги, если они уже были исправлены, проверены и закрыты. Ситуация может возникать в ходе регрессионного тестирования.
Такой “операцией” Вы испортите аналитику и метрики + создадите путаницу в релизах и процессе работы и т.п.
Лучше создавать новый баг, скопировав закрытый и связав их между собой. Тогда путаницы не будет, а разработчику не придется искать ошибку, которую он уже исправлял 🙂
Теперь, когда мы разобрались с багами, причинами их возникновения и жизненным циклом — мы можем переходить к рассмотрению баг репорта 🙂
Что такое баг репорт (bug report)?
Баг Репорт (Bug Report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]
Мы уже знаем, что такое баг, поэтому определение можно упростить.
Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.
Другие названия этого документа:
Зачем нужны баг репорты?
Почему баги нельзя исправлять сразу, зачем писать отчеты? Лишняя работа, только время тратить… — типичный менеджер, который не слышал о качестве
Написание баг репортов — чрезвычайно полезный процесс, потому что:
1. Происходит фиксации факта существования бага
Есть репорт — есть прецедент для реакции.
Нет репорта — никто ничего не будет делать.
Именно поэтому не стоит писать баги в скайп / чат / говорить лично и т.п.
Есть вероятность, что о нем забудут (и вы, в том числе) и не исправят.
Потом баг найдет либо заказчик в ходе приемочного тестирования, либо клиент — и вряд ли они будут этому рады… Вы тоже не будете рады, когда разработчик скажет, что он впервые это видит.
2. Баг репорт помогает разработчику
Для воспроизведения и последующего исправления бага разработчикам нужна информация. Она должна быть максимально точной, полной и понятной. Без нее разработчику придется тратить время на поиск и анализ ошибки, и вряд ли он будет этому рад. Да и менеджмент не будет рад, так как разработчик будет заниматься не разработкой, а чем-то другим…
В докладе Егора Бугаенко Testing and Testers на TestCon 2020, именно об этом был 4-ый вопрос и объяснения, почему это важно. Рекомендую посмотреть 🙂
3. Появляется возможность приоритизации исправлений
Если у вас есть несколько багов — вам всегда придется выбирать, какой из них исправлять в первую очередь, потому что все сразу исправить не получится.
4. Появляется возможность анализа ошибок
Имея информацию о найденных дефектах Вы можете определять первопричины их возникновения и вносить изменения в рабочие процессы, чтоб их предотвращать. (Привет QA)
5. Тестировщик содействует устранению бага
Хорошо созданный баг репорт — это огромная помощь разработчику, так как из полученной информации он быстро сможет определить, где находится ошибка и исправить ее.
6. Появляется возможность контроля этапа исправления бага
Вы уже знаете, что до момента исправления, каждый баг проходит через определенные стадии жизненного цикла.
Наличие отчета о дефекте с изменяющимся статусом позволяет легко и быстро определять точное “положение” бага и контролировать его исправление.
7. Появляется возможность оценки качества продукта в текущий момент времени
Если в ходе тестирования было найдено 50 багов и все они были оформлены как баг репорты — вы, как менеджер, сможете оценивать готовность продукта, оценивать объем требуемых доработок, принимать решения о релизе и т.п.
Отчеты о дефектах дают командам очень полезную и важную информацию, которая необходима для контроля качества продукта.
Именно поэтому навык написания хороших отчетов критически важен для любого профессионала-тестировщика и его нужно освоить в совершенстве 😉
Атрибуты баг репорта
Баг репорт — это технический документ.
У него есть некий набор атрибутов (полей, параметров) для структуризации информации.
Атрибуты баг репорта можно разделить на 2 группы:
Основные поля
Дополнительные поля
Серьезность бага (Bug Severity)
Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.
Приведенные ниже уровни — не стандартизированы и могут отличаться в разных компаниях.
S4 | Blocker
Блокирующий — баг описывает ситуации, когда ПО не работает в принципе.
S3 | Critical
Критический — баг влияет на критический функционал или критические данные.
К критическому функционалу относятся функции приложения, без которого само приложение станет бессмысленным, либо перестанет выполнять свои основные функции.
Примеры критических функций в разных приложениях:
Помимо критического функционала, к критическим багам относятся:
S2 | Major
Серьезный — баг не влияет на критический функционал, но создает неудобства при использовании приложения / системы.
К этому уровню относятся баги, связанные с:
S1 | Minor
Незначительный — баг не влияет на бизнес логику приложения.
Чаще всего к этому уровню относятся баги в реализации UI (верстке), отсутствие переводов и т.п.
S0 | Trivial
Тривиальный — баг никак не влияет на качество продукта.
Из-за того, что такие баги не влияют на качество продукта, преднамеренно их не исправляют (они не “окупаются”). Обычно, правку делают в ходе реализации смежной задачи.
Типы багов
Дополнительный атрибут “Тип бага” необходим для обнаружения слабых мест в процессе разработки и тестирования, а также для их последующей корректировки.
Используемые типы багов определяются в зависимости от направления, размера и сложности проекта.
Приведенные ниже типы багов относятся к WEB сайтам.
UI (ошибка в верстке)
Баг в верстке — следствие ошибки в разметке (HTML) или стилизации (CSS) элемента страницы в специфическом окружении.
UX (ошибка в удобстве)
Баг в удобстве — неудобство / нелогичность работы с элементами / функционалом страницы.
Functional (ошибка в функционале)
Баг в функционале — несоответствие логики работы компонента заявленным функциональным требованиям.
SEO (ошибка в seo)
Баг в seo — ошибка, которая влияет на SEO (нарушение нефункциональных требований, касающихся seo).
Алгоритм создания баг репорта
Предположим, Вы нашли баг и приступаете к написанию баг репорта.
Ниже приведен алгоритм, следуя которому Вы точно ничего не упустите и снизите вероятность создания дубликатов или некачественных отчетов.
🔥 Если Вы хотите потренировать свой навык создания отчетов о дефекте и получить оценку с рекомендациями, Вы можете оставить заявку на получение практического задания по созданию баг-репортов.
Пример хорошего баг репорта (bug report example)
Предположим, в ходе исследовательского тестирования Вы заметили следующее:
И Вы хотите создать отчет о найденном баге (нет перевода текстов ошибок).
Итоговый вариант может выглядеть так:
Заголовок / Краткое описание / Тема / Summary / Title
Не переведены на украинский язык тексты ошибок (что?) на форме “Зворотний зв’язок” на странице https://itawards.ua/ua (где?) в UA версии сайта (когда?)
Скриншот / видео
Скриншот / ссылка на скриншот
Шаги к воспроизведению
Фактический результат
Отображаются ошибки на английском языке
Ожидаемый результат
Отображаются ошибки на украинском языке
Серьезность
Кто внимательно рассмотрел изображение с багом (или решил сам протестировать форму) — мог заметить еще несколько “странностей”.
Например, некоторые тексты ошибок содержат грамматические ошибки, атрибуты полей содержат свойство autocomplete, которое не работает в большинстве браузеров, а анимация на форме зависает при наведении на любой из прямоугольников.
Может показаться, что это мелочи, и так оно и есть. Но если таких мелочей будет слишком много — продукт не будет вызывать доверия у клиента и его не будут считать качественным.
The Devil is in details.
🔥 Если Вы хотите потренировать свой навык создания отчетов о дефекте и получить оценку с рекомендациями, Вы можете оставить заявку на получение практического задания по созданию баг-репортов.
Пример баг репорта в Jira
Jira является одной из самых распространённых систем управления проектами в мире и очень часто используется в ИТ.
Так может выглядеть описанный выше баг репорт в Jira:
Пример баг репорта в Jira
Основные поля являются обязательными для заполнения при создании бага, без них задача просто не сохраниться 🙂
Ошибки при создании баг репорта
Создание хороших баг репортов требует определенных знаний, навыков и опыта.
Начинающим тестировщикам (и не только, как бы это ни было странно) иногда тяжело справляться с этой задачей, и они часто делают следующие ошибки:
Знание типичных ошибок помогает проверять самого себя (можно создать чек-лист) и позволяет создавать более качественные отчеты без возвратов на доработку!
Резюме
В статье мы рассмотрели все, что нужно знать начинающему тестировщику о багах, баг репортах и их жизненном цикле.
Мы поняли, что баг репорты — это чрезвычайно важные документы, потому что именно они описывают найденные в процессе тестирования дефекты, исправление которых и повышает качество продукта.
И именно правильное и качественное оформление баг репортов является ключевым навыком тестировщика.
🔥 Если Вы хотите потренировать свой навык создания отчетов о дефекте и получить оценку с рекомендациями, Вы можете оставить заявку на получение практического задания по созданию баг-репортов.
Если у вас есть вопросы или предложения — пишите нам в Телеграм!
Если вам интересно тестирования и Вы хотите получать актуальную информацию по этой теме — подписывайтесь на наш Tелеграм канал. У нас очень интересно: статьи, видео, тесты, опросы, нет спама 😉
Источники
Что такое баг?
Баг — это отклонение фактического результата от ожидаемого результата.
Здесь:
— фактический результат — это то, что мы “видим” или то, что произошло после проделанных действий
— ожидаемый результат — это ожидания наблюдателя, которые он получил из требований, спецификаций, любой другой документации, личного опыта и здравого смысла
Откуда берутся баги?
Баги являются следствием ошибок.
В свою очередь, ошибка — это действие человека, которое приводит к неправильным результатам.
Что такое баг репорт (bug report)?
Баг Репорт (Bug Report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. [IEEE 829]
Баг Репорт (Bug Report) — документ, содержащий информацию о найденном баге.
Что такое Серьезность бага (Bug Severity)?
Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.