На сложность ошибок не влияет

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

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

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

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

Почему требуется тестирование ПО?

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

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

• Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects). Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но не гарантирует их отсутствия.
• Принцип 2 — Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible). Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
• Принцип 3 — Раннее тестирование (Early testing). Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки ПО или системы, и должны быть сфокусированы на определенных целях.
• Принцип 4 — Скопление дефектов (Defects clustering). Разные модули системы могут содержать разное количество дефектов – то есть плотность скопления дефектов в разных частях кода может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей.
• Принцип 5 — Парадокс пестицида (Pesticide paradox). Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
• Принцип 6 — Тестирование зависит от контекста (Testing is concept depending). Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
• Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

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

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

• проверка готовности ПО к релизу;
• проверка соответствия требований и качества данного проекта.

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

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

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

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

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

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

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

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

1. Проектная документация — включает в себя всё, что относится к проекту в целом.
2. Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.

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

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

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

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

1. анализ требований к проекту;
2. проектирование;
3. реализация;
4. тестирование продукта;
5. внедрение и поддержка.

Требования

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

Требования к требованиям:

1. Корректность — каждое требование должно точно описывать желаемый функционал.
2. Проверяемость — требование должно быть сформулировано так, чтобы существовали способы однозначной проверки, выполнено оно или нет.
3. Полнота — каждое требование должно содержать всю информацию, необходимую разработчику, чтобы правильно спроектировать и реализовать требуемую функциональность.
4. Недвусмысленность — требование описано без неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание.
5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность — приоритет требования представляет собой количественную оценку степени значимости (важности) требования.
7. Атомарность — требование нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
8. Модифицируемость — характеризует простоту внесения изменений в отдельные требования и в набор требований.
9. Прослеживаемость — у каждого требования должен быть уникальный идентификатор, по которому на него можно сослаться.

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

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

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

1. Уникальный идентификатор (ID) — присваивается автоматически, может содержать в себе данные о требовании, на которое ссылается дефект.
2. Тема (краткое описание, Summary) — кратко сформулированная суть дефекта по правилу «Что? Где? Когда?»
3. Подробное описание (Description) — более широкое описание сути дефекта (при необходимости).
4. Шаги для воспроизведения (Steps To Reproduce) — последовательное описание действий, которые привели к выявлению дефекта (которые нужно выполнить для воспроизведения дефекта). Описываются максимально подробно, с указанием конкретных вводимых значений.
5. Фактический результат (Actual result) — указывается, что не так работает, в каком месте продукта и при каких условиях. Описывая фактический результат, необходимо ответить на три вопроса: что? где? когда?
6. Ожидаемый результат (Expected result) — указывается, как именно должна работать система по мнению тестировщика, основанному на требованиях и прочей проектной документации.
7. Вложения (Attachments) — скриншоты, видео или лог-файлы.
8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
9. Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправить дефект.
10. Статус (Status) — определяет текущее состояние дефекта. Отражает жизненный цикл дефекта от начального состояния до завершения. Названия статусов дефектов могут быть разными в разных баг-трекинговых системах.
11. Окружение (environment) – указывается окружение, на котором воспроизвелся баг.

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

Severity vs Priority

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

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

• Блокирующий (S1 – Blocker)
  тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
• Критический (S2 – Critical)
  критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
• Значительный (S3 – Major)
  не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
• Незначительный (S4 – Minor)
  часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
• Тривиальный (S5 – Trivial)
  почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

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

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

• P1 Высокий (High)
  Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критичным для проекта.
• P2 Средний (Medium)
  Ошибка должна быть исправлена, ее наличие не является критичным, но требует обязательного решения.
• P3 Низкий (Low)
  Ошибка должна быть исправлена, но ее наличие не является критичным и не требует срочного решения.

Существует пять базовых типов задач:

• Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
• История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
• Задача (task) — техническая задача, которую делает один из членов команды.
• Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
• Баг (bug) — задача, которая описывает ошибку в системе.

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

