Что такое дефект в тестировании

Словарь тестировщика

Баг (bug, дефект) — отклонение фактического результата (actual result) от ожидаемого результата (expected result).

Если проще, то это ошибка.

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

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

◆ Пример из работы.
Возьмем форму авторизации на сайте. Мы ожидаем, что введя в поле “Имя” и в поле “Пароль” те данные, под которыми мы регистрировались, произойдет вход в систему. Если этого не случается, то мы имеем дело с багом.

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

Если проще, то это процесс проверки работоспособности продукта и его пригодности к использованию. То есть это не просто поиск багов.

◓ Пример из жизни.
Нам дали на проверку кружку. Что мы будем делать? Сначала продумаем, как именно ее можно проверить и набросаем себе план. И только затем присудим к делу. Осмотрим ее снаружи, проверим на трещины, оценим качество рисунка. Уроним ее на пол, чтобы проверить на прочность. Нальем в нее холодную воду, теплую, кипяток, чтобы посмотреть не лопнет ли она. Возьмем ее в руки, оценим, удобно ли держать. После расскажем о результатах нашей работы создателю кружки.

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

◆ Пример из работы.
Есть задача проверить корзину покупок. Опять же начинаем с планирования. Мы пробуем положить в нее товар, удалить, изменить количество, оцениваем удобство и так далее. После заносим все найденные баги в специальные документы (баг-репорты) и отправляем разработчику (программисту).

Обычно тестирование осуществляется на основании документации, но не всегда.

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

Если проще, то это то, что пишет заказчик, когда хочет получить продукт.

◓ Пример из жизни.
Тесть решил построить дом для тещи и нанял для этого зятя (мужа дочери), который как раз работает инженером. У тестя есть свое видение этого дома. Он рисует и описывает его своими словами и передает мужу.

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

Спецификация (specialization, спек) — детальное описание того, как должно работать ПО.

Если проще, то это описание технических свойств своего продукта (размеры, различные параметры, материалы, функции, etc).

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

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

(!) Все что не соответствует ТЗ и спецификации как раз и будет багом.

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

Если проще, то это документ, в котором мы фиксируем найденный баг.

◓ Пример из жизни.
Вернемся к нашему забагованному прогнозу погоды. Что делать? Кому и как сообщить, что погода-то совсем не такая, как говорят? Надо просто написать отчет. Причем написать так, чтобы они поняли про какой именно район речь и что именно с этой погодой не так.

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

Система отслеживания ошибок (bug tracking system) — программа учета и/или контроля багов.
Ее обычно называют баг-трекер или баг-трекинг.

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

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

Пофиксить — внести изменения, а именно исправления, в код программы.

Если проще, то это правка.

◓ Пример из жизни.
Жена сломала дверцу шкафа. Пошла к мужу, привела к дверце за руку, все показала (считайте, что предоставила баг-репорт с прикрепленным видео). Муж сел, там покрутил, тут постучал и дверца опять начала работать как положено. То есть муж исправил (пофиксил) шкаф.

◆ Пример из работы.
Мы создали баг-репорт и отправили в наш баг-трекер. Разработчик взял баг-репорт в работу, изучил его и внес изменения в код. То есть он исправил (пофиксил) код так, чтобы в продукте больше не было бага.

Билд — версионированная сборка программного обеспечения.

Если проще, то это продукт или кусок продукта, который можно тестировать.

◓ Пример из жизни.
Зять строит дом для тещи. Уже готов каркас и пару комнат. Эти комнаты уже можно показать жене на проверку. Именно эти пару комнат, которые ей уже можно смотреть и оценивать — это и есть билд, который будет тестировать жена.

◆ Пример из работы.
Разработчик создает продукт. Часть кода уже написана и готова к проверки. Именно эту часть он и отдает тестировщикам на проверку.

Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.

Если проще, то это продукт, который видит конечный пользователь.
Можно сказать, что релиз — это билд, который команда разработчиков предоставляет наружу.

