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

Уровни Тестирования

1. Компонентное или Модульное тестирование (Component Testing or Unit Testing)
2. Интеграционное тестирование (Integration Testing)
3. Системное тестирование (System Testing)
4. Приемочное тестирование (Acceptance Testing)

Компонентное (модульное) тестирование

Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

Модульное тестирование можно разбить на две глобальные ветки:

• Тестирование верстки (визуальное тестирование)

• Функциональное тестирование

1. Соответствие макетам
2. Графику и оптимизацию

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

Можно проводить тестирование, как следом за написанием кода, так и используя  подготовку автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-driven development) или подход тестирования вначале (test first approach). При этом подходе создаются и интегрируются небольшие куски кода, против которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор, пока все тесты не будут успешно пройдены.

Интеграционное тестирование

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

Выделяют два уровня интеграционного тестирования:

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

Подходы к интеграционному тестированию:

• Снизу вверх (Bottom Up Integration)

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

• Сверху вниз (Top Down Integration)

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

• Большой взрыв ("Big Bang" Integration)

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

Системное тестирование

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

Можно выделить два подхода к системному тестированию:

• на базе требований (requirements based)

Для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.

• на базе случаев использования (use case based)

На основе представления о способах использования продукта создаются случаи использования системы (Use Cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест кейсы (test cases), которые должны быть протестированы.

Приемочное тестирование

Приемочное тестирование - формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

• определения удовлетворяет ли система приемочным критериям;
• вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

• продукт достиг необходимого уровня качества;
• заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

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

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

Типичными формами приемочного тестирования являются:

● Пользовательское приемочное тестирование

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

● Эксплуатационное приемочное тестирование

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

● Контрактное и нормативное приемочное тестирование.

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

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

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

● Альфа-тестирование и бета-тестирование

Цели:

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

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