• Среда разработки (Development Env) – в ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.
• Среда тестирования (Test Env) – в этой среде работают тестировщики. Тут тестируются новые билды. Здесь тестировщики проверяют функционал, проводят регрессионные проверки, воспроизводят ошибки. Эта среда появляется во время начала динамического тестирования.
• Интеграционная среда (Integration Env) – иногда реализована в рамках среды тестирования, а иногда в рамках превью среды. В этой среде собрана необходимая для end-to-end тестирования схема взаимодействующих друг с другом модулей, систем, продуктов. Собственно, необходима она для интеграционного тестирования. Поддержка среды – также, как и в случае со средой тестирования.
• Превью среда (Preview, Preprod Env) – в идеале, это среда идентичная или максимально приближенная к продакшену: те же данные, то же аппаратно-программное окружение, та же производительность. Она используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к «боевым». Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и/или пользователи проводят приемочное тестирование (User Acceptance Testing (UAT)), а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.
• Продакшн среда (Production Env) – среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3.

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

• Pre-Alpha: ПО является прототипом. Пользовательский интерфейс завершен. Но не все функции завершены. На данном этапе ПО не публикуется.
• Alpha: является ранней версией программного продукта. Цель — вовлечь клиента в процесс разработки. Хороший Альфа-тест должен иметь четко определенный план тестирования с комплексными тестовыми примерами. Это дает лучшее представление о надежности программного обеспечения на ранних стадиях. В некоторых случаях тестирование может быть передано на аутсорс.
• Beta: ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
• Release Candidate (RC): основываясь на отзывах Beta Test, вы вносите изменения в ПО и хотите проверить исправления ошибок. На этом этапе вы не хотите вносить радикальные изменения в функциональность, а просто проверяете наличие ошибок. RC также может быть выпущен для общественности.
• Release: все работает, ПО выпущено для общественности.

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

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

1. Классификация по запуску кода на исполнение:
   • Статическое тестирование — при статическом тестировании код не выполняется. Вы вручную проверяете код, документы требований и проектные документы на наличие ошибок. Отсюда и название «статичный». Основная цель этого тестирования — повысить качество программных продуктов путем выявления ошибок на ранних этапах цикла разработки.
   • Динамическое тестирование — при динамическом тестировании выполняется код. Оно проверяет функциональное поведение ПО, использование памяти / процессора и общую производительность системы. Основная цель этого тестирования — подтвердить, что программный продукт работает в соответствии с требованиями бизнеса. Динамическое тестирование выполняется на всех уровнях тестирования, и это может быть либо тестирование черного, либо белого ящика.
2. Классификация по доступу к коду и архитектуре:
   • Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
   • Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
   • Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения – техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
3. Классификация по уровню детализации приложения:
   • Модульное тестирование — модульные тесты используются для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками.
   • Интеграционное тестирование — предназначено для проверки насколько хорошо два или более модулей ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами).
   • Системное тестирование — процесс тестирования системы в целом, чтобы проверить, соответствует ли она установленным требованиям.
   • Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
4. Классификация по степени автоматизации:
   • Ручное тестирование.
   • Автоматизированное тестирование.
5. Классификация по принципам работы с приложением
   • Позитивное тестирование — тестирование, при котором используются только корректные данные.
   • Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
6. Классификация по уровню функционального тестирования:
   • Дымовое тестирование (smoke test) — короткий цикл тестов, выполняемый для каждой новой сборки для подтверждения того, что ПО стартует и выполняет основные функции без критических и блокирующих дефектов.
   • Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
   • Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
7. Классификация в зависимости от исполнителей:
   • Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
   • Бета-тестирование — ПО стабильно и выпускается для ограниченной пользовательской базы. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в ПО.
