К основному контенту

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье "С чего начинать изучение тестирования? Конечно же с методов!") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается)
Итак, по степени важности тестируемых функций разделяют следующие виды:
- «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки.
Дымовое тестирование на начальном этапе выявляет основные критические
дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать.
Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования.
- Критического пути (critical path test) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при стандартном их использовании.
Чаще всего на практике на данном уровне тестирования проверяется основная масса требований к продукту. Пример: возможность набора текста, вставки картинок, возможность войти на сайт, создать запись, и т.д.
Для данного вида тестирования пишутся наиболее подробные и глубокие тест-кейсы, чтобы покрыть всю возможную функциональность приложения.
Тест критического пути может быть как позитивным, так и негативным:
·       Позитивный тест критического пути — это проверка работоспособности функций программного продукта, с которыми пользователь сталкивается ежедневно.
·       Негативный тест критического пути — это проверка всевозможных вариантов нестандартного использования функциональности, используемой пользователем каждый день.
Тест критического пути является одним из самых распространенных видов функционального тестирования. Частота проведения данного тестирования обусловлена в первую очередь необходимостью периодической проверки всего приложения в сжатые сроки. А также позволяет выявить самые быстро находимые дефекты и исправить приложение в более сжатые сроки.
- Расширенное  (extended test) - тестирование, при котором проверяется нестандартное использование программного продукта, границы переполнения массивов данных, ввод специальных символов, нелогичное кликанье по кнопкам, открыть одно окно и закрыть предыдущее, и так далее.
Обычно данный вид тестирования проводится при наличии времени и ресурсов. Тест-кейсы для него составляются аналогично тест-кейсам основного функционала, но их обычно меньше всего и они могут всегда дополняться.

На практике чаще проводится «дымовое» тестирование и «критического пути», в отличии от «расширенного».

Комментарии

Популярные сообщения из этого блога

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключе

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные ша