Верификация и валидация (Verification and Validation)

Верификация - это проверки, выполняемые в процессе разработки ПО для ответа на вопрос: “правильно ли мы разрабатываем продукт?”. Это в т.ч. включает проверку документации: requirements specification, design documents, database table design, ER diagrams, test cases, traceability matrix и т.д. Верификация гарантирует, что ПО разрабатывается в соответствии со стандартами и процессами организации, полагаясь на reviews и статические методы тестирования (т.е. без запуска ПО, но, например, с unit/integration tests). Верификация является превентивным подходом (Preventative approach).

 

Этап верификации	Действующие лица	Описание	На выходе
Review бизнес / функциональных требований	Команда разработки / клиент для бизнес-требований	Это необходимый шаг не только для того, чтобы убедиться, что требования собраны и / или корректны, но и для того, чтобы убедиться, выполнимы ли они	Завершенные требования, которые готовы к использованию на следующем этапе - дизайне
Review дизайна	Команда разработки	После создания дизайна команда разработчиков тщательно его просматривает, чтобы убедиться, что функциональные требования могут быть выполнены с помощью предложенного дизайна	Дизайн готов к имплементации
Прохождение кода (Code Walkthrough)	Отдельный разработчик	Написанный код проверяется на наличие синтаксических ошибок. Это более обыденно и выполняется индивидуальным разработчиком на основе кода, разработанного им самим	Код готов к unit testing
Проверка кода (Code Inspection)	Команда разработки	Это уже более формально. Специалисты в данной области и разработчики проверяют код, чтобы убедиться, что он соответствует бизнес-целям и функциональным целям	Код готов к тестированию
Test Plan Review (внутренней командой QA)	QA команда	План тестирования проходит внутреннюю проверку командой QA, чтобы убедиться в его точности и полноте	test plan готов к передаче внешним командам (Project Management, Business Analysis, development, Environment, client, etc.)
Test Plan Review (внешнее)	Project Manager, Business Analyst, and Developer	Формальный анализ test plan, чтобы убедиться, что график и другие соображения команды QA соответствуют другим командам и всему проекту	Подписанный или утвержденный test plan, на котором будет основываться деятельность по тестированию
Test documentation review (Peer review)	Членый команды QA	Экспертная проверка - это когда члены команды проверяют работу друг друга, чтобы убедиться, что в самой документации нет ошибок.	Документация по тестированию готова к передаче внешним командам
Test documentation final review	Business Analyst and development team.	A test documentation review чтобы убедиться, что test cases охватывают все бизнес-условия и функциональные элементы системы	Тестовая документация готова к выполнению

 

Валидация - это процесс оценки конечного продукта, чтобы проверить, соответствует ли он потребностям бизнеса и ожиданиям клиентов, т.е. отвечает на вопрос: “правильный ли мы разработали продукт?”. Валидация является динамическим тестированием, т.е. происходит с помощью выполнения кода и прогона тестов на нём (UAT/CAT, usability, всё что угодно). Валидация является реактивным подходом (Reactive approach).

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

Источник: Exact Difference Between Verification And Validation With Examples

Доп. материал:

● В. В. Кулямин - Работа на тему “Методы верификации программного обеспечения”

● Форум тестировщиков: Verification & Validation - что это такое?

Дефекты и ошибки

Прежде всего, стоит разобраться с терминологией. В определениях Error/Mistake/Defect/Bug/Failure/Fault три из них переводятся на русский язык как ошибка. Определения из ISTQB:

● Просчет (mistake): См. ошибка;

● Помеха (bug): См. дефект;

● Недочет (fault): См. дефект;

● Ошибка (error): Действие человека, которое приводит к неправильному результату;

