1.7 Тестирование, связанное с изменениями

Типы тестов по степени важности тестируемых функций

1. Smoke testing - проводиться на начальном этапе, например, посте нового билда ((англ. “build”) — это сборка проекта из исходного кода, которая создаёт исполняемый файл или библиотеку.). Направлено на проверку готовности разработанного продукта к проведению расширенного тестирования и определения общего качества состояния продукта.

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

Обычно это один тест или короткий цикл тестов, который подтверждает либо отрицает факт того, что приложение стартует или выполняет основные функции.

На примере интернет магазина smoke-test представляет собой тест, в котором мы логинимся, ищем товар, добавляем его в корзину, производим оплату, подтверждаем ее и получаем наш заказ. То есть все эти шаги можно смело вносить в тестовый случай и, если он будет проходить, ожидаемый и фактический результат будет одинаковым, то smoke testing считается успешным.

Для smoke-test есть только 2 варианта развития событий: либо да, либо нет. В случае, если тест фейлится - дальнейшее тестирование не проводится. Направляется баг на разраба и останавливаем процесс тестирования полностью.

Smoke тесты должны быть быстрыми и легковесными чтобы их можно было прогонять быстро и часто.

2. Тест критического пути (Critical Path Testing, CPT) - основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются на предмет правильности работы при стандартном использовании. Т.е. типичный пользователь в типичной повседневной жизни выполняет типичные задачи.

Чаще всего на данном уровне тестирования проверяется основная масса требований к продукту. Например, выбор шрифта, возможность набора текста, вставка картинок и тд. Может быть как позитивным, так и негативным.

3. Расширенный тест (Extended Testing) - проверка нестандартного использования программного продукта. Например, ввод спецсимволов в поле логина либо нелогично кликать по кнопкам, работать на многих вкладках одновременно, максимально загружать систему и тд.

Расширенное тестирование (extended test) направлено на исследование всей заявленной в требованиях функциональности — даже той, которая низко проранжирована по степени важности. Ещё одним направлением исследования в рамках данного тестирования являются нетипичные, маловероятные, экзотические случаи и сценарии использования функций и свойств приложения, затронутых на предыдущих уровнях.

Типы тестов по цели тестирования

1. Тестирование новой функциональности (New Feature Test) - проверка качества новой функциональности, поставленной на тестирование. Обычно проводится весь цикл тестов по степени важности(Smoke testing --> Critical Path Testing --> Extended Testing).

Тестировщики каждый день сталкиваются с New feature test так как новая функциональность приходит во время какого либо спринта (Спринты — это регулярные ограниченные промежутки времени, в течении которых команда выполняет заданный объем работы в рамках большого проекта.).

2. Регрессионное тестирование (Regression test) - самый важный тест, который занимает у тестеровщиков большую часть времени. Это тестирование ранее проверенной функциональности с целью удостовериться, что изменения в коде (например, добавление новой функциональности) не повлияло на работу старой функциональности.

Регрессионное тестирование может проходить на любом уровне тестирования по степени важности: Smoke testing, Critical Path Testing или Extended Testing.

1. Регрессивное тестирование проводится в каждом новом билде.
2. Регрессивное тестирование осуществляет проверку исправленных багов.
3. Регрессивное тестирование не покрывает все приложение, а только те участки, которые соприкасаются с изменениями в билде.
4. Регрессивное тестирование рекомендуется поводить в системе несколько раз.
5. Регрессивное тестирование любят очень часто автоматизировать для того, чтобы экономить время тестеровщика.
6. Выбор тестов для регрессии:
1. Всегда нужно включать тесты, которые покрывают требования безопасности либо требования критичных, важных функций для бизнеса.
2. Необходимо включать области, которые часто меняются в процессе разработки.
3. Нужно включать тесты функций с высокой вероятностью ошибки.

Особенности регрессионного тестирования из практики

Регрессионное тестирование является одной из самых главных активностей тестировщика и проводится перед каждым релизом (выпуском продукта для конечного пользователя).

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

Обычно для проведения регрессии выделяют несколько дней, код проекта "замораживают"(code freeze) и в него нельзя вносить изменения, кроме исправлений критичных дефектов.

Важно понимать: какие тесты в конечном итоге попадут в регрессионный набор?

Регрессионные тесты выбираются из уже существующих тестовых наборов на основании следующих принципов:

• Тесты, проверяющие часть приложения, в которые вносились изменения

Например, если дефект или новая функция локализованы в модули регистрации, необходимо убедиться, что остальные компоненты этого модуля работоспособны

• Тесты с высоким приоритетом

Мы не можем рисковать работоспособностью самых важных функций приложения, поэтому необходимо дополнительно проверять и их

• Тесты, которые проверяют модули с наибольшей концентрацией дефектов

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

3. Ретест (Re-test) - проверка результата работы над дефектом, проверка правильности исправления дефекта.

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

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

Smoke: пользователь авторизовался, смог найти и добавить товар в корзину, совершил оплату и оформил доставку - в качестве примера для онлайн-магазина.

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

Если Smoke не проходит, то остальное тестирование останавливается и ждет доработки кода.

Critical path: тестируются новые или измененные функции, которые попали в промежуточную версию продукта с точки зрения использования конечного пользователя.

Extended: все остальное.

Что касается Sanity тестирования, то с одной точки зрения это синоним Smoke.

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