8. Классификация в зависимости от целей тестирования:
   • Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения (корректность реализации функциональных требований).
   • Нефункциональное тестирование (non-functional testing) — анализ атрибутов качества компонента или системы, не относящихся к функциональности, то есть проверка, «как работает система».
     1. Тестирование производительности (performance testing) —определение работоспособности, стабильности, потребления ресурсов в условиях различных сценариев использования и нагрузок.
     2. Нагрузочное тестирование (load testing) — оценка поведения системы при возрастающей нагрузке, а также для определения нагрузки, которую способны выдержать компонент или система.
     3. Тестирование масштабируемости (scalability testing) — тестирование программного обеспечения для измерения возможностей масштабирования.
     4. Объёмное тестирование (volume testing) — тестирование, при котором система испытывается на больших объёмах данных.
     5. Стрессовое тестирование (stress testing) — вид тестирования производительности, оценивающий систему на граничных значениях рабочих нагрузок или за их пределами.
     6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
     7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
     8. Тестирование удобства использования (usability testing) — проверка того, насколько легко конечный пользователь системы может понять и освоить интерфейс.
     9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для нового места эксплуатации (например, при смене языка).
     10. Тестирование безопасности (security testing) — тестирование программного продукта, чтобы определить его защищённость.
     11. Тестирование надёжности (reliability testing) — тестирование способности приложения выполнять свои функции в заданных условиях на протяжении заданного времени.
     12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
     13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

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

Техники тест-дизайна:

1. Тестирование на основе классов эквивалентности (equivalence partitioning) — техника тест-дизайна на основе метода чёрного ящика. Помогает разрабатывать и выполнять меньше тест-кейсов, при этом сохраняя достаточное тестовое покрытие.
2. Техника анализа граничных значений (boundary value testing) — проверка поведения продукта на крайних значениях входных данных.
3. Попарное тестирование (pairwise testing) — разработка тестов методом чёрного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
4. Тестирование на основе состояний и переходов (State-Transition Testing) применяется для фиксирования требований и описания дизайна приложения.
5. Таблицы принятия решений (Decision Table Testing) — способ компактного представления модели со сложной логикой. А ещё это техника тестирования чёрного ящика, которая применяется для систем со сложной логикой.
6. Исследовательское тестирование (Exploratory Testing) — это подход, когда тестировщик не использует тест-кейсы, а тестирует приложение по определённому сценарию, который часто составляется прямо во время проверки.
7. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной (или переменных) на поддиапазоны (или домены), с последующим выбором одного или нескольких значений из каждого домена для тестирования.
8. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы). Пользователем может выступать как человек, так и другая система. Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (тест-кейсов), так как они описывают, в каком контексте должно производиться каждое действие пользователя.

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

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

Согласно 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) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

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

• Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
• Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
• Ожидаемый результат (PostConditions) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

1. Понятие «дефект». Работа с дефектами и системами багтрекинга.

Гонсалес Аделя
Тест-менеджер
Центра Тестирования Логики Бизнеса

2.

Дефект
Дефект – невыполнение установленного требования к разрабатываемому или
поддерживаемому программному продукту.
Одна из целей тестирования – находить дефекты.
После обнаружения дефект должен быть:
1. Локализован – определены условия его возникновения, функционал, в котором он
происходит, и, по возможности, причины и связи дефекта и функционала, окружения
или внесенных изменений.
2. Задокументирован – о дефекте должен быть составлен отчет с описанием.
3. Проанализирован и исправлен.
4. Проверен на факт исправления.
2

3.

Разновидности дефекта по критичности.
Уровень
критичности
Блокирующий
Описание
Дефекты, блокирующие дальнейший процесс использования и/или тестирования конечного
продукта. Например:
Система не запускается
Вызов функции не работает
Отсутствует способ выполнить бизнес-операцию.
Важный
Дефекты, приводящие к искажению данных или логики работы системы, или из-за которых
вызов функции приводит к некорректным результатам и при этом отсутствует обходной путь
достижения желаемого (корректного) результата. Например:
В результате обработки системой невалидных данных (данных, которые система не должна
обрабатывать) искажается логика работы системы или в базе данных сохраняются некорректные
данные
Вызов функции был осуществлен, но полученный результат не соответствует ожидаемому
результату
Средний
Дефекты, приводящие к неработоспособности отдельной функции системы или невозможности
ее использования запланированным способом, но при этом существует обходной путь
достижения желаемого результата.
Низкий
Дефекты, приводящие к неудобству использования конечного продукта (ошибки интерфейса и
эргономики), но никак не влияющие на работоспособность системы.
Например, отсутствие ограничения ввода в текстовое поле, при этом в процессе обработки
введенных данных нарушений в системе не возникает.
3

