что такое fixed version у дефекта

говориМ о тестировании
простым языком

Основы тестирования. Жизненный цикл бага

Какой же путь проходит баг и какую роль в его жизненном цикле играет тестировщик? Давайте разбираться.

Ошибка, дефект, но чаще всего баг. Именно так называется то, что находят тестировщики в процессе работы.

Определение бага

Bug в переводе означает “жук, насекомое”. Первая ошибка, которая была задокументирована, возникла как раз из-за жука. В середине 40-х годов 20 века ученых Гарвардского университета вызвали для того, чтобы определить причину сбоя в работе вычислительной машины Mark II. Покопавшись в этой громадной куче приборов, соединенных проводами, они обнаружили бабочку, застрявшую между контактами электромеханического реле. Стало ясно, что именно она и явилась причиной сбоя. Одна из сотрудниц университета, Грейс Хоппер, так и сформулировала результат исследований: «неполадку вызвал баг». Извлеченное насекомое было вклеено скотчем в технический дневник, с соответствующей сопроводительной надписью. Ее, как говорят, до сих пор можно увидеть в этом журнале, хранящемся в университетском научном музее.

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

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

Баг в программе не появляется просто так, у него всегда есть источник. Например, ошибка программиста при написании кода. Дефекты встречаются, потому что люди склонны ошибаться, существует нехватка времени, сложность кода, сложность инфраструктуры, изменения технологий и/или много системных взаимодействий.

Что еще интересно, что программ, не содержащих ошибок, не бывает. По статистике на каждую тысячу строк программного кода, который пишут программисты, приходится несколько ошибок, а количество строк в сложном программном обеспечении достигает нескольких миллионов. Поэтому поиск и исправление этих ошибок – очень трудоемкое дело, составляющее до 45% всех затрат на разработку программного обеспечения.

Жизненный цикл бага

Давайте вкратце разберем каждый этап жизненного цикла

Данную схему можно изобразить в текстовом виде. Вот несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании):
1. Новый (new) —> Отклонен (rejected) —> Закрыт (closed)
2. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed)
3. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed) —> Переоткрыт (re-opend)

Жизненный цикл бага с точки зрения команды

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

Сначала тестировщик находит баг. Далее заносит его в систему учета ошибок. После этого программист начинает изучать отчет о дефекте. Именно на этом этапе он решает баг это или нет.

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

Если баг больше не воспроизводится, то тестировщик закрывает баг.
Если баг снова воспроизводится, то мы возвращаем его программисту. И снова проходим все шаги, начиная с 3-го шага (рассмотрения проблемы программистом).

Теперь другой сценарий — разработчик не принял баг. Если баг не принят, то разработчик возвращает его нам. Наша задача — рассмотреть проблему. Если баг вернули из-за некорректного описания, то значит переписываем его. Если невозможно воспроизвести дефект, то заново проверяем все шаги, может мы что то упустили при описании. Если разработчик прав и бага нет, то мы закрываем баг. А если баг все же есть, то вносим необходимые коррективы и опять возвращаемся на шаг 3.

Именно так выглядят основные этапы жизненного цикла бага. Иногда могут добавляться дополнительные этапы, это вызвано особенностями процессов тестирования внутри фирмы. Неизменным всегда останется то, что баг создается и закрывается (прекращает существование) по различным причинам.

Источник

Стиль ведения дефектов

Предисловие

Участвуя в разработке программного обеспечения, видел, что при написании кода программисты обычно задают стандарт оформления кода (codestyle) — следование определённым практикам, призванным улучшить жизнь программистов. Моя роль в разработке программного обеспечения заключалась в тестировании. В качестве одной из своих обязанностей, как тестировщик, я видел производство информации о качестве программного обеспечения. В качестве одной из классификаций, эту информацию можно было поделить на позитивную и негативную. Позитивная информация обычно заключалась в том, что ожидаемое поведение совпадало с действительным, и результаты тестирования можно было предоставить в виде данных в отчете о тестировании (фича 1- работает, сценарий 2 – работает, и т.д.). А вот негативная информация чаще всего производилась и оформлялась в виде дефектов. (конечно же, бывали и другие рабочие элементы, такие, как риски, запросы на изменение, и др.)

Встречал внутри проектов ведение базы знаний (не только дефектов), ориентированное на то, чтоб его «раз-раз и в продакшн». Прямо как у дорожных рабочих – сдать объект, а потом будь что будет.

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

Обычно дефект включает в себя:

1. Название
2. Критичность
3. Описание: Информация о стенде, шагах воспроизведения, фактическом и ожидаемом результате.

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

О том, из чего состоит дефект и и базовых правилах оформления, таких, как задавать наименование дефекта, отвечающее на вопросы «Что, где, когда?» на просторах интернета и в том числе на самом хабре встречал много статей. Здесь хочу поделиться опытом, полученным собственноручно.