◓ Пример из жизни.
Зять закончил строить дом для тещи. Жена все протестировала. Теперь можно привозить тещу и поздравлять ее с новосельем. То есть готовый дом — это и есть релиз.

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

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

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

Принципы тестирования

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

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

Этапы тестирования:

Программный продукт проходит следующие стадии:

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

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

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

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Градация Приоритета дефекта (Priority):

Тестовые среды

Основные фазы тестирования

Основные виды тестирования ПО

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

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.

Тест план должен отвечать на следующие вопросы:

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

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям.

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Принципы тестирования

Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

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

Этапы тестирования:

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

Требования

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

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — это документ, описывающий ситуацию, которая привела к обнаружению дефекта, с указанием причин и ожидаемого результата.

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

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Тестовые среды

Основные фазы тестирования

Основные виды тестирования ПО

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

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Типы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:
– тестирование, основанное на анализе внутренней структуры компонента или системы;
– тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

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

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

Тестовая документация

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Основные пункты тест плана:

В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:
a) Идентификатор тест плана (Test plan identifier);
b) Введение (Introduction);
c) Объект тестирования (Test items);
d) Функции, которые будут протестированы (Features to be tested;)
e) Функции, которые не будут протестированы (Features not to be tested);
f) Тестовые подходы (Approach);
g) Критерии прохождения тестирования (Item pass/fail criteria);
h) Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
i) Результаты тестирования (Test deliverables);
j) Задачи тестирования (Testing tasks);
k) Ресурсы системы (Environmental needs);
l) Обязанности (Responsibilities);
m) Роли и ответственность (Staffing and training needs);
n) Расписание (Schedule);
o) Оценка рисков (Risks and contingencies);
p) Согласования (Approvals).

Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.

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

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Источник

Русские Блоги

Дефекты в тестировании ПО

Определение дефекта

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

Есть ошибки в коде или аппаратной системе

Интеллектуальная рекомендация

URL-тур

URL-тур Во всем процессе он может быть примерно разделен на следующие процессы. DNS-анализ домена TCP соединение HTTP-запрос Запрос процессов Возвращает ответ HTTP Рендеринг страницы Выключить соедине.

Руководство по обзору кода на основе GitLab

Luo Valley P3809 (вопросы массива суффикса)

phpMyAdmin сообщает об ошибках на главной странице

[Феномен]: phpMyAdmin сообщает о фатальной ошибке: необученная ошибка: вызов неопределенной функции mb_detect_encoding () [Анализ причины]: На этой домашней странице следует подумать, открыты ли библи.

Что такое алгоритм фильтра Блума?

Нажмите вышеСинее словоУстановить звезду Начнем сегодняшнее исследование

Вам также может понравиться

JQuery писать HTML-шаблон

Введение в сцену Данные ajax, возвращаемые из фона, должны быть заполнены в li, а затем вставлены в ul случай Возврат данных в фоновом режиме Поскольку только jq не имеет сторонних плагинов, я временн.

Список типов исключений Python

https://blog.csdn.net/TskyFree/article/details/48630817 1. NameError: Попытка получить доступ к необъявленной переменной 2. ZeroDivisionError: делитель равен 0 3. SyntaxError: Син.

Глубокое понимание структуры файлов виртуальной машины Java и механизма загрузки типа виртуальной машины

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

Essential Phone очень сложно ремонтировать iFixit советует не покупать его!

Essential Phone, запущенный «отцом Android» Энди Рубином, запустил собственный портал, который изначально считал, что может конкурировать с «детскими» телефонами Google. Неожид.

Язык C-три способа имитации функции strlen

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

Источник

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

Предисловие

Участвуя в разработке программного обеспечения, видел, что при написании кода программисты обычно задают стандарт оформления кода (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. Если дефект был заведен кем-то помимо тестировщика, то при необходимости стоит его подкорректировать

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

Источник