QA Engineer - Михаил Семынин Страница 5

3.2. Классификация по запуску кода

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

Классификация включает следующие виды:

— Статическое тестирование — это процесс анализа программного обеспечения без выполнения кода. Такое тестирование направлено на ранний поиск ошибок для существенного снижения затрат на разработку. Оно включает в себя проверку кода и документации, анализ требований и дизайна, использование инструментов статического анализа для обнаружения потенциальных проблем. Этим видом тестирования не всегда занимается QA инженер. Проверку кода чаще выполняют разработчики, а инструменты статического анализа нередко внедрены в инструменты разработки приложений и автоматически подсказывают разработчикам слабые или ошибочные места в коде.

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

3.3. Классификация по доступу к коду

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

— Black box (черный ящик) — это выполнение тестирования, когда имеется очень мало или совсем нет информации о внутреннем устройстве проверяемого функционала приложения. При таком тестировании QA инженер выполняет действия так, как если бы он был обычным пользователем, и делает акцент на внешнем поведении приложения. Этот вид тестирования не требует высокой технической квалификации инженера, но требует понимания действий и мышления пользователя.

— White box (белый ящик) — это выполнение тестирования с применением исчерпывающей информации о приложении, то есть, когда имеется полный доступ к исходному коду. Такой вид тестирования предполагает, что QA инженер понимает код и будет учитывать все циклы, условные операторы, применяемые библиотеки, инфраструктурные и прочие особенности работы приложения. Это значит, что для проведения тестирования требуется высокая квалификация инженера.

— Grey box (серый ящик) — это гибрид Black box и White box, когда применяется только частичная информация о внутреннем устройстве функционала приложения. Обычно это означает наличие доступа к документации, описывающей логику поведения приложения и основные особенности его внутреннего устройства, но не вдающейся в техническую реализацию. В этом случае инженер проводит тестирование функционала с учетом только основной логики, чтобы также уделить внимание внешнему поведению системы. Требует средней квалификации QA инженера.

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

3.4. Классификация по способу выполнения тестирования

Эта классификация разделяет тестирование по тому, каким способом выполняют тесты.

— Ручное тестирование — означает, что QA инженер проходит тест вручную, то есть напрямую взаимодействуя с тестируемым приложением. При этом он может использовать незначительную часть автоматизации в процессе, например, генерацию исходных тестовых данных.

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

3.5. Классификация по уровню архитектуры

Тестирование современных приложений можно разделить на уровни, исходя из их архитектуры, то есть внутреннего устройства:

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

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

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

QA инженер обычно участвует в тестировании приложения на системном уровне, однако он может участвовать и в остальных уровнях (реже).

3.6. Классификация по принципу проверок

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

— Позитивное тестирование — направлено на проверку того, что приложение работает как ожидается, когда используются правильные входные данные. Цель этого подхода — подтверждение того, что приложение выполняет свои функции корректно в «идеальных» условиях.

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

Примеры:

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

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

3.7. Классификация тестирования по целям и задачам

Данная классификация разделяет тестирование на основе конкретных главных целей, которые преследуют в процессе проверки программного продукта:

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

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

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