1. Название должно отражать суть проявления дефекта на прикладном уровне

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

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

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

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

Когда проект маленький и вы являетесь единственным тестировщиком (возможно, сочетая и другие обязанности, например, программиста), дефекты можно оформлять как заблагорассудится. Но когда вы работаете в команде – требуется иной подход. Когда живете один в доме — можно не мыть посуду, не укладывать вещи на свои места и т.д. А когда живете в большой семье – стоит относиться с уважением к тому, что другие члены семьи захотят видеть чистоту и порядок.

Касаемо стенда:

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

3. Описание дефекта не должно содержать не относящейся к нему информации

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

4. Описание дефекта должно содержать достаточное для воспроизведения количество информации

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

Следует учитывать, что члены команды в проекте периодически меняются. По моим наблюдениям люди работают над одним и тем же проектом, не меняя его и не переключаясь на другие, порядка 2-х лет. Следует учитывать эффект грузовичка. Еще бывает так, что в компании несколько тестировщиков, и стоит предусмотреть, чтоб при уходе в отпуск другие тестировщики могли перепроверить этот дефект.

5. Базу дефектов в багтрекере стоит вести с расчетом на перспективу

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

Стоит учитывать, что даже после закрытия дефекта он может кому-то понадобиться. Ориентировочная цифра перспективы– 2 года.(ориентировочный расчет).

Например, когда рабочие меняют окна в подъезде, бывает так, что они экономят время и усилия на выносе мусора. Вроде мусор проходу не препятствует, жители спокойно ходят. И ресурсы сэкономлены. НО: через некоторое время наступает момент, когда мусор начинает мешать. А если случится пожар (релиз или еще какое мероприятие), то начинаются неприятности.

Например, какой-то старый дефект всплывает у пользователей (или будет новый, симптомы которого будут совпадать со старым), из-за этого у компании возникает ущерб. Начинают выяснять детали. И если дефект был оформлен как попало, то владельцы явно не будут в восторге от работы тестировщика.

Много раз замечал, что тестировщики при описании дефекта ориентируются на то, что он будет исправлен командой в тот же день. Примерно с 80% дефектов так и происходит –они исправляются на ходу и становятся мало кому нужны. Но вот порядка 20% дефектов продолжают существовать, причем порядка половины оставшихся — в течение достаточно большого промежутка времени. За это время состав команды, работающей над продуктом, претерпевает изменения. И когда новые члены команды начинают работать, то разбор и воспроизведение существующих дефектов начинает занимать очень много времени. На актуализацию каждого дефекта без адекватного описания, даже зная продукт на уровне документации, может уходить уйма времени.

Приведу грубый расчет. Помню, что за 8-часовой рабочий день мне удавалось актуализировать около 5 дефектов без описания. Если бы тестировщики при заведении дефектов тратили дополнительно по 5 минут на каждый заведенный дефект, делая описание подробнее, то на заведение 100 дефектов ушло бы дополнительно 500 минут = порядка 1 рабочего дня. Из этих 100 дефектов порядка 20 останутся незакрытыми в течение достаточно большого количества времени. На их актуализацию при расчете 5 дефектов/день может уйти порядка 4 рабочих дней.

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

Когда над проектом работает 1-2 программиста, обычно каждый полностью знает весь функционал. Но когда над проектом работает, скажем, 10 программистов – то каждый хорошо знает лишь тот функционал, в который он вносил изменения. И не стоит заставлять программистов изучать поведение незнакомого для них функционала. У них с лихвой достаточно задач по реализации нового функционала.

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

Часто бывает, что важные детали дефекта выявляются уже после его оформления. Их добавляют где-то в комментариях к дефекту. Выгодно актуализировать информацию о шагах воспроизведения в описании дефекта. Особенно если дефект имеет отношение к нескольким командам. Не стоит заставлять всех перечитывать комментарии и вникать в них.

8. Если к дефекту требуется прикрепить много файлов, то перед этим удобно задавать им имена, начинающиеся с цифр

Впоследствии, при обсуждении, вложения могут добавляться, их количество может вырастать до десятков. Удобно оперировать указанием на вложения, например: на скриншоте 15… использовать скрипт из вложения 7… см. сообщение в логе архива 25.

9. Стоит отмечать в описании дефекта информацию о частичных исправлениях

Если в одном дефекте собрана информация о нескольких схожих ошибках, например, в описании присутствует:

Ошибка выводится в браузерах:

1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari

После работы над дефектом выявляется, что дефект исправлен лишь частично, то выгодно актуализировать в нем информацию, не удаляя старое, а используя перечеркнутый шрифт:
Ошибка после исправления 0.1.01.2018 выводится в браузерах:

1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari

