Объекты тестирования.

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

Типичные элементы документации программного обеспечения включают:

Руководство пользователя (User Manual): Документ, предназначенный для пользователей программы, который объясняет, как использовать продукт, как выполнять определенные задачи, а также предоставляет инструкции по установке и настройке.

Руководство администратора (Administrator’s Guide): Этот документ описывает процессы установки, настройки и управления программой. Он предназначен для администраторов системы или технического персонала, который ответственен за обслуживание программы.

Техническая документация (Technical Documentation): Включает в себя детальные технические описания архитектуры, компонентов, API и внутренних механизмов программы. Этот тип документации обычно ориентирован на разработчиков и инженеров.

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

Документация по API (API Documentation): Если программное обеспечение предоставляет API для интеграции с другими системами, этот документ объясняет, как использовать и взаимодействовать с API.

Справочные материалы (Reference Materials): Это справочники, включающие в себя списки команд, функций, параметров и других элементов программы с их описаниями.

Документация по тестированию (Testing Documentation): Описание процедур тестирования, тестовых случаев, сценариев и результатов тестирования.

Релизные заметки (Release Notes): Информация о каждом выпуске программы, включая список изменений, исправления ошибок и новые функции.

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

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

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

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

Программное обеспечение (Software).

Код программы (исходный код) — это набор текстовых инструкций, написанных на определенном языке программирования, которые определяют логику и поведение программного продукта.

Аппаратное обеспечение (Hardware).

Тестовые артефакты.

Это документы, материалы или объекты, созданные в процессе тестирования ПО и служащие важными источниками информации для команды разработчиков и тестировщиков.

Тестирование требований.

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

Спецификация (specification) — документ, описывающий (в идеале — исчерпывающе, однозначно и доступно) требования, дизайн, поведение или иные характеристики компонента или системы. Зачастую в спецификацию включаются процедуры контроля исполнения.

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

Спецификация проектирования теста (test design specification) — документ, описывающий тестовое условие (элементы покрытия) для элемента тестирования, детализированный подход к тестированию, и идентифицирующий соответствующие тестовые сценарии высокого уровня.

Спецификация процедуры тестирования (test procedure specification) — документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования.

Спецификация теста (test specification) — документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и / или спецификации процедуры тестирования.

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

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

Прямые требования.

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

Косвенные требования.

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

Бизнес-требования к программному обеспечению (Business Requirements for Software) — это высокоуровневые описания функциональности, процессов и условий, которые программное обеспечение должно удовлетворить, чтобы соответствовать бизнес-целям и потребностям организации. Они обычно формулируются с учетом потребностей бизнеса и описывают, что система должна делать, чтобы поддерживать операции компании, улучшать процессы и достигать целей.

Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль). Результатом выявления требований на этом уровне является общее видение (vision and scope) — документ, который, как правило, представлен простым текстом и таблицами.

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

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

