Экзамен ISTQB FL: уровни тестирования. Компонентное тестирование

Тема уровней тестирования встречается в заданиях ISTQB FL, поэтому мы подробно рассматриваем ее на курсе по подготовке к экзамену. Сегодня поговорим о компонентном тестировании, способах его проведения и терминах из глоссария ISTQB.

Словарь ISTQB гласит, что уровень тестирования — это конкретная реализация процесса тестирования. На разных уровнях тестирования есть свой определенный набор атрибутов.

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

По этим атрибутам и рассмотрим уровни тестирования. Но прежде познакомимся еще с несколькими терминами: компонент, система и интеграция.

Программный продукт всегда состоит из отдельных частей. Простой пример — фронтэнд (интерфейс) и бэкэнд (серверная часть). 

  1. Компонент, модуль, программа (component, module, program) — наименьший элемент программного обеспечения, который может быть протестирован отдельно. Например, модуль заказа продукта можно протестировать, вызывая конкретные функции этого модуля, не через пользовательский интерфейс.
  1. Система — совокупность связанных компонентов, которые мы тестируем вместе. 
  1. Интеграция — интерфейс взаимодействия между компонентами системы. Например, данные в 1С могут передаваться разными способами — это и будет интеграцией между компонентами системы.

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

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

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

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

TDD — Test Driven Development — Разработка, Управляемая Тестированием. Это прием разработки программного обеспечения, при котором вначале разрабатываются тестовые сценарии, тестирование зачастую автоматизируется, и после этого разрабатывается то ПО, которое будет использовать эти тестовые сценарии.

Простыми словами, это когда сначала написали тесты, а потом под них разработали программный продукт. Чаще всего TDD организуется разработчиками.

На основании чего проводится компонентное тестирование

  • Дизайн;
  • Код;
  • Модель данных
  • Спецификации.

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

Что тестируется при компонентном тестировании

  • Модули, компоненты;
  • Классы;
  • Подпрограммы;
  • Модули БД;
  • Программы конвертации данных, выполнения внутренних функций.

Типичные ошибки на компонентном уровне тестирования

  • Неправильная работа функциональности;
  • Проблемы с потоками данных;
  • Неправильные код и логика.

Зоны ответственности

Почти всегда компонентное тестирование выполняет разработчик — автор кода. Тесты чаще всего пишутся после написания кода, либо до (по TDD), если  используются гибкие методологии и жизненные циклы разработки ПО.


Компонентное тестирование — самый первый из всех уровней. Три остальных мы также рассматриваем в нашем курсе подготовки к экзамену ISTQB FL.

Вам предстоит сдача экзамена? Хотите железно разбираться в теории тестирования? Прокачать знания для себя?

Присоединяйтесь к курсу подготовки к экзамену ISTQB FL!

Старт 20 февраля.

Отзывы выпускников курса

Паве Луцевич, 3.02.2023:

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

Наталья Григорова, 13.10.2022:

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

Ирина Кежеватова, 9.10.2022:

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