4.

Атрибуты отчета о дефекте.
Тип запроса
Списковое поле
(фиксированные значения)
Тип заявки (Дефект, Задача, Запрос на изменение или
другое). Значение должно быть «Дефект» (Bug).
Проект
Списковое поле
(актуальные проекты для базы)
Название проекта
Тема
Текстовое поле
Название (заголовок) дефекта
Автор
Текстовое поле
(заполняется автоматически)
Имя участника проекта, который регистрирует дефект
Дата регистрации
(создания)
Дата
(заполняется автоматически)
Дата регистрации дефекта
Резолюция
Выпадающий список
Поле содержит решение, принятое по дефекту в момент его
закрытия или перевода в другой статус.
Проявляется в
версиях
Текстовое поле
Версия системы (подсистемы) для которой заведен дефект
Замечание: Если база предназначена для единственного
проекта – предустановленное значение.
4

5.

Атрибуты отчета о дефекте.
Компонент
Описание
Списковое поле
(предустановленный набор для
конкретного проекта)
Название компонента системы (подсистемы, части, модуля и
т.п.).
Текстовое поле
Подробное описание дефекта.
Замечание: Используется для сложных систем с поэтапной
разработкой/поставкой.
Замечание: Если дефект ПП не является следствием выполнения
определенного сценария тестирования, то в данном поле
указывается подробная последовательность шагов для
воспроизведения дефекта.
Критичность
Списковое поле (фиксированные
значения)
Уровень критичности дефекта (Блокирующий, Важный,
Средний, Низкий).
Исполнитель
Списковое поле
(актуальный список участников
проекта)
Участник ролевой группы исполнителей, ответственный за
анализ, исправление или подтверждение исправления дефекта.
Приоритет
Выпадающий список
Приоритет исправления дефекта (Высокий, Средний, Низкий).
Исправить в версиях
Текстовое поле
Версия системы (подсистемы), для которой будут выполнены
работы по исправлению дефекта (или версия документа)
Комментарии
Текстовое поле
Любые значимые комментарии, поясняющие произведенные с
дефектом действия
5

6.

Создание отчета о дефекте.
6

7.

Создание отчета о дефекте.
7

8.

Пример хорошего отчета о дефекте.
8

9.

Пример плохого отчета о дефекте (не надо так).
9

10.

Жизненный цикл дефекта.
Аналитик, Разработчик, Тестировщик
Аналитик
РП,
Аналитик
Opened
РП
Rejected
РП
РП,
Аналитик
РП
РП
Assigned
Postponed
РП
РП
Разработчик, Аналитик,
Аналитик Разработчик
Reopened
Тестировщик
In Progress
Тестировщик
Not confirmed
Разработчик,
Аналитик
Техподдержка
Тестировщик
Тестировщик
Тестировщик
Resolved
Confirmation
Тестировщик
Аналитик,
РП, Техподдержка
Closed
10

11.

Описание статусов (состояний) дефекта.
Статус
Opened
Описание
Дефект зарегистрирован в базе JIRA (или ином багтрекере), но требует анализа и одобрения перед направлением на исправление.
Assigned
Дефект назначен на конкретного разработчика, ответственного за его исправление.
In Progress
Ответственный разработчик начал работу с дефектом.
Resolved
Ответственный разработчик завершил работы по исправлению дефекта.
Confirmation
Тестировщик проверил устранение дефекта, но для его закрытия требуется дополнительное подтверждение Заказчика (только для
дефектов, требующих подтверждения Заказчиком).
Not confirmed
Участник техподдержки опроверг исправление дефекта по требованию Заказчика. Дефект назначается на тестировщика для
контрольного воспроизведения с целью анализа причин опровержения исправления и, при необходимости, внесения изменений в
тестовые сценарии или методику тестирования (только для дефектов, требующих подтверждения Заказчиком).
Reopened
Дефект переоткрыт тестировщиком с указанием причин в результате неподтверждения устранения дефекта или опровержения
устранения Заказчиком.
Closed
Тестировщик проверил устранение дефекта и подтверждает завершение работ по нему.
Rejected
Дефект отклонен РП или Аналитиком с указанием причин.
Postponed
Исправление дефекта отложено.
11

