Что такое дефект тестирование
Разница между дефектом и ошибкой в тестировании?
В чем разница между дефектом и ошибкой?
Ошибка является результатом ошибки кодирования
Не все программные дефекты вызваны ошибками кодирования. Один из распространенных источников дорогостоящих дефектов вызван пробелами в требованиях, например непризнанными требованиями, которые приводят к ошибкам упущения разработчиком программы. [14] Распространенным источником пробелов в требованиях являются нефункциональные требования, такие как тестируемость, масштабируемость, ремонтопригодность, удобство использования, производительность и безопасность.
Цитирую Илин Бернштейн из книги « Практическое тестирование программного обеспечения» (рекомендуется), которая разделяет определение из «Коллекции стандартов IEEE для разработки программного обеспечения» (1994) и «Стандартного глоссария IEEE по терминологии разработки программного обеспечения» (стандарт 610.12, 1990):
ошибка
В категорию разработчиков входят разработчики программного обеспечения, программисты, аналитики и тестировщики. Например, разработчик может неправильно понять нотацию проекта или программист может неправильно ввести имя переменной.
Неисправности (Дефекты)
Ошибка (дефект) вводится в программное обеспечение в результате ошибки. Это аномалия в программном обеспечении, которая может привести к его неправильному поведению, а не в соответствии с его спецификацией.
Ошибки или дефекты иногда называют «ошибками». Использование последнего термина упрощает влияние ошибок на качество программного обеспечения. Использование термина «дефект» также связано с программными артефактами, такими как требования и проектная документация. Дефекты, возникающие в этих артефактах, также вызваны ошибками и обычно обнаруживаются в процессе проверки.
Отказы
Во время выполнения программного компонента или системы тестировщик, разработчик или пользователь замечает, что они не дают ожидаемых результатов. В некоторых случаях определенный тип неправильного поведения указывает на наличие определенного типа неисправности. Мы можем сказать, что тип неправильного поведения является признаком ошибки. Опытный разработчик / тестировщик будет хранить в памяти базу знаний о неисправностях / симптомах / случаях неисправности (модели неисправностей, как описано в Главе 3). Неправильное поведение может включать в себя создание неправильных значений для выходных переменных, неправильный ответ со стороны устройства или неправильное изображение на экране. Во время разработки сбои обычно наблюдаются тестерами, а сбои обнаруживаются и устраняются разработчиками.
Там несколько разные термины, связанные с ошибками программного обеспечения. Выдержка из курса я взял:
Ошибка : человеческое действие или упущение, которое приводит к ошибке.
Ошибка : так же, как ошибка.
Отказ : неспособность программного обеспечения выполнять необходимые функции в соответствии с заданными требованиями к производительности.
Согласно этому, нет никакой разницы между дефектом и ошибкой. Тем не менее, некоторые люди утверждают, что ошибка является ошибкой, которая обнаруживается до выпуска программного обеспечения, в то время как дефект обнаруживается клиентом.
Я не мог удержаться от публикации знаменитого «первого фактического случая обнаружения ошибки».
Термин «ошибка» застрял как термин, который означает, что что-то работает не так, как ожидалось.
БАГ должен рассматриваться как жаргонный термин, означающий дефект.
Везде, где это возможно, использование DEFECT вместо BUG фактически означает, что мы признаем наши неудачи (наши дефекты, наше непонимание требований пользователей или вещи, которые мы упустили из виду при реализации) вместо того, чтобы называть это «более тривиально звучащей» ошибкой ».
Старайтесь не использовать термин «ошибка». Это глупо, неактуально, исторически и банально.
Из стандартного глоссария IEEE терминологии разработки программного обеспечения, который цитируется в Своде знаний по разработке программного обеспечения KA для тестирования программного обеспечения и качества программного обеспечения:
ошибка. Смотрите: ошибка; неисправность.
отказ. Неспособность системы или компонента выполнять свои требуемые функции в рамках указанных требований к производительности. Примечание. Дисциплина отказоустойчивости различает действия человека (ошибка), их проявление (аппаратная или программная ошибка), результат ошибки (сбой) и величину, на которую результат является неправильным (ошибка). Смотрите также: сбой; зависимый сбой; исключение; режим отказа; интенсивность отказов; тяжелый сбой; начинающийся отказ; независимый отказ; случайный сбой; мягкий сбой; застрял сбой.
неисправность. (1) дефект в аппаратном устройстве или компоненте; например, короткое замыкание или обрыв провода. (2) Неправильный шаг, процесс или определение данных в компьютерной программе. Примечание: это определение используется в основном дисциплиной отказоустойчивости. В общепринятых терминах термины «ошибка» и «ошибка» используются для выражения этого значения. Смотрите также: ошибка, чувствительная к данным; программно-чувствительный сбой; эквивалентные неисправности; маскировка неисправностей; прерывистая ошибка
Я думаю, что определение отказа является наиболее актуальным. Все начинается с ошибки, будь то требования, дизайн, реализация или контрольный пример / процедура. Если эта ошибка проявляется в программном обеспечении, она становится ошибкой. Сбой вызван наличием одного или нескольких сбоев в программном обеспечении.
Словарь тестировщика
Баг (bug, дефект) — отклонение фактического результата (actual result) от ожидаемого результата (expected result).
Если проще, то это ошибка.
◓ Пример из жизни.
Смотрим мы прогноз погоды и слышим, что сейчас на улице тепло и солнечно. Мы ожидаем, что при выходе на улицу будет тепло и солнечно (ожидаемый результат). Выходим на улицу, а там холодно и все небо затянуто тучами (фактический результат). То есть мы ждали одного (ожидаемый результат), а получили совсем другое (фактический результат).
Если бы мы вышли на улицу и там было тепло и солнечно, то фактический результат совпал бы с ожидаем и, значит, багов нет и все работает как надо.
◆ Пример из работы.
Возьмем форму авторизации на сайте. Мы ожидаем, что введя в поле “Имя” и в поле “Пароль” те данные, под которыми мы регистрировались, произойдет вход в систему. Если этого не случается, то мы имеем дело с багом.
Тестирование — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов.
Если проще, то это процесс проверки работоспособности продукта и его пригодности к использованию. То есть это не просто поиск багов.
◓ Пример из жизни.
Нам дали на проверку кружку. Что мы будем делать? Сначала продумаем, как именно ее можно проверить и набросаем себе план. И только затем присудим к делу. Осмотрим ее снаружи, проверим на трещины, оценим качество рисунка. Уроним ее на пол, чтобы проверить на прочность. Нальем в нее холодную воду, теплую, кипяток, чтобы посмотреть не лопнет ли она. Возьмем ее в руки, оценим, удобно ли держать. После расскажем о результатах нашей работы создателю кружки.
То есть мы не просто ищем дефекты, а проверяем ее со всех сторон и оцениваем, точно ли ей будем удобно пользоваться и выполняет ли она все заявленные функции.
◆ Пример из работы.
Есть задача проверить корзину покупок. Опять же начинаем с планирования. Мы пробуем положить в нее товар, удалить, изменить количество, оцениваем удобство и так далее. После заносим все найденные баги в специальные документы (баг-репорты) и отправляем разработчику (программисту).
Обычно тестирование осуществляется на основании документации, но не всегда.
Техническое задание (ТЗ) – документ, в котором зафиксированы требования к решениям, которые должны быть реализованы в ходе создания сайта или программного обеспечения.
Если проще, то это то, что пишет заказчик, когда хочет получить продукт.
◓ Пример из жизни.
Тесть решил построить дом для тещи и нанял для этого зятя (мужа дочери), который как раз работает инженером. У тестя есть свое видение этого дома. Он рисует и описывает его своими словами и передает мужу.
◆ Пример из работы.
Данный документ описывает, каким именно должен получиться продукт. Исходя из него мы понимаем, что это будет игра в виде фермы, тематика космос и т.д.
Спецификация (specialization, спек) — детальное описание того, как должно работать ПО.
Если проще, то это описание технических свойств своего продукта (размеры, различные параметры, материалы, функции, etc).
◓ Пример из жизни.
Зять читает желания тестя и на их основании уже рисует чертежи, выбирает материал, просчитывает его количество, продумывает как именно технически будет проведены коммуникации (вода, электричество, канализация) и так далее. И уже по этим готовым схемам строители начинают строить дом.
◆ Пример из работы.
На основании ТЗ прописывается, как это все реализовать с технической точки зрения. То есть по спецификации мы будем видеть, как именно должен работать наш продукт. В ней мы пропишем какие семена у нас будут, что из них вырастет, сколько времени займет рост, с помощью чего уже можно ускорить, сколько будут стоить сами семена и т.д.
(!) Все что не соответствует ТЗ и спецификации как раз и будет багом.
Отчет о дефекте (bug report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Его еще называют отчет об ошибке, баг-репорт.
Если проще, то это документ, в котором мы фиксируем найденный баг.
◓ Пример из жизни.
Вернемся к нашему забагованному прогнозу погоды. Что делать? Кому и как сообщить, что погода-то совсем не такая, как говорят? Надо просто написать отчет. Причем написать так, чтобы они поняли про какой именно район речь и что именно с этой погодой не так.
◆ Пример из работы.
На каждую найденную ошибку (баг) составляется отчет об ошибке. Данный отчет имеет определенный шаблон. У каждой компании может быть свой шаблон, но основные поля остаются неизменными. Именно этот шаблон позволяет разработчикам быстро ориентироваться и находить ошибку в коде.
Система отслеживания ошибок (bug tracking system) — программа учета и/или контроля багов.
Ее обычно называют баг-трекер или баг-трекинг.
◓Пример из жизни.
Где вы храните информацию о всех ошибках, которые допустила ваша вторая половинка, чтобы при удобной возможности ей это припомнить? Если вы ее где-то записываете и храните в определенном месте, то считайте, что у вас есть система отслеживания ошибок.
◆ Пример из работы.
Каждая фирма использует свою систему учета. Это могут быть как специально разработанные программы, так и обычные гугл-таблицы. Суть в том, что в одном месте собраны все наши отчеты об ошибках и в любое время можно получить доступ к любому отчету и посмотреть пофикшен он или нет.
Пофиксить — внести изменения, а именно исправления, в код программы.
Если проще, то это правка.
◓ Пример из жизни.
Жена сломала дверцу шкафа. Пошла к мужу, привела к дверце за руку, все показала (считайте, что предоставила баг-репорт с прикрепленным видео). Муж сел, там покрутил, тут постучал и дверца опять начала работать как положено. То есть муж исправил (пофиксил) шкаф.
◆ Пример из работы.
Мы создали баг-репорт и отправили в наш баг-трекер. Разработчик взял баг-репорт в работу, изучил его и внес изменения в код. То есть он исправил (пофиксил) код так, чтобы в продукте больше не было бага.
Билд — версионированная сборка программного обеспечения.
Если проще, то это продукт или кусок продукта, который можно тестировать.
◓ Пример из жизни.
Зять строит дом для тещи. Уже готов каркас и пару комнат. Эти комнаты уже можно показать жене на проверку. Именно эти пару комнат, которые ей уже можно смотреть и оценивать — это и есть билд, который будет тестировать жена.
◆ Пример из работы.
Разработчик создает продукт. Часть кода уже написана и готова к проверки. Именно эту часть он и отдает тестировщикам на проверку.
Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.
Если проще, то это продукт, который видит конечный пользователь.
Можно сказать, что релиз — это билд, который команда разработчиков предоставляет наружу.
◓ Пример из жизни.
Зять закончил строить дом для тещи. Жена все протестировала. Теперь можно привозить тещу и поздравлять ее с новосельем. То есть готовый дом — это и есть релиз.
Также этот пример наглядно показывает насколько вообще важно тестирование и чем может закончиться ситуация, когда продукт вышел в релиз без этапа тестирования)
◆ Пример из работы.
Разработчик создал продукт. Тестировщик его проверил. Если все хорошо, то принимается решение отдать продукт конечному потребителю.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Что такое дефект тестирование
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Software Testing
Разделы портала
Про инструменты
Автор:
Андрей Петров
У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.
На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:
Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.
Серьезность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется тестировщиком или техническим специалистом, который может оценить степень влияния дефекта на работу системы.
Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.
Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.
Подводя итог, нужно помнить, что проставление описанных выше атрибутов является важной частью процесса разработки и тестирования программных продуктов, поскольку атрибуты однозначно классифицируют все дефекты по типу: степень влияния на систему и последовательность их исправления. Как следствие, это позволяет проводить быстрый поиск или делать сортировку, формировать наглядные отчеты и не тратить время на излишние коммуникации. Проставляйте атрибуты правильно и да пребудут ваши системы в добром здравии!
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализом результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Пример таблицы принятия решений
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.