#1
urururka
-
- Members
-
- 20 сообщений
Новый участник
Отправлено 17 ноября 2015 — 09:40
Народ, я сейчас хожу на собеседования и понял что валюсь на вопросах терминалогии, помогите разобраться, пожалуйста:
1. Что такое тест кейс, тест степ, тестовый сценарий, тест сьют, чек лист и т.д.?
2. Для чего нужен документ Стратегия тестирования? Что это такое вообще?
3. Что такое тест-план?
4. Какая еще бывает документация?
Пробовал капать интернет, но как-то все по разному всё пишут, но общее представления ответов на эти вопросы получил, но и из-за него полностью запутался 
Извините, если это уже здесь обсуждалось, не нашел поисковиком… Киньте ссылку тогда, пожалуйста.
-
0
- Наверх
#2
Molechka
Отправлено 17 ноября 2015 — 10:49
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования 
4. Собственно, техническое задание Которое, правда, очень редко бывает.
Или имеется в виду документация, которая поступает от тестировщика?
-
0
- Наверх
#3
urururka
urururka
-
- Members
-
- 20 сообщений
Новый участник
Отправлено 17 ноября 2015 — 12:47
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования
4. Собственно, техническое задание
Или имеется в виду документация, которая поступает от тестировщика?
Ух ты! Ольга, спасибо!
1. То есть стратегия тестирования и часть плана? Я как думал, что тест-план — это набор тест-сценариев с описанием параметров проверки (браузер, разрешения экрана, прочая такая штука), и тест-план является частью стратегии. А стратегия — это, где-то прочитал, описание првоерки функционала. Как-то так.
2. А вот фиг его знает что имеют в виду собеседующие… Я как бы тоже отвечал: документация бывает поступающая от аналитиков — ТЗ и прочее. Но видно что-то как-то не так ответил… А какая документация поступает от тестировщика?
-
0
- Наверх
#4
SALar
Отправлено 17 ноября 2015 — 13:23
2. Для чего нужен документ Стратегия тестирования? Что это такое вообще?
http://sqadays.com/ru/talk/38135
Как вариант запишитесь на тестовый прогон этого доклада. Дней через пять делать буду.
PS. http://software-test…-testirovaniia/
Найдите RUP-ский шаблон. Он мне не нравится, авторы сделали стандартную ошибку смешав plan и shedule. Но все равно это лучшее что есть, несмотря на то, что этому шаблону лет 20. Я начинал с него. В 2001.
PS. В моем блоге есть пример плана по RUP-скому шаблону.
-
0
- Наверх
#5
Molechka
Отправлено 17 ноября 2015 — 17:53
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования
4. Собственно, техническое задание
Или имеется в виду документация, которая поступает от тестировщика?
Ух ты! Ольга, спасибо!
1. То есть стратегия тестирования и часть плана? Я как думал, что тест-план — это набор тест-сценариев с описанием параметров проверки (браузер, разрешения экрана, прочая такая штука), и тест-план является частью стратегии. А стратегия — это, где-то прочитал, описание првоерки функционала. Как-то так.
2. А вот фиг его знает что имеют в виду собеседующие… Я как бы тоже отвечал: документация бывает поступающая от аналитиков — ТЗ и прочее. Но видно что-то как-то не так ответил… А какая документация поступает от тестировщика?
Не за что
По поводу стратегии Salar уже ответил, почитайте у него
Документацию можно писать в виде вариантов использования, как вариант. Диаграммы переходов рисовать.
От тестировщика поступает как раз тест-план, тест-кейсы, чек-листы и прочая.
Уточняйте у работодателей, что они имеют в виду Ну и перечитывайте Савина, Coopeland и другие книжки, каждый раз что-то новое находя)
-
0
- Наверх
#6
Solovey_PO
Solovey_PO
-
- Members
-
- 4 сообщений
Новый участник
Отправлено 21 июня 2019 — 06:00
1. Тестовый сценарий = тест-кейс — это проверка данных. Ваш сценарий проверки.
Тест степ — один шаг сценария, step = шаг.
Тест сьюит — набор тест-кейсов, объединенных вместе.
Подробнее про тест-кейс см в этой статье
Например, чтобы протестировать регистрацию, вам понадобятся разные тестовые сценарии — корректное имя, что-то запрещенное, проверки по другим полям итд.
Чем чек-листы отличаются от тест-кейсов
3. Тест-план — это именно план. Когда, что, зачем, какими ресурсами? В нем вы описываете стратегию своего тестирования
4. Собственно, техническое задание
Или имеется в виду документация, которая поступает от тестировщика?
А чем тест-сьют отличается от чек листа?
-
0
- Наверх
#7
Vasiliy
Vasiliy
- ФИО:Касимов Василий
- Город:Москва
Отправлено 21 июня 2019 — 09:13
Сьют это набор тест-кейсов.
Чеклист это список «быстрых» проверок.
-
0
- Наверх
#8
Little_CJIOH
Little_CJIOH
- ФИО:Власкин Павел
- Город:Санкт-Петербург
Отправлено 21 июня 2019 — 10:35
сьют — это набор тест кейсов объединенных некоей логикой ( по модулям системы, по пользовательским сценариям, по уровням тестирования.
чек-лист — это список-напоминалка что нужно сделать, в котором отмечается что уже сделано.
-
0
- Наверх
#9
Solovey_PO
Solovey_PO
-
- Members
-
- 4 сообщений
Новый участник
Отправлено 22 июня 2019 — 00:22
-
0
- Наверх
В чем разница между тестовым сценарием и тестовым случаем?
Я немного запутался в тестовых сценариях и тестовых примерах. Каковы различия между ними?
Допустим, мне нужно проверить коробок спичек. Правильно ли я говорю, что ниже могут быть примеры тестовых сценариев?
- может ли коробка содержать x спичек?
- скажем, коробка закрыта, и я энергично встряхиваю ее. Спички все еще в коробке?
Можете ли вы привести примеры тестовых сценариев и тестовых случаев?
Пример:
Вы тестируете свой телефон:
Сценарий: убедитесь, что устройство автоматически подключается к Wi-Fi, если пользователь создает новый профиль
Test cases:
case 1: create Wi-Fi profile and verify that it created successfully
case 2: verify that device succeeded to connect to Wi-Fi
В этом примере у вас есть один тестовый сценарий, который содержит 2 тестовых случая. Потому что 1-й относится к предварительное условие
Создан 03 июн.
Тестовый пример состоит из набора входных значений, предварительного условия выполнения, исключенных результатов и выполненного постусловия, разработанного для покрытия определенного тестового условия. В то время как тестовый сценарий — это не что иное, как тестовая процедура. Сценарии тестирования имеют связь один ко многим с тестовым набором, значит сценарий имеет несколько тестовых случаев. Каждый раз мы пишем тестовые примеры для тестового сценария. Итак, приступая к тестированию, сначала подготовьте тестовые сценарии, а затем создайте два разных тестовых примера для каждого сценария. Тестовые случаи выводятся (или пишутся) из тестового сценария. Сценарии являются производными от вариантов использования. Сценарий тестирования представляет собой серию связанных друг с другом действий. В то время как тестовый пример представляет собой одно (низкоуровневое) действие пользователя. Сценарий — это поток операций, где в качестве тестовых случаев используется набор входных и выходных данных, предоставляемых Системе. Например:
Проверка функциональности кнопки «Войти» — это тестовый сценарий, а тестовые примеры для этого тестового сценария: 1. Нажмите кнопку, не вводя имя пользователя и пароль. 2. Нажмите кнопку, введя только имя пользователя. 3. Нажмите кнопку при вводе неправильного имени пользователя и неправильного пароля. Так далее…
Тестовый сценарий — это «Что тестировать», а тестовый пример — «Как тестировать».
Создан 30 янв.
Проще говоря, сценарии тестирования предоставляют обзор того, что необходимо тестировать и в каких условиях. Принимая во внимание, что тестовые примеры описывают, как это условие будет проверено с положительным и отрицательным результатом путем изменения предварительных условий и необходимых переменных. Таким образом, 1 сценарий может иметь 1….1* связь с тестовым набором.
Например,
Senario 1 — пользователь подключается к веб-сайту, используя веб-URL, и получает доступ к своему профилю после успешного входа в систему в качестве первой страницы.
Тестовые примеры возможность входа в систему только с именем пользователя возможность входа только с паролем возможность входа в систему с именем пользователя и паролем возможность входа в систему с неправильным именем пользователя и паролем возможность просмотра профиля пользователя после входа в систему возможность просмотра истории заказов пользователей после входа в систему
Я надеюсь, что это имеет немного больше смысла. дайте мне знать, если вам нужны дополнительные примеры.
ответ дан 17 дек ’13, 14:12
Сценарий тестирования
Подтвердите страницу входа
Испытательные случаи
- Введите правильное имя пользователя и пароль
- Сбросить пароль
- Введите неверные учетные данные
Создан 31 янв.
Тест-кейсы — это то, что вы можете изобразить в проработанной форме.
Допустим, что тестовый сценарий является «страницей входа».
Учитывая этот тестовый сценарий, контрольные примеры вероятно, будут связаны со страницей входа и их атрибутами:
-
Подтвердите URL-адрес, чтобы отобразить страницу входа
-
Проверьте поле ввода имени пользователя и пароля в текстовом поле на странице входа.
-
Подтвердите предупреждающее сообщение, когда имя пользователя определено, но пароль пуст, и пользователь нажимает кнопку входа в систему.
-
Подтвердите предупреждающее сообщение, когда имя пользователя не определено, но есть пароль, и пользователь нажимает кнопку входа в систему.
Создан 31 янв.
В общем, прецедент означает как тест и тестовый сценарий что тестировать.
Вот пример с банкоматом.
Испытательные случаи
- Вставьте карту банкомата, которая действительна
- Введите свой пин-код
- Затем дисплей должен отображаться с такими опциями, как «снять», «проверить баланс» и т. д.
- Выберите нужный вариант
- Наконец, машина должна напечатать бумагу с подробностями
Тестовый сценарий
-
Вставьте банкоматную карту
-
Введите свой пин-код
-
Выберите один из вариантов
-
Введите сумму
-
Снять деньги со счета
Создан 31 янв.
Для данного примера: Тестирование приложения, такого как watsapp Тестовые сценарии: Проверка того, что пользователь может совершать видеозвонки. Тестовые примеры: чтобы убедиться, что пользователь может совершать видеозвонки на любой номер. Для проверки качества изображения. Чтобы убедиться, что приложение не падает при звонке.
ответ дан 10 мая ’22, 08:05
Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками
testing
or задайте свой вопрос.
What does the Test Case entail?
A test case is a set of criteria that a tester uses to verify whether or not a
software application is meeting the customer’s requirements.
Preconditions, case name, input conditions, and intended outcome are all
included in the test case design. A test case is a basic activity that is
derived from test scenarios.
It is a comprehensive document that comprises all potential inputs (both
positive and negative) as well as navigation instructions for the test
execution process. Writing test cases is a one-time effort that may be
reused for regression testing in the future.
The test case contains thorough information about the testing approach,
procedure, preconditions, and expected results. These are used during the
testing phase to see if the software program is capable of executing the
purpose for which it was created.
By associating a defect with a test case ID, test cases assist testers in
defect reporting. The testing team benefits from detailed test case
documentation because if the developer misses something, it may be
detected during the execution of these full-proof test cases.
To construct the test case, we need the requirements to extract the inputs,
as well as the test scenarios to ensure that we don’t overlook any testing
features. Then, to ensure uniformity, we should have a test case template,
or every test engineer should produce the test document in the same way.
Whenever the developer is busy creating code, we will usually write the test
case.
When should a test case be written?
When we have the following information, we will write the test case −
When the customer provides the business requirements, the developer
begins work and estimates that the product will take 3.5 months to
complete.
Meanwhile, the testing group will begin developing the test cases.
It will email it to the Test Lead for evaluation once it is completed.
The product is then turned over to the testing team once the developers
have finished building it.
Because testing is consistent and does not depend on the mood of the
person rather than the quality of the test engineer, test engineers never
glance at the requirement when testing the product document.
What is a Test Scenario, and how does it work?
Any functionality that may be tested is specified as a Test Scenario. It is a
collection of test scenarios that assists the testing team in determining the
project’s positive and negative features.
The Test Scenario provides a high-level overview of what has to be tested.
In liner statements, a test scenario is a complete list containing test cases
that cover the end-to-end functionality of a software program. A scenario is
defined as a linear statement. The test scenario is a categorization of
testable requirements at a high level. These criteria are categorized
according to a module’s functionality and derived from use cases.
Because there are so many test cases in the scenario, there is a thorough
testing process. The tester must evaluate the test cases for each scenario
before completing the test scenario.
Testers must put themselves in the shoes of the user in the test scenario
since they are testing the software application from the user’s perspective.
The most important aspect of the process is scenario preparation, which
necessitates seeking advice or assistance from consumers, stakeholders,
or developers.
Test Scenarios: How to Write Them
-
To build Test Scenarios as a tester, follow these steps
-
Examine the software’s requirement documents, such as the BRS
(Business Requirement Specification), SRS (System Requirement
Specification), and FRS (Functional Requirement Specification). -
For each need, determine all technical factors and objectives.
-
Find every feasible way for the user to interact with the software.
-
Determine all conceivable scenarios in which the system might be
abused, as well as users who could be hackers. -
Make a list of possible test cases to check each function of the
program after reading the requirement document and completing the
planned analysis. -
Create a traceability matrix once you’ve identified all of the available
test scenarios to see if each requirement has a matching test scenario or not. -
All possibilities are reviewed by the project supervisor. They are then
reviewed by the project’s other stakeholders.
Characteristics of the Test Scenario
-
The test scenario is a one-liner that directs testers through the testing
process. -
The product’s complexity and repetition are reduced by using a test
scenario. -
A test scenario is when you speak and think about tests in great
detail yet write them down in linear statements. -
It’s a series of procedures threaded together.
-
When the tester does not have enough time to develop test cases
and the team agrees on a comprehensive liner scenario, the test
scenario becomes more significant. -
The test scenario is a useful exercise for saving time.
-
It is simple to maintain since adding and modifying test cases is
simple and self-contained.
Exercising a Test Scenario
A few test cases for an eCommerce application might be −
-
Scenario 1 − Examine the Search Functions
-
Check the Payments Functionality in Scenario 2
-
Check the Login Functionality in Scenario 3
The Main Difference
-
A test case is a collection of actions that are carried out to check
certain features or functionality, whereas a test scenario is any
capability that may be evaluated. -
Test Scenarios are derived from test artifacts such as BRS and SRS,
whereas Test Cases are derived from test scenarios. -
Test Cases aid in the thorough testing of an application, whereas
Test Scenarios aid in the testing of end-to-end functionality in a more
agile manner. -
Test Cases are more concerned with what to test and how to test,
whereas Test Scenarios are more concerned with what to test. -
Low-level activities are Test Cases, whereas high-level actions are
Test Scenarios. -
Test Cases necessitate more resources and time to execute,
whereas Test Scenarios necessitate fewer resources and time. -
Test Cases include test procedures, data, and anticipated outcomes,
whereas Test Scenarios contain end-to-end functionality to be
evaluated.
Test Cases as an Example
There would be test cases for the Test Scenario: «Check the Login
Functionality.»
-
When a valid email address and password are entered, observe the
system’s reaction. -
When an incorrect email address and a legitimate password are
supplied, observe the system’s behavior. -
When a legitimate email address and an incorrect password are
submitted, observe the system’s behavior. -
Check the system’s response when an incorrect email address and
password are submitted. -
Examine the system’s behavior when the email address and
password are left blank and the Sign-in button is pressed. -
Make sure Forgot your password is working properly.
-
When a valid or incorrect phone number and password are entered,
observe the system’s behavior. -
When «Keep me signed» is selected, observe the system’s actions.
Why do we write Test Cases in the first place?
Here are a few compelling reasons to develop a Test Case
-
Test cases aid in the verification of compliance with relevant
standards, guidelines, and client needs. -
Assists you in validating client expectations and requirements.
-
Control, logic, and data flow coverage have all been improved.
-
You may play around with real end-user scenarios.
-
exposes flaws or faults
-
The test engineer’s job will be more structured and simpler when test
cases are developed for test execution.
What is the purpose of writing a Test Scenario?
The following are some compelling reasons to build a Test Scenario
-
The primary goal of writing a test scenario is to ensure that the
software application’s whole functioning is verified. -
It also aids in ensuring that business processes and flows are in
compliance with functional requirements. -
To guarantee that the Application Under Test is adequately tested,
multiple stakeholders such as Business Analysts, Developers, and
Customers can approve Test Scenarios. It assures that the program
functions properly in the most prevalent scenarios. -
They are useful for determining the testing work effort and, as a
result, creating a proposal for the customer or organizing the
workforce. -
They aid in the identification of the most crucial end-to-end
transactions or the actual use of software programs. -
Test cases may simply be produced from these Test Scenarios once
they’ve been finalized.
What is the difference between a test case and a test scenario?
There are important distinctions between a Test Case and a Test Scenario.
| Test Scenario | Test Case |
|---|---|
| A test scenario is a high-level document that defines the functionality to be tested from beginning to end. |
For evaluating all of an application’s functionality, test cases contain specified test procedures, data, and expected results. |
| It emphasizes «what to test» rather than «how to test.» |
The emphasis is entirely on «what to test» and «how to test.» |
| A one-liner is a test case. As a result, there is always the risk of ambiguity during testing |
A step, pre-requisites, intended outcome, and so on are all described in test cases. As a result, there is no room for misunderstanding in this procedure |
| BRS, SRS, and other test artifacts are used to create test scenarios. |
The majority of test cases are derived from test scenarios. A single Test Scenario might provide several test cases. |
| It aids in the rapid testing of end-to-end functionality. |
It aids in the thorough testing of an application. |
| High-level actions are used in test scenarios. |
Low-level actions are what test cases are. |
| Creating and testing scenarios requires significantly less time and money. |
More resources are required for test case documentation and execution. |
Example of a Test Case
-
Test cases should be clear and easy to understand.
-
Create a test case with the end-user in mind.
-
Repetition of test cases should be avoided.
-
You must ensure that test cases are written to ensure that all
software requirements specified in the specification document are met. -
When creating a test case, never make assumptions about the
functioning and features of your software application. -
The test cases must be easily distinguishable.
Example of a Test Scenario
-
The majority of test cases are single-line statements that specify what
should be tested. -
The scenario description should be straightforward and easy to
comprehend. -
A thorough examination of the specified criteria should be carried out.
-
Before commencing the testing process, gather the necessary tools
and resources.
What does the Test Case entail?
A test case is a set of criteria that a tester uses to verify whether or not a
software application is meeting the customer’s requirements.
Preconditions, case name, input conditions, and intended outcome are all
included in the test case design. A test case is a basic activity that is
derived from test scenarios.
It is a comprehensive document that comprises all potential inputs (both
positive and negative) as well as navigation instructions for the test
execution process. Writing test cases is a one-time effort that may be
reused for regression testing in the future.
The test case contains thorough information about the testing approach,
procedure, preconditions, and expected results. These are used during the
testing phase to see if the software program is capable of executing the
purpose for which it was created.
By associating a defect with a test case ID, test cases assist testers in
defect reporting. The testing team benefits from detailed test case
documentation because if the developer misses something, it may be
detected during the execution of these full-proof test cases.
To construct the test case, we need the requirements to extract the inputs,
as well as the test scenarios to ensure that we don’t overlook any testing
features. Then, to ensure uniformity, we should have a test case template,
or every test engineer should produce the test document in the same way.
Whenever the developer is busy creating code, we will usually write the test
case.
When should a test case be written?
When we have the following information, we will write the test case −
When the customer provides the business requirements, the developer
begins work and estimates that the product will take 3.5 months to
complete.
Meanwhile, the testing group will begin developing the test cases.
It will email it to the Test Lead for evaluation once it is completed.
The product is then turned over to the testing team once the developers
have finished building it.
Because testing is consistent and does not depend on the mood of the
person rather than the quality of the test engineer, test engineers never
glance at the requirement when testing the product document.
What is a Test Scenario, and how does it work?
Any functionality that may be tested is specified as a Test Scenario. It is a
collection of test scenarios that assists the testing team in determining the
project’s positive and negative features.
The Test Scenario provides a high-level overview of what has to be tested.
In liner statements, a test scenario is a complete list containing test cases
that cover the end-to-end functionality of a software program. A scenario is
defined as a linear statement. The test scenario is a categorization of
testable requirements at a high level. These criteria are categorized
according to a module’s functionality and derived from use cases.
Because there are so many test cases in the scenario, there is a thorough
testing process. The tester must evaluate the test cases for each scenario
before completing the test scenario.
Testers must put themselves in the shoes of the user in the test scenario
since they are testing the software application from the user’s perspective.
The most important aspect of the process is scenario preparation, which
necessitates seeking advice or assistance from consumers, stakeholders,
or developers.
Test Scenarios: How to Write Them
-
To build Test Scenarios as a tester, follow these steps
-
Examine the software’s requirement documents, such as the BRS
(Business Requirement Specification), SRS (System Requirement
Specification), and FRS (Functional Requirement Specification). -
For each need, determine all technical factors and objectives.
-
Find every feasible way for the user to interact with the software.
-
Determine all conceivable scenarios in which the system might be
abused, as well as users who could be hackers. -
Make a list of possible test cases to check each function of the
program after reading the requirement document and completing the
planned analysis. -
Create a traceability matrix once you’ve identified all of the available
test scenarios to see if each requirement has a matching test scenario or not. -
All possibilities are reviewed by the project supervisor. They are then
reviewed by the project’s other stakeholders.
Characteristics of the Test Scenario
-
The test scenario is a one-liner that directs testers through the testing
process. -
The product’s complexity and repetition are reduced by using a test
scenario. -
A test scenario is when you speak and think about tests in great
detail yet write them down in linear statements. -
It’s a series of procedures threaded together.
-
When the tester does not have enough time to develop test cases
and the team agrees on a comprehensive liner scenario, the test
scenario becomes more significant. -
The test scenario is a useful exercise for saving time.
-
It is simple to maintain since adding and modifying test cases is
simple and self-contained.
Exercising a Test Scenario
A few test cases for an eCommerce application might be −
-
Scenario 1 − Examine the Search Functions
-
Check the Payments Functionality in Scenario 2
-
Check the Login Functionality in Scenario 3
The Main Difference
-
A test case is a collection of actions that are carried out to check
certain features or functionality, whereas a test scenario is any
capability that may be evaluated. -
Test Scenarios are derived from test artifacts such as BRS and SRS,
whereas Test Cases are derived from test scenarios. -
Test Cases aid in the thorough testing of an application, whereas
Test Scenarios aid in the testing of end-to-end functionality in a more
agile manner. -
Test Cases are more concerned with what to test and how to test,
whereas Test Scenarios are more concerned with what to test. -
Low-level activities are Test Cases, whereas high-level actions are
Test Scenarios. -
Test Cases necessitate more resources and time to execute,
whereas Test Scenarios necessitate fewer resources and time. -
Test Cases include test procedures, data, and anticipated outcomes,
whereas Test Scenarios contain end-to-end functionality to be
evaluated.
Test Cases as an Example
There would be test cases for the Test Scenario: «Check the Login
Functionality.»
-
When a valid email address and password are entered, observe the
system’s reaction. -
When an incorrect email address and a legitimate password are
supplied, observe the system’s behavior. -
When a legitimate email address and an incorrect password are
submitted, observe the system’s behavior. -
Check the system’s response when an incorrect email address and
password are submitted. -
Examine the system’s behavior when the email address and
password are left blank and the Sign-in button is pressed. -
Make sure Forgot your password is working properly.
-
When a valid or incorrect phone number and password are entered,
observe the system’s behavior. -
When «Keep me signed» is selected, observe the system’s actions.
Why do we write Test Cases in the first place?
Here are a few compelling reasons to develop a Test Case
-
Test cases aid in the verification of compliance with relevant
standards, guidelines, and client needs. -
Assists you in validating client expectations and requirements.
-
Control, logic, and data flow coverage have all been improved.
-
You may play around with real end-user scenarios.
-
exposes flaws or faults
-
The test engineer’s job will be more structured and simpler when test
cases are developed for test execution.
What is the purpose of writing a Test Scenario?
The following are some compelling reasons to build a Test Scenario
-
The primary goal of writing a test scenario is to ensure that the
software application’s whole functioning is verified. -
It also aids in ensuring that business processes and flows are in
compliance with functional requirements. -
To guarantee that the Application Under Test is adequately tested,
multiple stakeholders such as Business Analysts, Developers, and
Customers can approve Test Scenarios. It assures that the program
functions properly in the most prevalent scenarios. -
They are useful for determining the testing work effort and, as a
result, creating a proposal for the customer or organizing the
workforce. -
They aid in the identification of the most crucial end-to-end
transactions or the actual use of software programs. -
Test cases may simply be produced from these Test Scenarios once
they’ve been finalized.
What is the difference between a test case and a test scenario?
There are important distinctions between a Test Case and a Test Scenario.
| Test Scenario | Test Case |
|---|---|
| A test scenario is a high-level document that defines the functionality to be tested from beginning to end. |
For evaluating all of an application’s functionality, test cases contain specified test procedures, data, and expected results. |
| It emphasizes «what to test» rather than «how to test.» |
The emphasis is entirely on «what to test» and «how to test.» |
| A one-liner is a test case. As a result, there is always the risk of ambiguity during testing |
A step, pre-requisites, intended outcome, and so on are all described in test cases. As a result, there is no room for misunderstanding in this procedure |
| BRS, SRS, and other test artifacts are used to create test scenarios. |
The majority of test cases are derived from test scenarios. A single Test Scenario might provide several test cases. |
| It aids in the rapid testing of end-to-end functionality. |
It aids in the thorough testing of an application. |
| High-level actions are used in test scenarios. |
Low-level actions are what test cases are. |
| Creating and testing scenarios requires significantly less time and money. |
More resources are required for test case documentation and execution. |
Example of a Test Case
-
Test cases should be clear and easy to understand.
-
Create a test case with the end-user in mind.
-
Repetition of test cases should be avoided.
-
You must ensure that test cases are written to ensure that all
software requirements specified in the specification document are met. -
When creating a test case, never make assumptions about the
functioning and features of your software application. -
The test cases must be easily distinguishable.
Example of a Test Scenario
-
The majority of test cases are single-line statements that specify what
should be tested. -
The scenario description should be straightforward and easy to
comprehend. -
A thorough examination of the specified criteria should be carried out.
-
Before commencing the testing process, gather the necessary tools
and resources.
Что такое контрольный пример?
TEST СЛУЧАЙ представляет собой набор действий , выполняемых для проверки конкретной функции или функциональности вашего приложения. Тестовый набор содержит шаги теста, данные теста, предварительное условие, постусловие, разработанное для конкретного тестового сценария для проверки любого требования. Тестовый пример включает в себя конкретные переменные или условия, с помощью которых инженер-тестировщик может сравнивать ожидаемые и фактические результаты, чтобы определить, работает ли программный продукт в соответствии с требованиями заказчика.
Что такое тестовый сценарий?
Сценарий тестирования определяется как любая функциональность, которую можно протестировать. Это совокупность тестовых случаев, которая помогает команде тестирования определить положительные и отрицательные характеристики проекта.
Сценарий тестирования дает общее представление о том, что нам нужно тестировать.
Пример тестового сценария
Для приложения электронной коммерции несколько тестовых сценариев
Тестовый сценарий 1: проверка функциональности поиска
Тестовый сценарий 2: проверка функциональности платежей
Тестовый сценарий 3: проверка функциональности входа
Пример тестовых случаев
Тестовые сценарии для сценария тестирования: «Проверка функциональности входа» будет
- Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
- Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
- Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
- Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
- Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
- Проверить Забыли пароль работает как положено
- Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
- Проверять поведение системы, когда установлен флажок «Держать меня в подписи»
Почему мы пишем тестовые случаи?
Вот несколько важных причин для создания контрольного примера:
- Контрольные примеры помогают проверить соответствие применимым стандартам, рекомендациям и требованиям клиентов
- Помогает вам подтвердить ожидания и требования клиентов
- Улучшенный контроль, логика и покрытие потока данных
- Вы можете смоделировать «реальные» сценарии конечного пользователя
- Выявляет ошибки или дефекты
- Когда тестовые случаи написаны для выполнения теста, работа инженера по тестированию будет организована лучше и упрощена
Почему мы пишем тестовый сценарий?
Вот важные причины для создания сценария тестирования:
- Основной причиной написания тестового сценария является проверка всей функциональности программного приложения.
- Это также поможет вам убедиться, что бизнес-процессы и потоки соответствуют функциональным требованиям.
- Сценарии тестирования могут быть одобрены различными заинтересованными сторонами, такими как бизнес-аналитик, разработчики, клиенты, для обеспечения тщательного тестирования тестируемого приложения. Это гарантирует, что программное обеспечение работает для наиболее распространенных случаев использования.
- Они служат быстрым инструментом для определения трудозатрат на тестирование и, соответственно, создают предложение для клиента или организуют рабочую силу.
- Они помогают определить наиболее важные сквозные транзакции или реальное использование программных приложений.
- Как только эти тестовые сценарии будут завершены, тестовые примеры могут быть легко получены из тестовых сценариев.
Тестовый случай и тестовый сценарий
Здесь есть существенные различия между тестовым сценарием и тестовым набором
| Тестовый сценарий | Прецедент |
|---|---|
| Тестовый сценарий содержит высокоуровневую документацию, в которой описывается сквозная функциональность, подлежащая тестированию. | Контрольные примеры содержат определенные этапы тестирования, данные, ожидаемые результаты для тестирования всех функций приложения. |
| В нем больше внимания уделяется «что проверять», чем «как проверять». | Полный акцент на «что тестировать» и «как тестировать». |
| Тестовые сценарии являются однострочными. Таким образом, всегда есть вероятность неоднозначности во время тестирования. | Контрольные примеры определили шаг, предварительные условия, ожидаемый результат и т. Д. Поэтому в этом процессе нет никакой двусмысленности. |
| Тестовые сценарии получены из тестовых артефактов, таких как BRS, SRS и т. Д. | Контрольный пример в основном получен из тестовых сценариев. Несколько тестовых случаев могут быть получены из одного тестового сценария |
| Это помогает в гибком способе тестирования сквозной функциональности | Помогает в исчерпывающем тестировании приложения |
| Тестовые сценарии – это действия высокого уровня. | Тестовые случаи – действия низкого уровня. |
| Сравнительно меньше времени и ресурсов требуется для создания и тестирования с использованием сценариев. | Для документирования и выполнения контрольных примеров требуется больше ресурсов. |
Лучшие практики создания тестовых случаев
- Тестовые случаи должны быть прозрачными и понятными
- Создайте контрольный пример, помня конечного пользователя
- Избегайте повторения тестовых случаев
- Вам необходимо убедиться, что вы напишете тестовые наборы для проверки всех требований к программному обеспечению, упомянутых в документе спецификации.
- Никогда не принимайте на себя функциональность и возможности вашего программного приложения при подготовке тестового примера.
- Тестовые случаи должны быть легко идентифицируемыми
Лучшие практики создания сценария тестирования
- Тестовые сценарии – это в основном однострочный оператор, который говорит, что следует тестировать
- Описание сценария должно быть простым и легким для понимания
- Тщательная оценка заявленных требований должна быть сделана
- Необходимые инструменты и ресурсы для тестирования должны быть собраны до начала процесса тестирования
КЛЮЧЕВАЯ РАЗНИЦА
- Тестовый набор – это набор действий, выполняемых для проверки определенных функций или функциональности, тогда как сценарий тестирования – это любая функциональность, которую можно протестировать.
- Тестовый набор в основном получен из тестовых сценариев, в то время как тестовые сценарии получены из тестовых артефактов, таких как BRS и SRS.
- Test Case помогает в исчерпывающем тестировании приложения, тогда как Test Scenario помогает в гибком способе тестирования сквозной функциональности.
- Тестовые случаи направлены на то, что тестировать и как тестировать, в то время как тестовый сценарий больше ориентирован на то, что тестировать.
- Тестовые случаи – действия низкого уровня, тогда как тестовые сценарии – действия высокого уровня.
- Test Case требует больше ресурсов и времени для выполнения теста, в то время как Сценарий тестирования требует меньше ресурсов и времени для выполнения теста.
- Тестовый набор включает в себя этапы тестирования, данные, ожидаемые результаты для тестирования, тогда как сценарий тестирования включает в себя сквозную функциональность, подлежащую тестированию.
Тест-анализ и тест дизайн
latest update of the page: 17-01-2023, 21:53 UTC
Тест-анализ
Тест-анализ = процесс поиска и рассмотрения информации, необходимой для тестирования. Обычно она есть у людей с хорошими знаниями о системе и способах её использования, в документации (требования, спецификации, описания архитектуры и интеграции и т.п).
Такая информация нужна для составления тест-кейсов.
Исполняющему роль тест-аналитика необходимо (в общем случае):
-
Знать, кто является причастными сторонами (т.н. стейкхолдерами): кто владелец проекта, владелец продукта, заказчики/клиенты, исполнители работ по проектированию, разработке, тестированию и сопровождению системы.
Ибо крайне важно понимать, кто будет поставщиком информации (например, архитекторы, аналитики, разработчики, админы/девопс), а кто будет потребителем наших информационных артефактов (например, проектные/продуктовые менеджеры и тестировщики). - Держать в голове для каких целей создан Продукт/Система, кто и каким образом будет его использовать.
- Выяснять суть реализации (общесистемной или конкретного инкремента): какова архитектура, какие компоненты дорабатываются.
- Определять необходимое и возможное тестовое покрытие (что будем тестировать и на какую «глубину»), необходимые виды тестирования.
- (опционально) Определить риски тестирования. Они способны серьёзно повлиять на оценку сроков тестирования.
- (опционально) Составить Матрицу трассировки требований
Тестовое покрытие
Тестовое покрытие = покрытие тестами требований к продукту/системе, выраженное в численном либо процентном соотношении. Тестовое покрытие является одной из основных метрик качества продукта.
Иногда под тестовым покрытием имеют в виду покрытие критериев приёмки, покрытие кода. Кто-то считает покрытие только автотестами.
Тестовое покрытие говорит о добротности тестирования, о степени доверия к производимому продукту, о наличие и масштабах «белых пятен», где выше риск пропуска ошибок.
Процесс определения покрытия кратко картинкой:
скачать схему в формате diagrams.net (бывший draw.io)
Итак, мы прошли этап определения причастных сторон, ознакомились с документацией, держим в голове архитектуру, требования к системе, критерии приёмки доработок.
Теперь надо определиться с объёмом тестирования и видами тестирования.
Проводим логическую декомпозицию Системы, определяя:
- сущности (задействованные чаще всего, самые важные), связи сущностей, модель их статусов/состояний, возможные действия с сущностями (CRUD, фильтрация, сортировка, поиск, экспорт, импорт, валидация, парсинг, копирование).
- бизнес-процессы, use cases (user scenarios, system scenarios), проходящие в продукте.
- входящую и исходящую интеграции, каким способом она происходит (ETL, RPC, REST API, file, MQ и т.д.) и с чем.
- ролевая модель — какие роли с какими правами; на какие бизнес-процессы, use cases и на работу с какими сущностями она распространяется.
- UI как те или иные виды экранных форм в web-, desktop-, mobile-приложении. Или даже TUI.
- CLI (command-line interface) и возможные команды приложению посредством командной строки.
- Варианты конфигурации приложения.
Теперь прикидываем какими видами тестирования с какими тест-сценариями это счастье можно покрыть:
| Вид тестирования | Примеры тестов |
|---|---|
| Функциональное позитивное (в т.ч. безопасности) |
|
| Функциональное негативное (в т.ч. безопасности) |
|
Нефункциональное:
|
|
В итоге получаем своего рода наброски (drafts) тест-кейсов, которые дальше уже далее потребуется детализировать по шагам.
Уже становится ПРИМЕРНО виден объём возможного тестирования, можно ПРИМЕРНО прикинуть сколько времени займёт как тест-дизайн по этим черновикам (детализация тест-кейсов), так и время прохождения всех этих тестов.
Заодно можно прикинуть какие из этих тест-кейсов целесообразно пустить потом в автоматизацию.
Трассировка требований и тест-кейсов
Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.
Матрица может включать в себя параметры в зависимости от ваших нужд на проекте
- ID Бизнес-Требования (BR, Business Requirement) или Бизнес Варианта Использования (Business Use Case);
- суть Бизнес-Требования;
- (опционально) приоритет Бизнес-Требования;
- (опционально) приёмочный критерий Требования (acceptance criteria);
- (опционально) ID Функционального требования (FR, functional requirement) из Спецификации к Требованиям ПО (SRS) или ID Варианта Использования (UC, Use Case);
- (опционально) описание Функционального требования или Варианта Использования;
- ID тестового артефакта (Тест-кейса);
- (опционально) ожидаемый результат Тест-кейса (expected result);
- (опционально) номер Задачи на разработку из таск-трекера + её описание;
- (опционально) логический блок / модуль, к которому принадлежит Задача/Требование;
Примеры Матриц Трассировки:
-
# Block of feature Issue for development Acceptance criteria Priority Test-case 1 Create Creating User should be able to create new document High Test #1: Create document 2 User should not be able to create new document, if he has role = «Reviewer» High Test #14: Reviewer should not be able to create new doc 3 Print Document printing User should be able to print a document High Test #2: Print a document 4 .doc, .pdf, .docx, .rtf formats of a document should be able to be printed High Test #4: Check-list for doc formats N … … … Low / Medium / High link to TC -
(скачать таблицу в формате XLSX)
Для каждого Бизнес-Требования будет одно или несколько Функциональных (Системных) Требований, его реализующих. Соответственно, каждое системное требование должно иметь критерии приёмки, которые должны быть покрыты тестами.
Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:
скачать схему в формате diagrams.net (бывший draw.io)
Если вы используете таск-трекер Jira (и её плагины Zephyr Scale (Zephyr Squad) — Test Management for Jira) для тестовой документации и систему управления требованиями Сonfluence, то JIRA-таски и Confluence-страницы можно привязывать к тест-кейсам, в JIRA-тасках создавать связи с тестовыми прогонами, и такая трассируемость позволяет:
- визуализировать актуальное состояние реализации;
- разбивать требования на более атомарные и структурировать их;
- отслеживать, есть ли требования, на которые еще не запланирована разработка (пропуск реализации);
- отслеживать, реализовано ли требование в данный момент;
- отслеживать, покрыто ли требование тест-кейсом (пропуск тестирования);
- наглядно отображать приоритизацию требований.
Соотношение привязки Требования и Тест-кейса может быть:
- 1 к 1 (атомарное требование, которое покрывается одним тест-кейсом, данный тест-кейс покрывает только это требование);
-
1 к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают только это требование);
когда одно требование в матрице трассируемости покрывается несколькими тестами, это может говорить об избыточности тестирования. В таком случае надо проанализировать, насколько требование атомарно. - n к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают это и другие требования).
Программные комплексы для управления требованиями:
- (очень платное) IBM Rational DOORS
- (платное)(есть trial на 14 дней) Cradle
- (платное) DevProm Requirements. Один из функциональных блоков программного продукта Devprom ALM
- (платный) плагин RMsis для Atlassian JIRA
- (платный) плагин R4J для Atlassian JIRA
Риски качества
Риск качества (Quality risk) — потенциальный вид ошибки, способ поведения системы, при котором она, вероятно, не соответствует обоснованным ожиданиям качества системы, имеющимся у пользователя или заказчика. Это потенциальный, а не обязательный результат.
| Общие категории рисков качества | |
|---|---|
| Функциональность | Проблемы, в результате которых не работают конкретные функции |
| Нагрузка, производительность, объём | Проблемы обработки ожидаемых пиковых нагрузок при параллельной работе нескольких пользователей |
| Надёжность, стабильность работы | Проблемы, при которых система слишком часто зависает или долго не восстанавливается |
| Перегрузки, обработка ошибок и восстановление | Проблемы, возникающие ввиду превышения допустимых пиковых нагрузок или из-за обработки недопустимых условий (например, побочный эффект от сознательного внесения ошибок) |
| Обработка времени и дат | Ошибки в математических действиях с датами и временем, в их форматировании, в планируемых событиях и других операциях, зависящих от времени |
| Качество данных | Ошибки в обработке, извлечении и хранении данных |
| Производительность | проблемы с временем завершения задач при ожидаемой нагрузке |
| Локализация | проблемы, связанные с локализацией продукта, в том числе в обработке страницы символов, языковой поддержке, в использовании грамматики, словаря, а также в сообщениях об ошибках и файлах помощи |
| Безопасность | проблемы в защите системы и охраняемых данных от мошеннического и злонамеренного использования |
| Установка/перенос | ошибки, которые препятствуют поставке системы |
| Документирование | ошибки в руководствах по установке и работе с системой для пользователей и системных администраторов |
Из этого также следует вывод о том, насколько важно изучить требования заказчика, придерживаться их и здравого смысла (заказчик не всегда прав, иногда полезно намекнуть ему о потенциальных рисках в результате реализации какого-либо из его легкомысленных требований).
Риски тестирования
Основные риски тестирования:
-
Проектные — связанные с коммуникациями участников команды, инфраструктурой:
— изменение скоупа тестирования после проверки основных тест-кейсов
… -
Продуктовые — связанные только с тестируемыми функциями и тестовыми средам:
— отсутствие тестовых зон с заданной конфигурацей (медленные БД, (не)обезличенные БД, отсутствие каких-то тестовых данных)
— недопустимое время на ожидание подготовки тестовых зон со стороны Администраторов / DevOps
…
Тест дизайн
Проектирование тестов (test design) = процесс проектирования и создания тест-кейсов (тестовых случаев/сценариев/дел, case — юр. «дело»), в соответствии с определёнными ранее критериями качества, целями тестирования, критериями приёмки.
Тест-кейс
Тестовый случай (Test Case) = артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Этимология слова case восходит к юридиспруденции. Case — дело, случай.
В тестировании мы, по-сути, с помощью тест-кейсов, предоставляющих нам свидетельства и факты, поддерживаем аргументы, обосновывая ими заявления о том, что проверяемая Система/ПО/Продукт соответствуют требованиям.
скачать схему в формате diagrams.net (бывший draw.io)
Исчерпывающий формат тест-кейса
- Название (subject)
- Описание (description) — что проверяем, некие важные подробности
- Трассировка (tracing) — ссылки на таск и страницу с требованиями к проверяемой тест-кейсом функциональности, юзкейс, юзерстори ссылки на бегрепорты по тест-кейсу
-
Предусловия (preconditions), например:
- Учётные записи и настройки ролей: имеется такая-то учётная запись, JWT, так-то настроена аутентификация и авторизация, учётной записи назначены такие-то права/роли.
-
Развёрнуто и настроено: развёрнуто A,B,C, перечисление критически важных для теста атрибутов конфигурации.
Возможно, ссылка на репозиторий, регистр с контейнерами скрипты деплоя и инструкции при наличии - Данные: в Системах A,B,C (их БД) созданы такие-то экземпляры сущностей / имеются такие-то данные, которые понадобятся в процессе теста.
-
«Тело» тест-кейса, обычно в виде таблицы такого вида:
№ п/п Действие Ожидаемый результат Результат 1 Делаем вот это Видим вот это, это и это <успех / неудача, комментарий с подробностями фактического результата при неудаче> N … … …
Методы разработки тестов
В общем случае нам требуется протестировать некую функцию системы. Часто, данные для функции и сам путь исполнения функции подразумевают некоторую вариативность. Нижеперечисленные техники как раз помогают определиться с тем, как именно подступиться к тестированию вариативности всего этого добра.
Причина / Следствие (Cause/Effect)
Простая проверка действий и их результата. Как правило, ввод комбинаций условий (Причин) для получения ответа от системы (Следствие).
Например, вы проверяете возможность добавлять клиента, используя определённую экранную форму. Пользователю необходимо заполнить несколько полей — «Имя», «Адрес», «Номер Телефона» — а затем нажать кнопку «Добавить». Это Причина. После нажатия кнопки «Добавить» система добавляет клиента в БД и показывает его номер на экране — это Следствие.
Примерный алгоритм:
- Выискиваем и связываем причины и следствия в спецификации
- Учитываем «невозможные» сочетания причин и следствий
- Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец это готовый тестовый сценарий
- Приоритизируем решения.
Тестирование смены состояний (State Transition Testing)
Когда в Системе есть сущности (объекты), которые могут принимать различные состояния, то неплохо бы проверить, что предусмотренные требованиями переходы возможны к осуществлению, а непредусмотренные — невозможны.
Пример:
скачать схему в формате diagrams.net (бывший draw.io)
Подробнее: Тестирование на основе диаграмм состояний сущности (2015).
Таблица решений (Decision Table Testing)
Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:
Чуть подробнее: Decision Table Testing: Learn with Example
Тестирование путей (Path Testing)
Часто под ним имеется в виду метод тестирования белого ящика Control Flow Testing (тестирование управляемого потока), в котором тест-кейсами покрываются все логические потоки ПО. Подробнее можно прочитать здесь:
- Path Testing & Basis Path Testing with EXAMPLES
- Control Flow Testing
Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений. Если условия ветвлений зависят от значений каких-то данных, то скорее всего, для каждого тест-сценария необходимо, опираясь на диаграмму, определить набор входных данных.
Очень упрощённо:
Посмотреть/послушать о такого рода применении метода можно здесь Где логика?! История тестирования одного микросервиса (Денис Кудряшов, Leroy Merlin, 2020), где докладчик скомбинировал этот метод с вышеупомянутой таблицей решений (Decision Table Testing).
Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)
- Если область определения параметра — диапазон каких-то упорядоченных данных, то имеет смысл выделение трёх т.н. классов эквивалентности: «слева» от диапазона (невалидные значения), «внутри» диапазона (валидные значения) и «справа» от диапазона (снова невалидные). При выделении классов нужно использовать включающие границы с целью однозначности и точности: одно и то же значение не может относиться к двум классам одновременно.
Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения. - Если область определения это набор неупорядоченных данных, то всегда можно выделить как минимум два класса — валидные и невалидные значения.
Полученное разбиение можно «дробить» дальше. Например, множество латинских букв можно разбить на два подмножества: латинница в верхнем и нижнем регистре.
Пример:
Попарное тестирование (Pairwise Testing)
Метод, основывающийся на тестировании комбинаций, с учётом того, чтобы каждое значение всех параметров хотя бы единожды сочеталось в проверках с другими значениями остальных параметров. Метод сильно уменьшает объём тестирования, но увеличивает вероятность пропуска дефекта.
Пример оптимизации количества тестов этим методом:
Подробнее: ПОПАРНОЕ ТЕСТИРОВАНИЕ (PAIRWISE TESTING) (2018).
Предугадывание ошибки (Error Guessing)
Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «здесь пользователь должен ввести код». Тест-аналитик выдвигает предположения: «Что, если я не введу код?», «Что, если я введу неправильный код?» и так далее. Это и есть предугадывание ошибки.
Иногда, под этим методом имеется в виду своеобразная «чуйка» у хорошо знающего систему тест-аналитика/тестировщика, когда при проверке функциональности X он даже неосознанно (опыт!) решает «на всякий случай» проверить дополнительно ещё функциональность Y, где могут «всплывать» ошибки.
Тесно связано с понятием импакт-анализа.
Исчерпывающее тестирование (Exhaustive Testing)
Бескомпромиссный случай — в пределах этой техники вы должны проверить реакцию Системы на все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода часто не представляется возможным, из-за огромного количества входных значений.