Пользовательские требования (user requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объема работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вариантов использования (use cases), пользовательских историй (user stories), пользовательских сценариев (user scenarios). Несколько простых, изолированных от контекста и друг от друга примеров пользовательских требований:

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

Бизнес-правила (business rules) описывают особенности принятых в предметной области (и / или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д. Несколько простых, изолированных от контекста и друг от друга примеров
бизнес-правил:

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

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

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

Функциональные требования (functional requirements) описывают поведение системы, т.е. ее действия (вычисления, преобразования, проверки, обработку и т.д.). В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что не должна делать (например: «приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции»).

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

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

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

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

• При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов.
• Ни при каких условиях общий объем используемой приложением памяти не может превышать 2 ГБ.
• Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов.

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

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

• Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана от 800x600 до 1920x1080.
• Не допускается использование Flash при реализации клиентской части приложения.
• Приложение должно сохранять способность реализовывать функции с уровнем важности «критический» при отсутствии у клиента поддержки JavaScript.

Требования к интерфейсам (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой. Несколько простых, изолированных от контекста и друг от друга примеров требований к интерфейсам:

• Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON.
• Протоколирование событий должно вестись в журнале событий операционной системы.
• Соединение с почтовым сервером должно выполняться согласно RFC3207 («SMTP over TLS»).

Требования к данным (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования. Несколько простых, изолированных от контекста и друг от друга примеров требований к данным:

• Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB.
• Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную.
• Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.

Свойства качественных требований (требования к самим требованиям).

Завершенность (completeness). Требование является полным и законченным с точки зрения представления в нем всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно». Типичные проблемы с завершенностью:

• Отсутствуют нефункциональные составляющие требования или ссылки на соответствующие нефункциональные требования (например: «пароли должны храниться в зашифрованном виде» — каков алгоритм шифрования?).
• Указана лишь часть некоторого перечисления (например: «экспорт осуществляется в форматы PDF, PNG и т.д.» — что мы должны понимать под «и т.д.»?).
• Приведённые ссылки неоднозначны (например: «см. выше» вместо «см. раздел 123.45.b»).

Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершенности и оно описывает одну и только одну ситуацию. Типичные проблемы с атомарностью:

• В одном требовании, фактически, содержится несколько независимых (например: кнопка «Restart» не должна отображаться при остановленном сервисе, окно «Log» должно вмещать не менее 20-ти записей о последних действиях пользователя — здесь зачем-то в одном предложении описаны совершенно разные элементы интерфейса в совершенно разных контекстах).

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

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

Непротиворечивость, последовательность (consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. Типичные проблемы с непротиворечивостью:

• Противоречия внутри одного требования (например: «после успешного входа в систему пользователя, не имеющего права входить в систему…» — тогда как он успешно вошёл в систему, если не имел такого права?).

• Противоречия между двумя и более требованиями, между таблицей и текстом, рисунком и текстом, требованием и прототипом и т.д. (например: «712.a Кнопка «Close» всегда должна быть красной» и «36452.x Кнопка «Close» всегда должна быть синей» — так всё же красной или синей?).

• Использование неверной терминологии или использование разных терминов для обозначения одного и того же объекта или явления (например: «в случае, если разрешение окна составляет менее 800x600…» — разрешение есть у экрана, у окна есть размер).

Недвусмысленность (unambiguousness, clearness). Требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз. Типичные проблемы с недвусмысленностью:

• Использование терминов или фраз, допускающих субъективное толкование (например: «приложение должно поддерживать передачу больших объемов данных» — насколько «больших»?) Вот лишь небольшой перечень слов и выражений, которые можно считать верными признаками двусмысленности: адекватно (adequate), быть способным (be able to), легко (easy), обеспечивать (provide for), как минимум (as a minimum), быть способным (be capable of), эффективно (effectively), своевременно (timely), применимо (as applicable), если возможно (if possible), будет определено позже (to be determined, TBD), по мере необходимости (as appropriate), если это целесообразно (if practical), но не ограничиваясь (but not limited to), быть способно (capability of), иметь возможность (capability to), нормально (normal), минимизировать (minimize), максимизировать (maximize), оптимизировать (optimize), быстро (rapid), удобно (user-friendly), просто (simple), часто (often), обычно (usual), большой (large), гибкий (flexible), устойчивый (robust), по последнему слову техники (state-of-the-art), улучшенный (improved), результативно (efficient). Вот утрированный пример требования, звучащего очень красиво, но совершенно нереализуемого и непонятного: «В случае необходимости оптимизации передачи больших файлов система должна эффективно использовать минимум оперативной памяти, если это возможно».

• Использование неочевидных или двусмысленных аббревиатур без расшифровки (например: «доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений» — ФС здесь обозначает файловую систему? Точно? А не какой-нибудь «Фиксатор Сообщений»?).

• Формулировка требований из соображений, что нечто должно быть всем очевидно (например: «Система конвертирует входной файл из формата PDF в выходной файл формата PNG» — и при этом автор считает совершенно очевидным, что имена файлов система получает из командной строки, а многостраничный PDF конвертируется в несколько PNG-файлов, к именам которых добавляется «page-1», «page-2» и т.д.). Эта проблема перекликается с нарушением корректности.

Выполнимость (feasibility). Требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта. Типичные проблемы с выполнимостью:

• Так называемое «озолочение» (gold plating) — требования, которые крайне долго и / или дорого реализуются и при этом практически бесполезны для конечных пользователей (например: «настройка параметров для подключения к базе данных должна поддерживать распознавание символов из жестов, полученных с устройств трёхмерного ввода»).

• Технически нереализуемые на современном уровне развития технологий требования (например: «анализ договоров должен выполняться с применением искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»).

• В принципе нереализуемые требования (например: «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»).

Обязательность, нужность (obligatoriness) и актуальность (up-to-date). Если требование не является обязательным к реализации, оно должно быть просто исключено из набора
требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета (см.
«проранжированность по…»).

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

• Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет.
• Требованию выставлены неверные значения приоритета по критериям важности и / или срочности.
• Требование устарело, но не было переработано или удалено.

Прослеживаемость (traceability). Прослеживаемость бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability). Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirements management tool) и / или матрицы прослеживаемости (traceability matrix). Типичные проблемы с прослеживаемостью:

• Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрестных ссылок.
• При разработке требований не были использованы инструменты и техники управления требованиями.
• Набор требований неполный, носит обрывочный характер с явными «пробелами».

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

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

Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений.
Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования.

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

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

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

К типичным проблемам с корректностью также можно отнести:

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

Бизнес-требования включают в себя:

• Описание бизнес-проблемы.

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

• Описание целей и ожиданий.

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

• Функциональные требования.

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

• Нефункциональные требования.

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

• Требования к интеграции.

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

• Ограничения и ожидания по срокам и бюджету.

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

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

Тест план.

Test Plan — документ, описывающий весь объем работ по тестированию:

• Что необходимо тестировать? — Описание объекта тестирования: системы, приложения.

• Что будем тестировать? — Список функций и описание тестируемой системы или её компонентов в отдельности (форма регистрации, форма авторизации, чат, комментарий, лайк).

• Как будем тестировать? — Указываем те виды тестирования, которые будем использовать при тестировании.

• Когда будем тестировать? — Последовательность проведения работ: чтение технической документации (требований), создание тестовой документации, тестирование, анализ результатов тестирования, заведение баг-репортов.

• Критерии начала тестирования. — Готовность тестового стенда (вид среды разработки, в которой разработчики могут свободно тестировать свои модули без какого-либо вмешательства со стороны команды тестирования), наличие всей необходимой документации, законченность разработки требуемого функционала.

• Критерии окончания тестирования. — Весь функционал работает согласно заявленным требованиям.

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

Пример Тест-плана.

Введение.

Цель тестирования: Обеспечение качества программного обеспечения через выявление ошибок и недочетов перед его выпуском в эксплуатацию.

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

Объекты тестирования.

Модули системы:

• Интерфейс пользователя.
• Серверная часть.
• База данных.
• API.

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

Функциональное тестирование:

• Проверка соответствия функциональности требованиям. Нефункциональное тестирование:
• Производительность.
• Безопасность.
• Удобство использования. Регрессионное тестирование:
• Проверка на наличие новых ошибок после изменения кода.

Интеграционное тестирование:

• Проверка взаимодействия между модулями.

Системное тестирование:

• Полное тестирование всей системы в целом.

Методологии тестирования.

• Ручное тестирование.
• Автоматизированное тестирование (с описанием инструментов, таких как Selenium, JUnit и др.).

Критерии успешности.

• 95% тест-кейсов должны пройти успешно.
• Максимально допустимое количество критических дефектов перед релизом — 0.

QA-ресурсы.

Команда: Определить роли и обязанности участников команды (тестировщики, разработчики, бизнес-аналитики).

Инструменты:

• Системы отслеживания ошибок (например, JIRA).
• Инструменты для автоматизации тестирования.
• Средства для тестирования производительности.

График тестирования.

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

• Подготовка тестовой среды — 1 неделя.
• Написание тест-кейсов — 2 недели.
• Проведение тестирования — 3 недели.
• Анализ результатов и отчетность — 1 неделя.

Отчетность.

Формат отчетности:

• Еженедельные отчеты о статусе тестирования.
• Итоговый отчет с анализом и рекомендациями.

Риски.

Потенциальные проблемы, которые могут повлиять на тестирование (недостаток времени, неопределенность требований, неготовность системы).

Заключение.

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

Чек-лист.

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

Тестовый сценарий.

Test Case — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Виды тестовых сценариев:

Тест-кейсы разделяются по ожидаемому результату на позитивные и негативные:

Позитивный.

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

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

Примеры позитивного тестирования:

Проверка авторизации.

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

Проверка ввода данных.

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

Проверка функций.

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

Негативный.

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

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

Примеры негативного тестирования:

Некорректные данные.

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

Переполнение.

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

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

Тест-сьют.

Набор тест-кейсов по одной теме или области продукта.

Тест-сьюты формируют, если нужно упростить рабочий процесс. Каждый тест-кейс проверяет, как работает элемент системы: например, страница личного кабинета, работа под ролью «Модератор».

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

Например, у интернет-магазина есть авторизация в личном кабинете. Чтобы проверить, как авторизация работает, тестировщик составит набор тест-кейсов:

• Проверить авторизацию под корректным логином и паролем.
• Проверить авторизацию под некорректным логином.
• Проверить авторизацию под некорректным паролем.
• Проверить авторизацию под ролью «Администратор».
• Проверить авторизацию под ролью «Руководитель».
• Проверить недоступность внутренних страниц сайта для неавторизованного пользователя.

Примеры тест-кейсов для чек-листа Тест-кейс № 1. Регистрация пользователя

• Шаг 1. Открыть страницу регистрации
• Шаг 2. Заполнить форму регистрации
• Шаг 3. Нажать кнопку «Зарегистрироваться»
• Шаг 4. Проверить, что появилось сообщение об успешной регистрации
• Шаг 5. Проверить, что пользователь был добавлен в базу данных

Ожидаемый результат:

Тест-кейс № 2. Авторизация пользователя

• Шаг 1. Открыть страницу авторизации
• Шаг 2. Ввести логин и пароль
• Шаг 3. Нажать кнопку «Войти»
• Шаг 4. Проверить, что пользователь был успешно авторизован
• Шаг 5. Проверить, что отображается правильная информация о пользователе (имя, фото профиля и т.д.)

Ожидаемый результат:

Тест-кейс № 3. Работа с профилем пользователя

• Шаг 1. Открыть страницу профиля
• Шаг 2. Изменить информацию о пользователе (например, имя, фото профиля)
• Шаг 3. Нажать кнопку «Сохранить»
• Шаг 4. Проверить, что изменения были сохранены
• Шаг 5. Проверить, что отображается правильная информация о пользователе

Ожидаемый результат:

Тест-кейс № 4. Работа с контентом

• Шаг 1. Открыть страницу с контентом (например, статьи, видео)
• Шаг 2. Проверить, что контент отображается корректно (например, все изображения загружаются, видео проигрывается)
• Шаг 3. Проверить, что пользователь может ть контент в избранное или поделиться им в социальных сетях
• Шаг 4. Проверить, что отображается правильное количество просмотров и лайков
• Шаг 5. Проверить, что комментарии к контенту отображаются корректно

Ожидаемый результат:

Тест-кейс № 5. Работа с функциональностью

• Шаг 1. Проверить работу функциональности продукта (например, поиск, фильтры, пагинация)
• Шаг 2. Проверить, что все кнопки и ссылки работают корректно
• Шаг 3. Проверить, что происходит корректный переход между страницами
• Шаг 4. Проверить, что функциональность продукта соответствует описанию в требованиях

Ожидаемый результат:

Тест-кейс № 5. Работа с различными устройствами и браузерами

• Шаг 1. Проверить, что продукт корректно отображается на разных устройствах (например, на компьютере, планшете и смартфоне).
• Шаг 2. Проверить, что продукт корректно работает в различных браузерах (например, Google Chrome, Mozilla Firefox, Safari).
• Шаг 3. Проверить, что продукт корректно работает в различных операционных системах (например, Windows, MacOS, iOS, Android).

Ожидаемый результат:

Баг-репорт.

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

Локализация дефекта.

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

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

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

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

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

Основные функции баг-трекинговой системы включают:

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

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

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

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

• История изменений: Баг-трекинговая система сохраняет историю изменений, связанных с конкретной ошибкой, включая комментарии, вложения, даты изменений и т.д.

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

Популярные баг-трекинговые системы включают Jira, Bugzilla, Redmine, GitHub Issues и многие другие. Они играют важную роль в обеспечении качества программных продуктов и эффективной командной работы.

Заголовок (Summary)	Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project)	Название тестируемого проекта
Компонент приложения (Component)	Название части или функции тестируемого продукта

Номер версии (Version)	Версия, на которой была найдена ошибка
Критичность (Severity)	Наиболее распространена пятиуровневая система критичности: S1 Блокирующий (Blocker) S2 Критический (Critical) S3 Значительный (Major) S4 Незначительный (Minor) S5 Тривиальный (Trivial)
Приоритет (Priority)	Приоритет дефекта: P1 Высокий (High) P2 Средний (Medium) P3 Низкий (Low)
Статус (Status)	Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например:

Поле	Описание
Автор (Author)	Создатель баг-репорта
Назначен на (Assigned To)	Имя сотрудника, назначенного на решение проблемы
Описание (Description)	Информация об окружении, на котором был найден баг: операционная система, сервис пак, имя и версия браузера, версия ПО чипа, версия библиотеки и т.д. Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Полученный результат. Ожидаемый результат
Прикрепленный файл (Attachment)	Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Атрибуты.

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

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

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

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

• Неправильно работающая ключевая бизнес-логика.
• Дыра в системе безопасности.
• Проблема приводит к временному падению сервера или приводит в нерабочее состояние часть системы.

Значительный (Major) — часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с высоким visibility — обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.

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

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

• Не нарушает бизнес логику.
• Очевидная проблема UI / UX.
• Грамматические ошибки.

Тривиальная (Trivial) — ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие шрифта и оттенка и т.д.

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

Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

Высокий (High).

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

Средний (Medium).

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

Низкий (Low).

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

Как правило, чем выше серьёзность, тем выше приоритет.

Пример дефекта с низкой серьёзностью и высоким приоритетом:

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

Пример дефекта с высокой серьёзностью, но низким приоритетом:

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

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

Определенный набор состояний, через которые проходит баг в течение всей своей жизни.

• Создан (также может быть отклонен или отложен).
• Назначен.
• Приоритезирован.
• Взят в работу.
• Исправлен.
• Тестирование (если баг не исправлен, то возвращается в работу, затем повторное тестирование).
• Закрыт.

Призрачный (плавающий или гейзенбаг) баг.

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

Вернер Гейзенберг говорил, что «чем более пристально глядят на один предмет, тем меньше внимания уделяют чему-то еще».

Отчет по тестированию.

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

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

Пример Отчета по тестированию.

Введение.

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

Область тестирования: Указать, какое ПО или компонент тестировался.

Общее описание.

Версия программного обеспечения: Указать, какая версия ПО тестировалась.

Дата проведения тестирования: Указать период тестирования.

Ответственные лица: Указать участников тестирования, включая тестировщиков и разработчиков.

Методология тестирования.

Типы тестирования: Указать, какие типы тестирования были проведены (функциональное, нагрузочное, регрессионное и т.д.).

Инструменты и среды: Описать, какие инструменты и среды использовались для тестирования.

Тестовые сценарии.

Общее количество тестов: Указать общее количество тестовых случаев.

Краткая информация о тестовых случаях: Перечислить основные тестовые сценарии и их цели. Можно представить в виде таблицы.

Результаты тестирования.

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

Обнаруженные ошибки: Перечислить найденные баги с описанием, их приоритетом и статусом.

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

Анализ результатов.

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

Сравнение с предыдущими версиями (если применимо): Указать, какие изменения произошли по сравнению с прошлым тестированием.

Рекомендации.

Пути улучшения: Указать рекомендации по устранению найденных ошибок.

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

Заключение.

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

Приложения.

Дополнительные материалы: Если необходимо, добавить дополнительные материалы: скриншоты, логи, отчеты об ошибках и т.д.

Советы:

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

Процесс управления тестированием.

Управление тестированием.

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

Управление тестированием — это не один вид деятельности. Оно состоит из целого ряда мероприятий.

Фазы управления тестированием.

В этом разделе кратко описывается процесс управления тестированием и дается обзор этапов управления тестированием.

Процесс управления тестированием.

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

Процесс управления тестированием состоит из двух основных частей:

• Планирование.
• Анализ рисков.
• Оценка тестирования.
• Планирование тестирования.
• Организация тестирования.
• Выполнение.
• Мониторинг и контроль тестирования.
• Решение проблем.
• Отчет о тестировании и оценка.

Планирование.

Анализ рисков и их решение.

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

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

Оценка теста.

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

Преимущества правильной оценки:

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

Планирование тестирования.

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

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

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

• Стратегия тестирования.
• Цель тестирования.
• Критерии выхода / приостановки.
• Планирование ресурсов.
• Результаты тестирования.

Что такое организация тестов при тестировании программного обеспечения?

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

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

Выполнение.

Мониторинг и контроль тестирования.

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

Мониторинг.

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

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

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

Контроллинг.

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

На этом этапе тест-менеджер предпринимает действия для исправления отклонений от плана. В некоторых случаях план должен быть скорректирован в соответствии с ситуацией в проекте.

Решение проблем.

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

В жизненном цикле любого проекта всегда будут появляться неожиданные проблемы и вопросы. Например:

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

Риск, которого следует избегать при тестировании:

• Нарушение дедлайна.
• Превышение бюджета проекта.
• Потеря доверия заказчика.

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

Отчет о тестировании и оценка.

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

Целью отчетов с оценкой результатов тестирования является следующее:

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

Покрытие / Критерии.

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

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