Error guessing что это

Error Guessing (EG)

The first documented approach to experience-based testing was error guessing [Myers 1979]. The people involved seem to have a knack for «smelling out» errors and faults. They practice, more often than not subconsciously, an approach to investigate certain probable types of faults and create test cases to try to expose these faults.

The value of Error Guessing lies in the unexpected: tests made up by guessing would otherwise not be considered. Based on the tester’s experience, he goes in search of fault-sensitive spots in the system and devises suitable test cases for these.

Experience here is a broad concept: it could be the professional tester who ‘smells’ the problems in certain complex screen processes, but it could also be the user or administrator who knows the exceptional situations from practice and wishes to test whether the new or amended system is dealing with them adequately.

The basic way of working is to think of possible faults and error-prone situations (for example by relying on past experiences) and to create and execute tests for that. The tests and results are mostly not documented. Therefore, we do not favor this approach, especially since exploratory testing is a much better alternative.

Together with exploratory testing, error guessing is rather a strange technique among test design techniques. Neither technique is based on any of the described basic techniques and therefore does not provide any specifiable coverage.

This very informal technique leaves the tester free to design the test cases in advance or to create them on the spot during the test execution. Documenting the test cases is optional. A point of focus when they are not documented is the reproducibility of the test. The tester often cannot quite remember under which circumstances a fault occurred. This may result in a developer not being able to investigate an anomaly, the tester not being able to retest a fix, and the test cannot be added to a regression test set. A possible measure for this is the taking of notes (a ‘test log’) during the test. Obviously, faults found with the test are documented. In those cases, great attention should be paid to the circumstances that have led to the fault, so that it will be reproducible.

The main downside of applying error guessing is the lack of documentation (as Myers states in his book “error
guessing is largely an intuitive and ad hoc process”). Therefore, tests are not reproducible. This may result in a developer not being able to investigate an anomaly, the tester not being able to retest a fix, and the test cannot be added to a regression test set.

Read more about the value of unstructured testing, here.

An aid for reproducing a fault is the activation of logging during the test, documenting the actions of the tester. A tool for automated test execution can be used for this.

The considerable freedom of the technique makes the area of application very broad. Error guessing can be applied to the testing of every quality characteristic and to every form of test basis.

Error guessing does not apply a structured approach to testing such as test design techniques, nor does it give any certainty about the coverage of functionality or risk. All known possibilities to solve this quickly result in moving to a checklist-based approach or to exploratory testing.

In more detail

Error guessing is sometimes confused with exploratory testing (see «Exploratory Testing»). The table below sums up the differences:

Error guessing
Exploratory testing
Does not employ the basic techniques Employs the most suitable basic technique, depending on the situation Suitable for testers, users, administrators, etc. Suitable for experienced testers with knowledge of the basic techniques The test cases are designed in the specification phase or during test execution The test cases are designed during test execution Focuses on the exceptions and difficult situations Focuses on the aspect to be tested in total (screen, function) Not systematic, no certainty at all concerning coverage Somewhat systematic

Still, error guessing may be an efficient approach in specific situations, especially in a situation where a system is known to be of very low quality. In that case an experienced tester does not have to prepare any tests to be able to reveal so many anomalies in the IT system that the developers will quickly ask them to stop testing so they can first improve the quality. However, if a system is of good quality, error guessing is a very bad approach. In the case of good quality, the tester will try all sorts of tests but won’t find any anomalies.

The stakeholders will start doubting the quality of the testing, and rightfully so, because besides the fact that there are no anomalies found, the tester (with this unstructured, ad hoc and undocumented approach) will not be able to provide any insight in the quality and risks of the IT system and the stakeholders will not get the information they need to establish their confidence that the pursued business value can be reached with this system.

In more detail

In practice, error guessing is often cited for the applied test technique in the absence of a better name – ‘It’s not a common test design technique, therefore it is error guessing’. In particular, the testing of business processes by users, or the testing of requirements is often referred to as error guessing. However, the basic technique of «checklist» is used here, while with error guessing no specific basic technique is used.

The fact that tests are executed that otherwise would not be considered makes error guessing a valuable addition to the other test design techniques. However, since error guessing guarantees no coverage whatsoever, it is not a replacement.

By preference error guessing takes place later in the total testing process, when most normal and simple faults have already been removed with the regular techniques. Because of this, error guessing can focus on testing the real exceptions and difficult situations. From within the test strategy there should be made availalbe an amount of time (time box) for this activity.

When crowd testing is applied, there is often no control of the approach, techniques and tools the testers use. In practice, we see that these testers often only apply error guessing in trying to find low-hanging-fruit anomalies. To make crowd testing more effective, insight into and advice about the approaches used by the testers is of vital importance.

Points of focus in the steps

The steps can be performed both during the specification phase and during the test execution. The ‘tester’ usually does not document the results of the steps, but if great value is attached to showing evidence or transferability and reusability of the test, then this should be done.

Читайте также:  Python pylint import error

1 — Identifying test situations

