Типы сооружений для обработки осадков: Септиками называются сооружения, в которых одновременно происходят осветление сточной жидкости...
История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...
Топ:
Основы обеспечения единства измерений: Обеспечение единства измерений - деятельность метрологических служб, направленная на достижение...
Особенности труда и отдыха в условиях низких температур: К работам при низких температурах на открытом воздухе и в не отапливаемых помещениях допускаются лица не моложе 18 лет, прошедшие...
Характеристика АТП и сварочно-жестяницкого участка: Транспорт в настоящее время является одной из важнейших отраслей народного хозяйства...
Интересное:
Отражение на счетах бухгалтерского учета процесса приобретения: Процесс заготовления представляет систему экономических событий, включающих приобретение организацией у поставщиков сырья...
Берегоукрепление оползневых склонов: На прибрежных склонах основной причиной развития оползневых процессов является подмыв водами рек естественных склонов...
Уполаживание и террасирование склонов: Если глубина оврага более 5 м необходимо устройство берм. Варианты использования оврагов для градостроительных целей...
Дисциплины:
2022-07-03 | 127 |
5.00
из
|
Заказать работу |
Верификация - это проверки, выполняемые в процессе разработки ПО для ответа на вопрос: “правильно ли мы разрабатываем продукт?”. Это в т.ч. включает проверку документации: 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.
Типы сооружений для обработки осадков: Септиками называются сооружения, в которых одновременно происходят осветление сточной жидкости...
Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...
Адаптации растений и животных к жизни в горах: Большое значение для жизни организмов в горах имеют степень расчленения, крутизна и экспозиционные различия склонов...
Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!