12.

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

13.

Ошибки при заведении дефекта.
1. Требования к продукту интерпретированы неверно или выдуманы.
2. Недостаточный анализ и локализация проблемы.
3. Недостаточное описание.
4. Название дефекта начинается с «ошибка».
5. Ссылка на аналитику, тест-кейс, любую документацию или другой дефект как на
общеизвестный факт.
6. Название дефекта не уникально или не свидетельствует о проблеме.
7. Дубль существующего незакрытого дефекта.
8. Грамматические ошибки.
9. Сложное или непонятное описание дефекта, обилие трудно понимаемых речевых
оборотов.
13

Серьезность ошибки

Серьезность ошибки или серьезность дефекта при тестировании — это степень влияния ошибки или дефекта на тестируемое приложение. Более сильное влияние ошибки / дефекта на функциональность системы приведет к более высокому уровню серьезности. Инженер по обеспечению качества обычно определяет уровень серьезности ошибки / дефекта.

Что такое приоритет?

Приоритет определяется как порядок, в котором дефект должен быть исправлен. Чем выше приоритет, тем быстрее будет устранен дефект.

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

КЛЮЧЕВАЯ РАЗНИЦА

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

Типы серьезности

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

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

Типы приоритета

Типы приоритета ошибки / дефекта можно разделить на три части:

• Низкий: дефект вызывает раздражение, но его можно исправить после устранения более серьезного дефекта.
• Средний: В ходе нормальной работы по разработке дефект должен быть устранен. Может подождать, пока не будет создана новая версия
• Высокий: дефект необходимо устранить как можно скорее, поскольку он серьезно влияет на систему и не может использоваться, пока не будет исправлен.

Советы по определению серьезности дефекта

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

Приоритет против серьезности: ключевое различие

Приоритет	Строгость
Приоритет дефекта определяет порядок, в котором разработчик должен устранять дефект.	Серьезность дефекта определяется как степень влияния дефекта на работу продукта.
Приоритет делится на три типа Низкий Середина Высоко	Степень серьезности делится на пять типов. Критический Основной Умеренный Незначительный Косметический
Приоритет связан с расписанием	Серьезность связана с функциональностью или стандартами
Приоритет указывает, как скоро ошибка должна быть исправлена	Серьезность указывает на серьезность дефекта функциональности продукта.
Приоритетность дефектов решается после консультации с менеджером / клиентом.	QA-инженер определяет уровень серьезности дефекта
Приоритет определяется стоимостью бизнеса	Серьезность определяется функциональностью
Его ценность субъективна и может меняться с течением времени в зависимости от изменения ситуации в проекте.	Его ценность объективна и вряд ли изменится
Статус высокого приоритета и низкого уровня серьезности указывает на необходимость немедленного устранения дефекта, но не влияет на приложение.	Статус высокой серьезности и низкого приоритета указывает на то, что дефект необходимо устранять, но не в срочном порядке.
Статус приоритета зависит от требований заказчика.	Статус серьезности зависит от технического аспекта продукта.
Во время UAT команда разработчиков исправляет дефекты в зависимости от приоритета.	Во время SIT команда разработчиков исправит дефекты в зависимости от серьезности, а затем приоритета.

Пример серьезности и приоритета дефекта

Давайте посмотрим на пример с низкой серьезностью и высоким приоритетом и наоборот

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

Сортировка дефектов

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

Как определить сортировку дефектов:

Большинство систем используют приоритет как главный критерий для оценки дефекта. Однако при правильной сортировке учитывается и серьезность.

Процесс сортировки включает следующие шаги

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

Рекомендации, которые должен учитывать каждый тестировщик, прежде чем выбирать степень серьезности

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

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

Вывод:

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

---