● Дефект (defect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы;

● Отказ (failure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата.

Неофициальные же источники показывают более широкую картину:

● Ошибка (Error) возникает из-за просчета (Mistake) в написании кода разработчиком;

● Дефект (Defect) это скрытый недостаток в ПО, возникший из-за ошибки в написании кода;

● Когда дефект (Defect) обнаруживается тестировщиком, он называется багом (Bug);

● Если тестировщики упустили дефект и его нашел пользователь, то это сбой (Failure);

● Если программа в итоге не выполняет свою функцию, то это отказ (Fault).

Так что же такое баг на практике? Когда мы имеем ситуацию “1 требование = 1 тест-кейс”, то вопрос отпадает сам собой - тест-кейс не прошёл, значит требование реализовано не правильно, значит баг. Но обычно вариантов куда больше:

● работало, но вдруг перестало;

● работает, но неправильно;

● реализация не соответствует описанию и в задаче в явном виде не зафиксированы корректировки;

● нужно изменить название кнопки/страницы/раздела, потому что в них есть опечатка или “Отменить отмену” (классика!);

● опечатки в принципе (легко может иметь разный приоритет в зависимости от целей и задач проекта);

● после сохранения информация не появляется на странице, даже если в консоли 200 ОК;

● не все указанные при сохранении поля отображаются на странице, но поля неизменно показываются при редактировании;

● при нажатии на кнопку “УДАЛИТЬ ВООБЩЕ ВСЕ ДАННЫЕ КЛИЕНТА” нет модального окна с подтверждением Да/Нет, да и сделать это может любой пользователь без авторизации, который нашел ссылку;

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

● можно cURL’ом заказать услугу другому клиенту или в Elements через DevTools изменить стоимость в корзине (не проворачивайте такие сценарии не на своих рабочих проектах);

● информация торчит за границами своего блока или “наслаивается” на другой (ж-ж-ж-жуть, но на некоторых проектах этим можно легко пренебречь);

● страница очень долго открывается, ну о-о-очень долго — секунд 30 на стабильном интернете (взбешенный клиент гарантирован);

● система делает что-то, что она не должна делать согласно изначальной задумке. Например, закрытие аккаунта не только переводит его в статус “Закрыто”, но и возвращает клиенту все деньги, которые он принес проекту за всё время сотрудничества за уже оказанные услуги (о-о-ой!);

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

При этом часто может возникнуть извечный вопрос “баг или фича?”, когда баг-репорт заводить не нужно. Это фича-реквест, если:

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

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

● знаете как улучшить ту или иную часть системы, чтобы было удобней. Например, меню необоснованно занимает 30% ширины экрана, а полезная информация ютится на оставшихся 70%;

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

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

● на странице не хватает какой-то информации или возможности её добавить;

● на странице не хватает фильтров и пагинации, когда информации много и трудно найти нужное или отображение 1000+ элементов существенно сказывается на скорости загрузки страницы;

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

Хорошо если в команде есть UX/UI дизайнер, а если нет? Тестировщику стоит различать что в дизайне баг, который может привести к печальным последствиям, а что запрос на улучшение, который сделает взаимодействие пользователей с системой более гладким и удобным, но может быть реализован позднее.

Классификация дефектов

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

Классы дефектов:

● Дефекты требований и спецификаций (Requirements and Specifications Defects): Начало жизненного цикла программного обеспечения важно для обеспечения высокого качества разрабатываемого программного обеспечения. Дефекты, введенные на ранних этапах, очень трудно устранить на более поздних этапах. Поскольку многие документы с требованиями написаны с использованием представления на естественном языке, они могут стать

○ Двусмысленными;

○ Противоречивыми;

○ Непонятными;

○ Избыточными;

○ Неточными.

Некоторые специфические дефекты требований / спецификаций:

○ Дефекты функционального описания: Общее описание того, что делает продукт и как он должен себя вести (входы / выходы), неверно, двусмысленно и / или неполно;

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

○ Дефекты взаимодействия функций: это происходит из-за неправильного описания того, как функции должны взаимодействовать друг с другом;

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

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

○ Алгоритмические дефекты и дефекты обработки: это происходит, когда этапы обработки в алгоритме, описанном псевдокодом, неверны;

○ Дефекты управления, логики и последовательности: Дефекты управления возникают, когда логический поток в псевдокоде неверен;

○ Дефекты данных: Они связаны с неправильным дизайном структур данных;

○ Дефекты описания интерфейсов модулей: эти дефекты возникают из-за неправильного или непоследовательного использования типов параметров, неправильного количества параметров или неправильного порядка параметров;

○ Дефекты функционального описания: к дефектам этой категории относятся неправильные, отсутствующие или неясные элементы дизайна;

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

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

○ Алгоритмические дефекты и дефекты обработки:

■ Непроверенные условия overflow and underflow;

■ Сравнение несоответствующих типов данных;

■ Преобразование одного типа данных в другой;

■ Неправильный порядок арифметических операторов;

■ Неправильное использование или пропуск круглых скобок;

■ Потеря точности (Precision loss);

■ Неправильное использование знаков.

○ Дефекты управления, логики и последовательности: этот тип дефектов включает неправильное выражение операторов case, неправильное повторение циклов и пропущенные пути;

○ Типографические дефекты: в основном это синтаксические ошибки, например неправильное написание имени переменной, которые обычно обнаруживаются компилятором, self-reviews, or peer reviews;

○ Дефекты инициализации: этот тип дефектов возникает, когда операторы инициализации пропущены или неверны. Это может произойти из-за недопонимания или отсутствия связи между программистами или программиста и дизайнера, небрежности или непонимания среды программирования;

○ Дефекты потока данных: дефекты потока данных возникают, когда код не следует необходимым условиям потока данных;

○ Дефекты данных: на это указывает неправильная реализация структур данных;

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

○ Дефекты документации кода: когда документация по коду не описывает, что программа на самом деле делает, либо является неполной или двусмысленной;

○ Внешнее оборудование, дефекты программных интерфейсов: эти дефекты возникают из-за проблем, связанных с Системными вызовами, Ссылками на базы данных, Последовательностью ввода / вывода, Использованием памяти, Использованием ресурсов, Обработкой прерываний и исключений, Обменом данными с оборудованием, Протоколами, Форматами, Интерфейсами с файлами сборки, Временными последовательностями.

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

○ Дефекты тестовой обвязки: Для тестирования программного обеспечения на уровне модулей и интеграции необходимо разработать вспомогательный код. Это называется Test Harness или scaffolding code. Test Harness должен быть тщательно спроектирован, реализован и протестирован, поскольку это рабочий продукт, и этот код можно повторно использовать при разработке новых версий программного обеспечения;

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

В англоязычной Wikipedia описано плюс-минус то же самое.

Жизненный цикл дефекта (Defect/Bug Life Cycle)

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

Статусы дефекта:

● Новый (New): когда новый дефект регистрируется и публикуется впервые;

● Назначен (Assigned): после публикации бага тестировщиком руководитель тестировщика утверждает ошибку и передает ее команде разработчиков;

● Открыт (Open): разработчик начинает анализ и работает над исправлением бага;

● Исправлен (Fixed): разработчик внес необходимое изменение в код и проверил его;

● Ожидает повторного тестирования (Pending retest): как только дефект будет исправлен, разработчик предоставляет тестировщику конкретный код для повторного тестирования кода. Поскольку тестирование программного обеспечения остается незавершенным со стороны тестировщиков, ему присваивается статус «ожидает повторного тестирования»;

● Повторное тестирование (Retest): на этом этапе тестировщик выполняет повторное тестирование кода, чтобы проверить, исправлен ли дефект разработчиком;

● Проверен (Verified): тестировщик повторно тестирует баг после его исправления разработчиком. Если баг исправлен, то присваивается статус «проверено»;

● Переоткрыт (Reopen): если баг сохраняется даже после того, как разработчик исправил баг, тестировщик меняет статус на «повторно открыт». И снова баг проходит жизненный цикл.

● Закрыт (Closed): если баг больше не существует, тестировщик присваивает статус «Закрыто».

● Дубль (Duplicate): если дефект повторяется дважды или дефект соответствует той же концепции ошибки, статус изменяется на «дублировать».

● Отклонен (Rejected): если разработчик считает, что дефект не является таковым, он меняет статус на «отклонен»;

● Отложен (Deferred): если текущий баг не является приоритетным и ожидается, что он будет исправлен ​​в следующем выпуске, таким багам присваивается статус «Отложено»;

● Не является багом (Not a bug): если это не влияет на функциональность приложения, то багу присваивается статус «Не является багом».

Утечка дефектов и релиз бага (Bug Leakage & Bug Release)

Утечка бага (Bug Leakage): возникает когда пропускается баг в билде, который вышел в Production. Если баг был обнаружен конечным пользователем или заказчиком, мы называем это утечкой ошибок.

Выпуск бага (Bug release): выпуск программного обеспечения в Production с некоторыми известными багами. Эти известные баги следует включить в примечания к выпуску (release notes). Другой вариант - передача программного обеспечения группе тестирования с некоторыми известными багами, серьезность и приоритет которых невысоки. Эти ошибки можно исправить перед выпуском в Production.