10. В компании стоит определиться со стандартом критичности дефектов

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

11. Дефекты следует заводить как можно быстрее

Своевременность заведения дефектов – немаловажное дело. Чем быстрее они будут заведены – тем скорее и лучше будут исправлены. И тем меньше вероятность пропустить что-то критичное в продакшн. После просмотра заведенного дефекта другими участниками команды может выявиться, что критичность выше, чем кажется на первый взгляд.

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

12. Не следует игнорировать мелкие дефекты, стоит оформлять их в багтрекере

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

Когда продукт маленький – мелкие дефекты не очень сильно заметны. Но когда продукт становится большим — сценарии более емкими – наличие мелких дефектов начинает донимать.
Можно привести такую аналогию: представим небольшой населенный пункт, например, деревню из двух улиц, на перекрестке которых одна маленькая ямка с грязью. Вроде на каждом (единственном) перекрестке яма, но передвигаться по деревне легко, просто объезжая всякий раз эту яму. И она мало кому мешает. Проходит время. Населенный пункт увеличивается до города-милионника. На каждом перекрестке по ямке с грязью. Если ездить по такому городу на работу через часть-города – то передвигаться, объезжая по одной ямке на каждом перекрестке, станет уже далеко не так комфортно. И возникнет большое желание перебраться в другой город или переизбрать администрацию города. Аналогично с программными продуктами – следует способствовать тому, чтоб у пользователей было желание в них работать, вместо желания удалять.

13. Если дефект был заведен кем-то помимо тестировщика, то при необходимости стоит его подкорректировать

Другие члены команды тоже заводят дефекты. И они вовсе не обязаны быть знакомы с деятельностью тестировщика, у них может быть дополна своих дел. База дефектов – одно из владений тестировщика, подобно тому, как система хранения кода – владения программистов.
Если вы, будучи тестировщиком, видите, что дефект на ваш продукт заведен не совсем корректно, то стоит подкорректировать его. Подобно тому, как стоит поддерживать порядок у себя в доме, складывая вещи на свои места, если гости поставили что-то не туда.

Источник

Жизненный цикл “бага”

Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла:

Использование данных отчета о дефекте

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

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

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

Атрибуты отчёта о дефекте

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

Свойства качественных отчётов о дефектах

Отчёт о дефекте может оказаться некачественным (а следовательно, вероятность исправления дефекта понизится), если в нём нарушено одно из следующих свойств:

Логика создания эффективных отчётов о дефектах

При создании отчёта о дефекте рекомендуется следовать следующему алгоритму:

Типичные ошибки при написании отчётов о дефектах

Ошибки оформления и формулировок:

Логические ошибки:

Источник

Как составить безупречный баг-репорт?

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

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

Баг-репорт содержит ответы на следующие вопросы:

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

Разберёмся, как добиться этого сочетания.

Как выявляют баги?

Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:

Идеальный сценарий ― первый, когда дефекты выявляются до релиза специалистами по обеспечению качества. Но иногда до начала составления баг-репорта тестировщику приходится изучать чужой опыт взаимодействия с ПО при появлении ошибки.

Какой инструмент используют для документирования дефектов?

Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.

Студенты QA Academy уже на базовом курсе получают необходимый багаж знаний для эффективной работы с JIRA, а в этой статье мы подробно рассказали, как прокачать своё мастерство поиска в этой баг-трекинговой системе.

Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.

Каких правил придерживаться при написании баг-репорта?

Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.

Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.

Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.

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

Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.

Если всё в порядке, можно переходить к описанию.

Из каких элементов состоит баг-репорт?

Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:

Summary (заголовок)

Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Что? Где? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.

Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:

«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».

При тестировании мобильных приложений важно внести и название платформы, iOS или Android.

Заголовок готов. Можем двигаться дальше.

Description (описание)

Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:

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

«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».

Actual/expected result (фактический/ожидаемый результат)

Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.

Пример заполнения данного раздела:

«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».

Attachments (вложения)

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

Priority (приоритет)

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

Системы определения важности могут отличаться, но скорее всего вы встретитесь с подобной градацией:

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

Severity (серьёзность)

Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.

Status (статус)

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

Такими являются основные элементы баг-репорта, с которыми приходится встречаться чаще всего. Но в отчёте могут содержаться и дополнительные поля:

Резюмируем

Написание баг-репорта ― важный элемент QA-процесса, который позволяет ускорить устранение дефекта и подготовить качественное ПО к выходу на рынок. До начала написания документа важно:

Хороший отчёт об ошибке написан простым и понятным языком, содержит максимум полезной информации. Ключевыми атрибутами баг-репорта являются заголовок, описание, приоритет и статус ошибки. Стоит придерживаться порядка написания отчёта и заполнять все поля в зависимости от особенностей трекинговой платформы и требований проекта.

Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!

Источник