Prior to test execution, the ‘tester’ identifies the weak points on which the test should focus. These are often mistakes in the thought processes of others and things that have been forgotten. These aspects form the basis of the test cases to be executed. Examples are:

  • Exceptional situations
    • rare situations in the system operation, screen processing or business and other processes
  • Fault handling
    • forcing a fault situation during the handling of another fault situation, interrupting a process unexpectedly, etc.
  • Non-permitted input
    • negative amounts, zeros, excessive values, too-long names, empty (mandatory) fields, etc. (only useful if there is no syntactic test carried out on this part)
  • Specific combinations, for example in the area of:
    • Data: an as-yet untried combination of input values
    • Sequence of transactions: e.g. «change – cancel change – change again – cancel – etc.» a number of times in succession
  • Claiming too much of the system resources (memory, disk space, network)
  • Complex parts of the system
  • Often-changed parts of the system
  • Parts of the system that often contained faults in the past (processes/functions) .

2 — Creating logical test cases

This step normally takes place only with more complex test cases. The tester may consider creating a logical test case that will cover the situation to be tested.

3 — Creating physical test cases

This step normally only takes place with more complex test cases. The tester may consider creating a physical test case for the logical test case.

4 — Establishing the starting point

During this activity, it may emerge that it is necessary to build a particular starting point for purposes of the test.

An overview of all featured Test Design Techniques can be found here.


Error Guessing

Error guessing in software testing is one of the most common experienced-based techniques used across projects. In this tutorial, we will learn in detail about these topics:

  • What is Error guessing technique?
  • How to apply the Error guessing technique?
  • When to use error guessing?
  • Pitfalls of error guessing technique

What is Error guessing technique?

Error guessing is a technique that makes use of testers’ skills, intuition, and experience to anticipate the occurrence of errors, defects, and failures that may not be easily captured by formal techniques like Boundary Value Analysis and Equivalence partitioning.

This technique is unstructured, which means there is no math behind it. If multiple testers apply this technique to the same application, they might end up with different test cases. The test cases might reflect the experience of the tester with similar applications and his domain expertise.

A methodical approach to the error guessing technique is to create a list of possible errors, defects, and failures, and then design tests that will cover this list.

How to apply the Error guessing technique?

Error guessing depends on testers’ experience with the below considerations:

How the application has worked in the past?

A tester who has worked on the same application is best for the error guessing technique. He would have a good understanding of how the application has worked in previous releases. For e.g. it’s likely that a particular area of application has always been buggy, and hence additional testing is required. The tester can apply error guessing here, while stable areas call for only formal techniques.

What kind of errors tend to be made?

Every application has a history, which is based on the people that are working on it, and also the functionality or integration points that the application has. An experienced tester would know the type of errors that have occurred in the past. E.g. there is an e-commerce application where the discount logic has often failed with the application of a random discount code. In such cases, the tester will try different combinations of valid and invalid discounts and see that the logic is working fine. This insight comes only when the tester has enough experience in the application to know the historical issues.

What are the Failures that have occurred in other applications?

An experienced tester would not only rely on the current application but also make use of his experience in testing similar applications. In some cases, the requirements themselves may not be enough, or the application is new so there is no historical data available. In such cases, the tester will have to rely on the domain experience.

Let’s understand this with the help of a simple example:

Consider a scenario where you are testing the functionality of funds transfer in a banking application. There is a field where you need to enter the amount. The requirements say that you can transfer any amount between 100 and 100000

If you apply standard techniques of Boundary value analysis and Equivalence Partitioning, you may come up with the below validations:

99, 100, 101, 500000, 99999, 100000, 100001.

However, an experienced tester has seen that a few of the similar applications have not handled the cases with a negative value. He would use this experience to create error-guessing scenarios for the current application

When to use the Error guessing technique in software testing?

We should always remember that error guessing is not a substitute for formal techniques. Wherever possible, we should use it in addition to formal techniques and only when the tester has past experience on similar applications.

Error guessing will be effective when-

  • Tester has got good experience with the same/similar applications.
  • There is enough data on historical behavior and failure of the application in past
  • The requirements are inappropriate and formal techniques are difficult to apply.
  • The application or functionality is business-critical, and there is a case to put more testing efforts by applying error guessing in addition to formal techniques.

Some of the defects found in error guessing are usually a result of exhaustive testing on the application. However, the tester has seen such issues in past and he can use his experience to come up with such scenarios without running the exhaustive tests again. This would save a lot of time and still find some quality edge case defects.

Pitfalls of Error Guessing technique

Similar to any unstructured approach, the error guessing technique is dependent on the testers’ intuition and experience. Lack of experience can enforce the failure of this technique. This is especially riskier in cases where requirements are not very clear, or product knowledge is not enough. Then it’s important to make sure that the testers on the project have got enough domain knowledge and experience on similar applications. If the testers are not experienced, they would create error scenarios that may not be relevant, and this would result in poor quality of testing.

Читайте также:  500 internal server error servlet error an exception occurred


Теория тестирования ПО просто и понятно

Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).


Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

планированием работ (Test Management)

проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

анализом результатов (Test Analysis)

Основные цели тестирования

техническая: предоставление актуальной информации о состоянии продукта на данный момент.

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

Верификация (verification)

Валидация (validation)

Соответствие продукта требованиям (спецификации)

Соответствие продукта потребностям пользователей

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

Следует уметь различать, что:

Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

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

Крит (Critical) — неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие непрямые пути (workaround).

Значительный (Major) — часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с высоким visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.

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

Приоритет (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) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.

Читайте также:  Process event stack error

Тестирование производительности (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). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.


Оцените статью