Баг сайта что это
Список Часто Встречающихся Веб Багов
Еще Канер в своей книге «Тестирование ПО» составил список из 400 ошибок. Однако это было в 1999.
Но многие из них еще актуальны.
Я настоятельно рекомендую тебе их прочитать. Они идут отдельной главой в конце книги.
Я же составил для тебя список наиболее часто попадающихся МНЕ ошибок.
Список привожу ниже. Надеюсь он принесет тебе немало пользы.
Список Часто Встречающихся Веб Багов:
P.S. Надеюсь этот список поможет тебе лучше искать ошибки.
Напиши какие ошибки встречаются тебе. А какие тебе сложно находить или ты их вообще пропускаешь.
Напиши помог ли тебе этот список лучше находить ошибки?
26 комментариев
Спасибо, очень полезно
Спасибо за статью- большая база знаний для того что бы знать где можно еще наткнуться на баги))
Спасибо!
Очень полезная статья!
Большое спасибо!
Очень полезная информация!
Я встречал баг следующего характера. Поле видеоплеера расположено в верхней части страницы. Ниже расположены превьюшки других сюжетов. Список длинный, требующий прокрутки. При клике, например, на последний, начинает воспроизводиться видео (это слышно по звуку), а плеера не видно. Автоматического перемещения (обратной прокрутки) к плееру не происходит.
Спасибо огромное, очень хорошая и полезная статья. Особенно ценно то, что все разложено по полочкам.
Мне лично встречались баги, связанные с регистрацией нового пользователя — не было всплывающей подсказки (надписи в поле), как правильно заполнить активное поле.
Также проблемы с кроссбраузностью. Некоторые браузеры (Google Chrome, к примеру) не поодерживают Java-script и поэтому Клиент-Банк on-line в этом браузере не открывается. Хотя браузер этот весьма популярный.
В Украине на данный момент очень распространен сервис Приват24, при отправке платежных поручений необходимо сначала ввести пароль, потом нажать «Отправить». В Google Chrome пароль невозможно ввести.
На моем рабочем компе есть только Firefox и IE. Google Chrome иногда использую дома, есть еще почта gmail.
Chrome поддерживает javascript.
Через настройки браузера их можно как включить, так и выключить.
Джаваскрипт ещё как поддерживается Chrome!
Вообще советую обратить внимания на джава-скрипт- очень интересный язык, да и тестить сможете глубже) если разберётесь…
Откройте страницу в Джаваскрипт и нажмите сочетание Ctrl+shift+I — увидите консоль и код страницы. Ооочень интересно, если знать, что да к чему относится )
Извиняюсь. Страницу в Chrome откройте ) И потом curl+shift+I и будет вам Джаваскрипт в консоли…
Любовь, Google Chrome не поддерживает Java, поэтому и проблема с Клиент-банком. Вот https://www.java.com/ru/download/faq/chrome.xml
Спасибо, статья очень полезная и позновательная )
Большое спасибо за статью. Мне в интернет-магазине попадался такой баг: хотела выбрать определенный товар, его небыло в наличии, я выбирала другой товар, при этом мне предлагалось обратить внимание на такие товары, и в перечне был тот, которого нет в наличии.
Думаю мы все простим небольшие опечатки) У нас все таки не клуб по грамматике.
Спасибо огромное. Конечно не хватает видео и практики. Сам тестирую часто игрушки и веб сайты. Как уже говорилось багов много находиться в кроусбраузерном тестировании, а именно в internet Explorer.Часто встречаются ошибки локализации, но как и все тестировщики в первую оччередь стараюсь уделить время функциональному тестированию. Так как проверка функционала одна из самых важных видов тестирования.
Как не надо заводить баги. Часто встречающиеся ошибки
Всем привет. Меня зовут Дарья и я – специалист по контролю качества программных продуктов компании «Ренессанс страхование», а проще говоря – тестировщик. «Ренессанс страхование» — не первое мое место работы тестировщиком. Я расскажу о том, как не надо делать, то есть на подробно, на примерах, распишу наиболее частые ошибки при заведении бага.
Сначала я опишу два примера багов из реальной жизни, которые меня ужаснули, а потом перейду к советам, как не надо делать. Все примеры, которые привожу в статье, взяты мною с предыдущих мест.
непонятно:)
Бывает так, что нам, тестировщикам, кажется очевидным и простым – для других сотрудников не так, ведь они одновременно работают с различными системами. Им из-за неудовлетворительного качества бага придется потратить время на уточнение, о чем вообще идет речь (какой продукт, какая среда, какая система и тд).
«При кодировке UTF 8 русские слова переносятся кракозябрами»
милая ккракозябра
Единственное, что хочется сказать после прочитанного – кракозябра вполне может быть милой:). Да, в настоящее время IT-специалисты, понимают, что хотел сказать автор данного бага. Но тут уже возникает вопрос отношения к коллегам и работе. Неужели нельзя затратить чуть больше времени и вместо «панибратских» выражений технически грамотно описать проблему?
Самое горькое и печальное – это последующие коммуникации по подобным багам с краснеющим от стыда лицом. Еще хуже – краснеть перед разработчиками и аналитиками за баг, который перешел к тебе «по наследству» от уволившегося тестера. Объяснять, что это не мое – «меня заставили» – последнее дело, зачастую всем абсолютно все равно, но при этом каждый коллега по такого рода багам предопределяет уровень «горе-тестировщиков». Подобные случаи встречаются очень часто и, к сожалению, влекут за собой немало неприятных последствий, а именно:
подрыв репутации конкретного тестировщика и всех тестировщиков компании;
занижение значимости процесса тестирования;
дискуссии о том, что тестировщики – лишнее звено в процессе (вроде их цель находить и оформлять баги, а они и этого не могут сделать по-человечески);
появление разговоров о том, что тестирование – это проще некуда – горе-тестировщик смог, значит, и обезьяна сможет.
Ни в коем случае не хочу обидеть или запугать людей, которые только собираются окунуться в тестирование. Лично для меня тестирование – это безумно интересный и сложный мир, в котором нет места халяве и выполнению задачи на «абы как». Поэтому мне очень хочется, чтобы тестировщик следил за уровнем выполняемой работы. А уж к заведению багов вообще относился как к «святая святых».
Поэтому я решила написать памятку: «Как не надо заводить баги. Или часто встречаемые ошибки»:
1. Работа на скорость
Скорость хороша в спорте, в тестировании же стоит уделять внимание качеству. Представим следующую ситуацию: один тестировщик завел 50 багов, но по 30 из них нужны коммуникации и уточнения, а 15 можно вообще закрыть, т.к. это и не баги вовсе, а фичи или особенности, которые можно изменить в настройках браузера. Другой тестировщик завел 15 информативных багов, которые можно сразу брать в работу без отклонений и уточнений. На чьей стороне будет «победа»? Мне кажется, ответ очевиден?.
2. Отсутствие конкретики
В дополнение к первому пункту: баг должен быть понятен разработчику настолько, что у него не возникнет необходимости писать вам и задавать дополнительные вопросы.
3. Использование сленга при формулировке бага
Как уже говорилось в примере про «крокозябру»: если не хватает технической грамотности, Гугл в помощь. В противном случае, в глазах коллег вы будете олицетворять мальчугана с картинки: смешно и нелепо.
4.Пренебрежение примерами и скриншотами
Этот широкий жест не будет лишним и сэкономит много времени для скорейшего закрытия задачи.
P.S. Не стоит путать: скрин – нужное и дельное дополнение, но не полное описание бага. Скрин не должен заменять описание.
5. Своевременный перевод бага на разработчика
Гораздо приятнее, чтобы разработчики увидели актуальную на текущую дату и четко описанную версию бага. Это избавит от лишней траты.
6. Актуализация критериев приёмки
Условия игры могут меняться прямо во время тестирования. А зачастую и не единожды. Обсуждения могут происходить не только на общих встречах со всеми коллегами. Есть также официальная и неофициальная переписка, обсуждения по телефону, комментарии в задаче в баг-треккере и в различных мессенджерах. И тут уже сотрудникам хочется быстрее дойти до истины, и часто никто не дублирует в режиме реального времени в задачу и не актуализирует критерии приемки.
Прежде чем закрыть любую задачу (заведенный вами баг или тестируемую задачу по новому функционалу), было бы здорово потратить немного времени и, пока все свежо в памяти, собрать «крайнюю» информацию из всех источников (документация, коммуникации с коллегами, чаты, телефония) и изложить ее в критериях приемки.
Да, хочется сказать, что подобная работа – зона ответственности аналитика, но, основываясь на своем опыте, могу утверждать, что по весомым причинами или по невнимательности аналитики редко вернутся к закрытой задаче.
Ведь тестировщик через какое-то время, успешно забыв тестируемый функционал, может столкнуться с задачей, которая повлечет за собой проведение регресса. И вот тут тестировщик вместо того, чтобы тратить время на выяснение, где же актуальная информация и кому верить, сможет сразу приступить непосредственно к своим обязанностям.
7. Заведение «псевдобагов»
Под «псевдобагами» я подразумеваю особенности тестовой среды или параметры, которые можно отключить в настройках браузера.
Из банальных примеров – при входе на страницу авторизации логин и пароль предлагаются автоматически. Это устранится очисткой cookies. Другой пример – кроссбраузерность. В одном браузере картинка четкая и на экране отображается прекрасно, в другом браузере – поля наезжают друг на друга. Возможно, дело в масштабе? Прежде чем бить панику, стоит сначала убедиться, что установка одинакового масштаба в обоих браузерах не устранит проблему.
8. Изменение ожидаемого результата
Бывают случаи, когда тестировщику не хватило информации для полного понимания процесса (отсутствие или наличие недостаточной/ слабый анализ). И может возникнуть такая ситуация, что через какое-то время после заведения бага выяснится, что ожидаемый результат, который вы указали, неверный. Он должен быть другим. И вот тут начинается самое интересное: тестировщик, чтобы замести следы «преступления» удаляет описание ожидаемого результата или (что еще хуже) начинает препираться с разработчиком, что подразумевалось другое.
Другая жизненная ситуация – заведение бага без ожидаемого результата. В таком случае надо пенять на себя и осознавать, что разработчик поправит так, как он поймет из описания. И далеко не факт, что правка будет совпадать с тем, чего вы ожидали. И отклонять решенную задачу с претензией, что вы ожидали «чего-то другого» будет непрофессионально. Поэтому все свои ожидания и пожелания надо обязательно указывать в критериях приемки.
9. Неумение отличить фронт от бэка
Одним из важных критериев при заведении бага является умение отличить, к какой части сервиса относится баг – к фронтенду или к бэкенду.
Пример: в поле не работает валидация. Баг задублировался и пришел и к фронтовым, и к бэкендовым командам. Обе команды тратят время и ресурсы на то, чтобы поправить баг.
В случае, если тестировщик самостоятельно не может определить – лучше обратиться за помощью к коллегам: другим тестировщикам, тим-лиду, разработчикам. Ответ обязательно найдется, ресурсов будет затрачено меньше, баги не задублируются, засоряя баг-трекинговую систему. Все счастливы.
10. Работа с логами
Тестестировщик должен уметь работать с логами, чтобы определить и понять, что за ошибка произошла, где конкретно она воспроизводится (в какой системе, при каком переходе). Относится ли баг к тестируемой системе или вызван другими внешними системами. При заведении бага следует прикладывать ссылки на логи с целью уменьшения экономии времени.
бывает и так
Работа тестировщика напрямую и неотъемлемо связана с багами: мы их обнаруживаем, заводим в баг-трекинговые системы, контролируем их устранение. Поэтому очень важно правильно их заводить, ведь без них никуда. Баги –жизненно необходимый орган в процессе системы. Постарайтесь внимательнее их заводить, тогда всем станет лучше.
Баг и баг репорт
Как Вы думаете, какой навык тестировщика — самый важный?
Может автоматизация тестирования?
Что-то из 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)?
Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.