типы багов в тестировании

Баг и баг репорт

Как Вы думаете, какой навык тестировщика — самый важный?

Может автоматизация тестирования?

Что-то из 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)?

Серьезность характеризует уровень влияния бага на работоспособность приложения / компонента и необходима для дальнейшего проставления приоритета.

Источник

Отчеты о дефектах. Приоритет и Серьезность.

Для начала рассмотрим каждый атрибут в отдельности.

Серьезность

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.

Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).

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

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

1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.

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

У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.

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

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

2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.

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

Приоритет

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

Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.

С помощью приоритета менеджер проекта говорит, когда стоит исправить найденную проблему.

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

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

Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:

Матрица определения приоритета

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

Различия Серьезности и Приоритета

Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.

Источник

ТОП-10 ошибок тестировщиков, что приводят к блокерам

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

Кто-нибудь заведёт

Что значит: заметить баг и не завести на него тикет или не убедиться, что он заведён. Чаще всего думают так: «явный баг, кто-нибудь заведёт» или «100% на это есть тикет».

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

Чтобы не стать жертвой этой ошибки нужно:

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

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

N-багов в одном тикете

Что значит: несколько багов объединяют в один при условии схожести, общности шагов и прочим «справедливым условиям». Иногда даже менеджеры, лиды разработки просят завести один на все.

К чему приводит: чинят один, другие остаются. Тратится время на сборку, тест, возврат на починку и нормальное переоформление. Это приводит к сдвигу релиза, переработкам, ухудшению качества тестирования.

Как увидеть: множество несоответствий в фактическом результате, например: «фактический результат: съехала кнопка, текст не соответствует действию, возвращается 500-код по клику».

Как бороться:

Мелкие баги графического интерфейса или функциональные можно объединить в одном баге. Например, «цвет кнопки серый и текст съехал» или «в json нет timestamp и date приходит пустой». Но лучше так не делать. Особенно когда ты новичок или проект только начался (можешь не все понимать, лучше завести и закрыть после).

Артефакты в публичном доступе

Что значит: сохранять скриншоты, скринкасты с незарелизенным функционалом в открытом доступе, не ограничивать доступ к ТЗ в гугл-доках.

К чему приводит: в СМИ появляется инсайдерская информация, убытки компании, сорванный проект, обида команды.

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

Как бороться:

В настройках любого ПО проверять не сливаются ли файлы в общий доступ

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

Искусственное тестирование

Что значит: тестировать на искусственных данных позабыв про использование реальных или похожих на реальные.

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

Запуск проекта или релиз новой версии без тестирования на проде это очень редкий кейс, но если имеет место, то часто функционал не запускается (не те пути к базам, нет доступов у пользователей и т.п.)

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

Как бороться: при выборе техники тест-дизайна закладывать в кейсы реальные данные. Обязательно разработать или указать в существующем регламенте выкатки в прод, тестирование на проде.

Тестировать в проде

Что значит: значит проходить тестовые кейсы в продовом окружении и оставлять после себя артефакты, который могут увидеть пользователи. Например, тестируешь интернет-магазин и оставляешь после себя товары с названием «Тестовое тесто».

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

К чему приводит: в лучшем случае никто не увидет или увидит забавную карточку товара, а в худшем засветишь тестовые данные учеток или испортишь внешний вид сайта.

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

Как бороться: есть много способов:

создавать виртуальные машины с соответствующим окружением,

создание профилей для продовой и тестовой среды,

давать права тестированию только на чтение в проде,

разворачивать тестовую среду на отдельных URL, серверах и т.п.

Боятся задать вопрос

Что значит: не спросить побоявшись выглядить глупым.

К чему приводит: функционал не протестирован полностью, пропущены критичные баги.

Как увидеть: считаю что есть 2 основные причины

Коллеги считают что ты должен все знать

Нет 100% уверенности в правильности понимания задачи

Как бороться:

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

Бояться задать вопрос еще раз

Слепо верить ТЗ

Что значит: баги документации (логические несоответствия, противоречия, недоработки и т.п.).

К чему приводит: откладывается релиз, блокеры и криты в проде и т.п.

Как увидеть и бороться: про то, как тестировать ТЗ поговорим в следующих постах, поэтому подписывайся и обсудим.

Тестировать в перчатках

Что значит: не оставлять комментариев, артефактов после закрытия тикетов.

Как увидеть: после закрытия тикета или перевода в протестирован пробежаться по своим комментариям. Если их нет, то нужно оставить.

Как бороться: если есть возможность в баг-трекинговой системе настроить запрос обязательного комментария при закрытии тикета.

Использовать только исследовательское тестирование

Что значит: не применять другие техники тестирования.

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

Как увидеть: при тестировании изучаешь продукт, т.е. нет четких кейсов с ожидаемым результатом.

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

Поддержите развитие блога подпиской, лайком, комментарием на Дзене или если удобней в телеграме.

Источник