Связанные с изменениями виды тестирования

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

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

Повторное тестирование (re-testing) — повторный запуск тестовых сценариев, которые показали наличие ошибок, для подтверждения успешности исправления этих ошибок.

Вчемразницамежду regression testing и re-testing?

Re-testing — проверяется исправление багов.

Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов.)

 

Тестирование сборки (Build Verification Test)направлено на определение соответствия версии ПО критериям качества. По целям - аналог Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Более глубоко проникает внутрь в зависимости от версии системы.

Санитарное тестирование (Sanity Testing)— это узконаправленное тестирование того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Часто выполняется вручную.

   В отличии от дымового (Smoke testing), санитарное тестированиенаправлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.

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

 

Стратегия быстрого тестирования

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

В том же ключе, быстрое тестирование (rapid testing) означает выполнение тестирования ПО в более быстром темпе, чем это делается в настоящий момент, при условии сохранения или повышения уровня качества. Простых путей достижения этой цели не существует. Упрощенно быстрое тестирование можно представить как структуру, основанную на компонентах:

• персонал,

• процесс комплексных испытаний,

• статическое тестирование,

• динамическое тестирование.

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

Персонал

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

Процесс комплексных испытаний

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

Статическое тестирование проводится с целью

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

• проконтролировать качества проекта.

Динамическое тестирование применяется для выполнения тестов различных типов, таких как

• функциональная проверка,

• испытания для определения рабочих характеристик,

• тестирование в предельных режимах.

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

 

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

• Может ли тестовая группа предпринять на данной стадии какое-либо действие, способное предотвратить утечку (сокрытие) дефектов?

• Может ли тестовая группа предпринять на данной стадии какое-либо действие, позволяющее уменьшить риск нарушения временного графика разработок?

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

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

 

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

• проектирование,

• кодирование,

• тестирование,

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