Алекс Смит: Тестирование ПО с Нуля до Специалиста
January 27

3.7 Классификация по цели тестирования

Данная классификация необходима для того, чтоб понять, а когда вообще необходимо производить тестирование.

Классификация по цели тестирования:

1. Тестирование новой функциональности (new feature test)

Тестирование новой функциональности (new feature test) – производится, как только была разработана новая функциональность.

То есть, как только разработчик выполнил свою часть работы, по созданию новой функциональности, он передает ее на тестирование.

Данный функционал проходит все этапы тестирования:

  • Смоук тестирование
  • Тест критического пути
  • Расширенное тестирование

2. Re-test

Re-test – проверка правильности исправления дефекта. Повторное тестирование функционала, в котором был найден дефект, то есть баг.

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

Разработчик разработал новый функционал, тестировщик его проверил, нашел там баг, занес его в бактрекинговую систему, типа Jira, я уже не много рассказывал о ней, в последующих уроках мы чуть больше затронем эту тему. Далее, когда разработчик исправил наш баг, или как говорят в IT «зафиксил», он говорит нашему тестировщику что баг исправлен, так вот повторная проверка нашего функционала, на отсутствие устраненного бага, называется re-test. Если баг не обнаружен, то новый функционал отправляется в релиз, если он повторно обнаружился, то снова возвращается разработчику и т.д.

3. Регрессионное тестирование

Что такое регрессионное тестирование и когда оно проводится - один из самых популярных вопросов на собеседованиях.

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

Регрессионное тестирование проводится:

- после появления нового билда (новой версии нашего продукта)

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

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

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

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

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

Например, у нас есть сценарий, который будет включать в себя авторизацию в интернет-магазине, выбор товара, перенос его в корзину и оплату товара. Используя те технологии что я перечислил, мы имитируем деятельность пользователя, прописываем все шаги нашего теста в коде, и у нас после его запуска открывается браузер, открывается нужная нам ссылка, заполняются все поля, нажимаются кнопки. При этом это все происходит гораздо быстрее, ведь нам не нужно вручную заполнять все поля, система делает это моментально. Тем самым мы экономим время, силы, ресурсы, людей. Так же есть различные средства CI/CD, благодаря которым мы можем запускать наши тесты удаленно, по событию или по расписанию. К примеру, можно настроить что после каждого появления нового билда, то есть, когда разработчик внес изменения в код и выложил это на стенд, будет происходить автоматический запуск наших тестов, для того, чтоб убедиться, что код нашего разработчика не навредил нашему старому функционалу. Так же это можно настроить по расписанию, например каждое утро, в 6 часов будет запускаться набор наших тестов, и придя на работу мы будем видеть результат. Разумеется, запускаются не все тесты, только их часть, основных, потому что прогон всех тестов может занять несколько часов.