на каком этапе разработки дороже всего устранить баг
говориМ о тестировании
простым языком
Основы тестирования. Жизненный цикл бага
Какой же путь проходит баг и какую роль в его жизненном цикле играет тестировщик? Давайте разбираться.
Ошибка, дефект, но чаще всего баг. Именно так называется то, что находят тестировщики в процессе работы.
Определение бага
Bug в переводе означает “жук, насекомое”. Первая ошибка, которая была задокументирована, возникла как раз из-за жука. В середине 40-х годов 20 века ученых Гарвардского университета вызвали для того, чтобы определить причину сбоя в работе вычислительной машины Mark II. Покопавшись в этой громадной куче приборов, соединенных проводами, они обнаружили бабочку, застрявшую между контактами электромеханического реле. Стало ясно, что именно она и явилась причиной сбоя. Одна из сотрудниц университета, Грейс Хоппер, так и сформулировала результат исследований: “неполадку вызвал баг”. Извлеченное насекомое было вклеено скотчем в технический дневник, с соответствующей сопроводительной надписью. Ее, как говорят, до сих пор можно увидеть в этом журнале, хранящемся в университетском научном музее.
В наше время большинство багов вызвано не насекомыми, как раньше, а преимущественно людьми.
Если обратиться к терминологии, то получается, что баг — это расхождение ожидаемого результата с фактическим. В нашем случае, ожидаемый результат – это поведение программы или системы, описанное в требованиях, а фактический результат — это поведение системы, наблюдаемое в процессе тестирования.
Баг в программе не появляется просто так, у него всегда есть источник. Например, ошибка программиста при написании кода. Дефекты встречаются, потому что люди склонны ошибаться, существует нехватка времени, сложность кода, сложность инфраструктуры, изменения технологий и/или много системных взаимодействий.
Что еще интересно, что программ, не содержащих ошибок, не бывает. По статистике на каждую тысячу строк программного кода, который пишут программисты, приходится несколько ошибок, а количество строк в сложном программном обеспечении достигает нескольких миллионов. Поэтому поиск и исправление этих ошибок – очень трудоемкое дело, составляющее до 45% всех затрат на разработку программного обеспечения.
Жизненный цикл бага
Давайте вкратце разберем каждый этап жизненного цикла
Данную схему можно изобразить в текстовом виде. Вот несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании):
1. Новый (new) —> Отклонен (rejected) —> Закрыт (closed)
2. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed)
3. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed) —> Переоткрыт (re-opend)
Жизненный цикл бага с точки зрения команды
Давайте для большей наглядности рассмотрим жизненный цикл бага с точки зрения участников команды и их функций.
Сначала тестировщик находит баг. Далее заносит его в систему учета ошибок. После этого программист начинает изучать отчет о дефекте. Именно на этом этапе он решает баг это или нет.
Давайте посмотрим сначала сценарий, в котором разработчик принял баг. Перед ним сразу встает задача пофиксить его, то есть исправить и залить (отдать заново на проверку). Как только разработчик все сделал, баг снова отправляется к тестировщику, который производит тестирование исправлений, а также проверяет смежные участки (регрессионное тестирование).
Если баг больше не воспроизводится, то тестировщик закрывает баг.
Если баг снова воспроизводится, то мы возвращаем его программисту. И снова проходим все шаги, начиная с 3-го шага (рассмотрения проблемы программистом).
Теперь другой сценарий — разработчик не принял баг. Если баг не принят, то разработчик возвращает его нам. Наша задача — рассмотреть проблему. Если баг вернули из-за некорректного описания, то значит переписываем его. Если невозможно воспроизвести дефект, то заново проверяем все шаги, может мы что то упустили при описании. Если разработчик прав и бага нет, то мы закрываем баг. А если баг все же есть, то вносим необходимые коррективы и опять возвращаемся на шаг 3.
Именно так выглядят основные этапы жизненного цикла бага. Иногда могут добавляться дополнительные этапы, это вызвано особенностями процессов тестирования внутри фирмы. Неизменным всегда останется то, что баг создается и закрывается (прекращает существование) по различным причинам.
Юзер-стори идеальная, а багов 100500? Как мы тестируем документацию
Зачем и как тестируют документацию? Представьте ту редкую ситуацию, когда в требованиях ошибка или документация составлена неверно. Что дальше? Требование уходит в разработку, программист неверно его истолкует и реализует фичу с искаженной функциональностью. Далее это заметит тестировщик, отправит баг-репорт, который пройдет весь life cycle (пофиксен, проверен, исправлен, закрыт). И это ещё хороший сценарий!
В реальной жизни не все баги исправляют с первого раза, а порой они попадают в прод с печальными последствиями. На вопрос «зачем» ответил. Ответ на вопрос «как» — ниже.
Отношения команды с документацией можно определить, в зависимости от психологической зрелости компании. Как известно, зрелость вовсе не определяется биологическим возрастом – все как в жизни.
Меня зовут Михаил Тимофеев, это моя первая статья, занимаюсь по большей части нагрузочным тестированием в команде Test IT. Нашей компании 2 года, мы разрабатываем систему управления тестированием. Наша система помогает QA-командам работать с ручными и автотестами, привести в порядок тестовую модель, поддерживать и хранить ее в одном месте, упрощает коммуникацию внутри команды. Но это не значит, что мы боги тестирования. Мы тоже люди и совершаем ошибки. Главное — это вовремя их обнаружить и пофиксить =)
Flow тестирования документации
Для нас Agile не равно отсутствие документации. Мы фиксируем все обсуждения с помощью комментариев к уже созданной документации. Поэтому наши записи четко структурированы и отражают суть, что облегчает работу с документацией на регрессе. Мы приняли следующую иерархию документации:
Состав эпика в Test IT
PM, собравшись с мужеством, пишет «Epic» и «User Story»
Эти сущности в Test IT начинается со слова «Хочу», которое является вектором развития ПО. Например: «Хочу иметь возможность импортировать/экспортировать тест-планы», «Хочу переносить тест-кейсы с одного инстанса Test IT на другой» и т.д. Тут можно посмотреть пример нашей стори.
Эпики и стори содержат: требования, юзкейсы и критерии выполнения; задачи, подзадачи и дефекты.
Связка эпика и юзер-стори
Затем QA тестируют User Story на:
Завершенность: User story представляет собой полноценную, логично завершенную новую или усовершенствованную старую функциональность.
Последовательность: Данная User Story логично продолжает развитие «Epic», который она реализует, или закономерно продолжает общее развитие продукта в текущей версии.
Непротиворечивость: Реализуемый функционал не противоречит самому себе, и не противоречит логике работы интегрируемых с ним компонентов ПО.
Атомарность: Каждое требование, описанное в User Story, является целостным и неделимым на подзадачи. Оно само является подзадачей.
Отслеживаемость: Каждая User Story, Task, SubTask, Bug должны быть слинкованы между собой для возможности отслеживания работы по User Story.
Актуальность: Вся информация после обсуждений вносится либо в комментарии, либо правится непосредственно Product Owner.
Недвусмысленность: Перекликается с принципом «Атомарности», каждое требование должно иметь единственную трактовку во избежание двусмысленности и отсутствия понимания.
Обязательность: Каждое требование, описанное в User Story- является обязательным к выполнению.
Проверяемость: Наличие обоснованных и выполнимых критериев завершения задачи. У нас эту роль играет раздел «Definition of Done».
После тестирования юзер-стори пишем Test Cases в соответствии с пунктами Use Case и Definition of Done.
В лучшем случае мы получим с десяток тестов, которые описывают ожидаемое поведение в рамках конкретно разрабатываемой фичи. QA может накинуть еще 5-10 тестов и закончить на этом. А могут проверить самих себя и обратиться к базовым принципам теории тестирования, в частности, к пирамиде.
Пирамида тестирования
Unit у нас их пишут разработчики. И да, на это выделяется на планировании спринта как отдельная задача, и на них уже в самом начале закладывается время.
Components: здесь мы делим процесс тестирования между разработчиком и специалистом QA-отдела. Так мы обеспечиваем быструю обратную связь по разрабатываемой функциональности.
Integration: проводим с отделом разработки. Здесь важно отследить взаимодействие с ближайшими компонентами в системе или с компонентами, на которые влияет данная функциональность.
E2E: для них мы берем информацию из пользовательских сценариев.
Тест кейсы обеспечивают атомарную документацию по конкретной фиче в рамках User Story. На каждый вопрос от члена команды «А что если. » QA может составить минимум один тест. От количества заданных вопросов «А что если. », и уровня профессионализма тестировщика зависит качество выпускаемого продукта, стоимость найденных дефектов и их исправления.
User Story идеальная, а багов +100500
Но бывает, что документация хороша, но баги вылезают. В связи с чем мы получаем увеличенный цикл разработки ПО, перенесенный срок релиза, недовольных заказчиков и при неоднократном повторении, потерю деловой репутации компании на рынке.
В Test IT мы сформировали свой подход к решению подобных проблем.
Майнд-мэп, которая содержит методы реализации, с указанием коллег, в чьей компетенции находятся эти методы.
Feature tester
Специалист, который комплексно работает над задачей. В зоне его ответственности находится: тестирование документации, написание тестовых сценариев, тестирование frontend и backend компонентов. Тесная работа с командой разработчиков в рамках пользовательской истории, которую ему передали в работу в начале релиза.
Контроль качества по пользовательской истории сосредоточен на одном специалисте, как следствие:
Глубокое знание продукта;
Качественные сообщения о дефектах содержащие исчерпывающую информацию со стороны backend и frontend разработки;
Сокращение времени работ по исправлению дефектов;
Постоянное повышение квалификации;
Возможность влиять на юзер-стори на протяжении всего процесса разработки более оперативно и централизованно;
Но есть и минусы, например долгий процесс вхождения в роль, а также его трудно заменить другими специалистами в случае отсутствия. Тем не менее, если мы имеем хорошую документацию, то заменить его уже легче.
Стандартизация US
1. Description — общее описание к US, коротко передаем основную идею.
«Как пользователь, управляющий тестированием на проектах и использующий разные инстансы Test IT, я хочу переносить тест-планы с одного инстанса на другой».
«Администратор Test IT, координатор/руководитель проектов, Тест-менеджер».
«Существует два инстанса Test IT не синхронизированные между собой. Есть потребность частично или полностью перенести тест-планы одного и того же проекта с одного инстанса на другой, с возможностью просмотра что было изменено.»
Возможность импорта/экспорта тест-планов в собственном формате, возможность актуализации тест-планов и кейсов, находящихся в тест-плане с помощью импорта/экспорта.;
Реализовать возможность выполнения импорта и экспорта тест-планов в проекте.
При импорте\экспорте так же подтягиваются кейсы, которые находились в тест-плане, перенос происходит с сохранением структуры секций, а также содержащих названия, описания, системные и пользовательские атрибуты, пред-, пост- условия тестов и секций, и общие шаги.
Реализовать возможность актуализации тест-планов с помощью импорта, с отображением изменений в журнале изменения тестов, истории прохождения тестов и отображением актуальной версии тестов на момент их прохождения.
Test Case
Воспользоваться API для экспорта тест-планов на инстансе 1, указать проект целиком, или конкретные тест-планы,
Воспользоваться API для импорта тестов на инстансе 2, отправить полученную выгрузку,
На инстансе 2 появился проект с секциями и тестами, которые были экспортированы, с сохранением структуры секций. В тест-кейсах содержатся, названия, описания системные и пользовательские атрибуты, пред-, пост- условия тестов и секций, ссылки и общие шаги.
Есть возможность экспортировать тест-планы с помощью API
При экспорте тест-планов есть возможность выбрать проект целиком, либо конкретные тест-планы
При экспорте планов, пользователь получает выгрузку в JSON формате в файле. Файл имеет следующее название: Test IT — <имя_проекта>— <имя_плана>—
Стандартизация по пунктам дает полное понимание разрабатываемой функциональности. Прочитав этот документ, разработчик точно будет знать, кто пользователи и для какой цели им нужна данная фича. Для аналитика, владельца продукта и тестировщика будет сформирована единая сетка требований. Разработчики точно будут знать, куда смотреть во время технической экспертизы при постановке подзадач, а пункты Use Case и Definition of Done позволят лучше понять бизнес-задачи.
Применение паттернов из пирамиды тестирования к юзер-стори
1) юнит-тесты:
Удостовериться в наличии;
2) компонентное тестирование:
Не функциональные требования;
Проектные риски — зная своих коллег, можно заранее прикинуть реальное время на выполнение задачи. Позволит скорректировать время на reject US;
Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.
3) интеграционное тестирование:
Не функциональные требования;
Цели: для чего нужна фича, какие аспекты вашего ПО будут затронуты;
Имидж продукта. Насколько фича отвечает общей концепции, не затрагивает ли общий вектор развития продукта;
Технологии, использованные при создании продукта;
Цели качества (критерии — запрос должен выполняться за 1 секунду);
Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.
4) e2e:
Пользовательские сценарии (примени к каждому сценарию CRUD);
Различные окружения — железо, ОС, приложения, конфигурация, языки;
Процесс внедрения:
Разработать и принять форму написания юзер-стори;
Подход к тестированию: 1 юз.стори = 1 QA;
Разработка тестовых сценариев в соответствии с паттернами тестовых сценариев пирамиды тестирования;
Контроль за покрытием тестовыми сценариями каждой User Story.
Результат:
Стандартизированная документация, в которой легко находить нужную информацию. В юзер-стори указаны бизнес-требования (кому и для чего это нужно), они составлены с учетом возможных сценариев использования, четко определены пункты, которые должны быть выполнены;
Глубокое понимание процессов взаимодействия конкретной фичи с остальным проектом;
Покрытие юзер-стори с учетом различных уровней тестирования. Специалист, только что пришедший на проект, сможет покрыть от 60% юзер-стори тестовой документацией;
Недвусмысленное понимание того, какие именно части юзер-стори покрыты тестовыми сценариями.
Дисклеймер: впервые тема была изложена в рамках доклада на конференции SQADays-28 в апреле 2021 года.
Библиография при подготовке:
37 Sources for Test Ideas, авторы Rikard Edgren, Martin Jansson and Henrik Emilsson
Тестовое покрытие по Бейзеру, автор видео Анастасия Асеева-Нгуен — эксперт по инженерным практикам в Tinkoff Group
Баг и баг репорт
Как Вы думаете, какой навык тестировщика — самый важный?
Может автоматизация тестирования?
Что-то из 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)?
Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.