Что такое доменное тестирование?
Новые техники в тестировании появляются достаточно редко, но в 2013 году вышла книга Сэма Канера «The Domain Testing Workbook».
Книга посвящена всего лишь одному виду тестирования — тестированию доменного анализа (также его называют доменный анализ либо доменное тестирование).
Что это за вид тестирования, которому посвятили целых 488 страниц? Давайте разберемся.
Если мы с вами обратимся к глоссарию ISTQB, то определение доменного тестирования звучит следующим образом:
Доменное тестирование (domain analysis) — методика разработки тестов, относящаяся к методу черного ящика, использующаяся для определения действенных и эффективных тестовых сценариев в случаях, когда множественные параметры могут или должны быть протестированы одновременно. Методика базируется и обобщает методы эквивалентного разбиения и анализа граничных значений.
Если переформулировать проще, то определение будет следующим:
Доменное тестирование — это вид тестирования, направленный на анализ различных значений, поиск их взаимосвязи и составление эффективных тестов.
То есть суть доменного тестирования заключается в том, чтобы разделить набор условий тестирования на те значения, которые можно считать одинаковыми, и за счет этого протестировать эффективней.
Для понимания возьмем простой пример. Скажем, что у нас есть поле Логин и Пароль. В идеале, нам необходимо каждое поле протестировать по отдельности. Однако доменное тестирование позволяет сделать так, чтобы в одном тесте мы смогли проверить оба поля одновременно и без потери в качестве тестирования.
Пример из жизни. Возьмем два действия: 1. ехать в автобусе в качестве пассажира и 2. слушать аудиокнигу. Мы можем просто ехать в автобусе без прослушивания книги, как и слушать книгу, не едучи в автобусе. Но мы можем объединить эти два действия и слушать книгу, пока едем в автобусе. При таком объединении мы без потери качества и до нужного места доберемся, и книгу послушаем.
Конечно, тут тоже есть свои ограничения и нюансы. Например, будет так шумно, что мы ничего не услышим. Но и при реальном тестировании они тоже есть. Например, при вводе логина и пароля сайт выводит “общее” предупреждение, которое гласит: “Логин или пароль введены неверно”. То есть в этом случае мы не сможем понять, что именно неверно.
Разновидности доменного тестирования: признаки эквивалентности и анализ граничных значений
В основе использования доменного тестирования лежат различные техники, но наиболее популярные — это определение классов эквивалентности и граничных значений.
Давайте вспомним, что они означают.
Классы эквивалентности — это набор тестов, полное выполнение которого является избыточным и не приводит к обнаружению новых дефектов. Если мы ожидаем одинакового результата от выполнения двух и более тестов, эти тесты эквивалентны.
Граничные значения — это те места, в которых один класс эквивалентности переходит в другой. Эти места очень важны, их обязательно следует проверять в тестах, т.к. именно в этом месте чаще всего и обнаруживаются ошибки.
Цель доменного тестирования
Цель доменного тестирования — предоставить стратегию по выбору минимального набора показательных тестов.
Нет, естественно, не один, но должно остаться минимум тестов, которые будут самые эффективными.
Шаги для достижения цели:
Давайте разберем все на конкретном примере.
К нам на тестирование поступает задача «протестировать форму авторизации». Форма состоит из двух полей: логин и пароль. Длина логина и пароля — от 5 до 10 символов. Логин может принимать различные символы, цифры и буквы на латинице. Пароль тоже может принимать символы, цифры и латиницу.
2. Выявляем наборы значений, представляющие каждую группу:
3. И далее скомбинируем эти значения в виде таблицы.
Таким образом, мы добились наиболее эффективных тестов, которые не только максимально покрывают необходимые проверки, но и экономят наше время.
Плюсы и минусы доменного тестирования
У доменного тестирования есть свои как плюсы, так и свои минусы.
К достоинствам можно отнести:
Полезные хитрости
Также есть и свои полезные трюки, которые вам могут пригодиться.
Если подытожить, то доменное тестирование — это не новый вид тестирования, а рекомбинация и формализация уже существующих техник.
Основное его преимущество — это сокращение количества проверяемых значений без потери эффективности тестирования. То есть правильное применение техники приводит к уменьшению количества тестов без ухудшения качества тестирования.
Тестирование домена
Введение в тестирование домена
Лучшие 4 стратегии доменного тестирования
Теперь давайте обсудим стратегию тестирования домена:
Тестирование домена делится на субдомены. После этого приложение рассматривается для тестирования домена вместе с поддоменом, при этом единичные или комбинации входных данных проверяются через поддомен. Это обеспечивает упрощение сложных сценариев, поскольку домен разделен на поддомен. Тест, проводимый на границах субдомена, называется анализом граничных значений (BVA). Когда условия теста делятся на наборы или группы тестов, тогда это называется классом эквивалентности тестирования. Домен тестер должен разбираться в домене в деталях.
1. Выбор домена
Домен, который имеет менее сложную функциональность, можно считать тестированием домена. В приложении будут входные переменные, которые должны быть назначены, и надлежащий результат должен быть проверен.
2. Сгруппируйте входные данные в классы
Подобный тип входных данных разбивается на подмножества. Существует два типа разделения: разделение по эквивалентным классам и анализ граничных значений (BVA). Разделение по классам эквивалентности разбивает входные данные на эквивалентные разделы данных для определения контрольных примеров. Здесь тестовые случаи разработаны таким образом, что каждый раздел покрывается за один раз. В тестировании анализа граничных значений (BVA) тестовые случаи разрабатываются с учетом недопустимого диапазона граничных значений.
3. Входные данные классов для тестирования
Граничные значения следует рассматривать как данные для тестирования. Границы представляют классы эквивалентности, которые с большей вероятностью обнаружат ошибку, чем другие члены класса. Данные между диапазонами являются лучшим представителем класса эквивалентности.
4. Проверка выходных данных
Когда входные данные присваиваются приложению, эти выходные данные проверяются. Выходные данные должны быть недействительными и указывать диапазон.
Примеры доменного тестирования
Давайте рассмотрим два сценария в качестве примера:
1. Тестовые данные с одним входом
Примеры выражений: (z = x + y) или (z = xy) или (z = x * y) или (z = x / y) и т. Д.
2. Тест с несколькими входными переменными
В этом примере несколько или комбинации входных переменных проверяются на предмет соответствующего вывода. Давайте рассмотрим приложение School Management для системы аттестации детей, в отношении их системы оценок назначены классы.
В соответствии с вышеуказанными условиями испытаний могут быть определены следующие сценарии:
Доменное тестирование (domain testing)
Доменное тестирование (domain testing) – вид тестирования, направленный на анализ показательных значений и взаимосвязи элементов. Доменный анализ в тестировании также известен как:
В доменном тестировании входные данные считаются эквивалентными, если программа проходит один и тот же путь выполнения для их обработки.
Класс эквивалентности (equivalence class) – набор тестов, полное выполнение которого является избыточным и не приводит к обнаружению новых дефектов. Другими словами, если мы ожидаем одинакового результата от выполнения двух и более тестов, эти тесты эквивалентны. Такие множества тестов называются классами эквивалентности.
Доменное тестирование (domain testing, domain analysis) — техника создания эффективных и результативных тест кейсов в случае, когда несколько переменных могут или должны быть протестированы одновременно. – Определение доменного тестирования из «Тестирование программного обеспечения. Базовый курс» / С. С. Куликов. — Минск, 2017.
Доменное тестирование: признаки эквивалентности
Идея этого метода состоит в том, чтобы разделить набор условий тестирования на, которые можно считать одинаковыми (т. е. система должна обрабатывать их одинаково), таким образом, признаками эквивалентности можно считать (несколько тестов эквивалентны, если):
Основная цель доменного тестирования — это предоставить стратегию по выбору минимального набора показательных тестов. Конечно, должен остаться не один тест, но минимум, при чем именно показательные тесты.
Domain testing: подход к достижению цели
Если очертить подход к достижению цели доменного тестирования, то можно выделить следующие шаги:
Сформировать конечный набор «наиболее показательных» значений и провести тесты с их использованием
Плюсы и минусы доменного тестирования
Нужно признать, что Доменное тестирование имеет как достоинства так и недостатки, поэтому давайте их перечислим.
Плюсы:
Минусы:
Доменное тестирование: эквивалентность и анализ граничных значений
Анализ граничных значений одна из наиболее популярных разновидностей domain testing, поэтому приведем пример. Доменный анализ в тестировании основной целью имеет то, чтобы проверить, принимает ли система входные данные в допустимом диапазоне и выдает требуемые выходные данные. Кроме того, он проверяет, что система не должна принимать входные данные, условия и индексы за пределами указанного или действительного диапазона.
Следующее поле пароля может содержать не менее 6 и не более 10 символов. Это означает, что результаты для значений в разделах 0-5, 6-10, 11-14 должны быть эквивалентны.
| Тестовый сценарий № | Описание сценария теста | Ожидаемый результат |
|---|---|---|
| 1 | Введите от 0 до 5 символов в поле пароля | Система не должна принимать |
| 2 | Введите от 6 до 10 символов в поле пароля | Система должна принять |
| 3 | Введите от 11 до 14 символов в поле пароля | Система не должна принимать |
Таким образом, нам нет необходимости проверять все возможные значения, потому что, если это будет сделано, число тестов станет больше. Чтобы решить эту проблему, мы используем гипотезу разделения эквивалентности, где мы тестируем возможные значения из каждой группы, как показано выше, где поведение системы можно считать одинаковым.
Такое разделение и есть классами эквивалентности. Затем мы выбираем только одно значение из каждого раздела для тестирования. Гипотеза, лежащая в основе этого метода, заключается в том, что если одно условие / значение в разделе проходит, все остальные также будут проходить. Аналогичным образом, если одно условие в разделе не выполняется, все остальные условия в этом разделе не будут выполнены.
Анализ граничных значений — вы проверяете границы между разделами эквивалентности. В нашем примере вместо проверки одного значения для каждого раздела вы будете проверять значения в таких разделах, как 0, 5, 6, 10, 11. Как вы можете заметить, вы проверяете значения как на допустимых, так и на недопустимых границах.
Разделение эквивалентности и анализ граничных значений (BVA) тесно связаны между собой и могут использоваться вместе на всех уровнях тестирования.
Доменное тестирование: полезные трюки
И напоследок полезные трюки, которые можно применять при доменном тестировании и не только.
Делим или умножаем на два
Позитивное вместе, негативное отдельно
Используем готовые чек-листы:
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализом результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Пример таблицы принятия решений
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.
