Тестовое покрытие тестовый сценарий тестовый пакет

Для того чтобы понять достаточно ли
разработано тестов, необходимо

измерять
полноту тестирования, которое называется
тестовое покрытие.

Структурное: степень покрытия тестами
структуры – кода, подсистемы или
компонентов — в системе, предназначенной
для тестирования.

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

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

1. Разработка общих алгоритмов тестирования

3.1. Тестовые сценарии и их выполнение

Test
Case (пер. с англ. «Тестовый случай») –
последовательность шагов, которые
необходимо выполнить.

Test Suite
(пер. с англ. «Тестовый набор») – набор
логически связанных тестовых сценариев
[14].

Алгоритм тестирования — это набор Tast
Case, другими словами Test Suite. Ниже
представлены таблицы разбитые по
выработанным критериям тестирования,
каждая из которых содержит обобщенный
набор Test Case.

• Функциональность.
  

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

Таблица
2 – Тестовые сценарии функциональности

Продолжение
таблицы 2

Продолжение
таблицы 2

• Нагрузка.

Так как большинство электронных курсов
используют либо Internet, либо Intranet, то не
обойтись без нагрузочного тестирования
количества подключаемых пользователей.
Некоторые варианты тестирования
представлены в таблице 3.

Таблица
3 – Тестовые сценарии нагрузочного
тестирования

Продолжение
таблицы 3

• Обработка
  дат и времени.

Правильная обработка всех математических
составляющих электронных курсов таблица
4.

Таблица
4 – Тестовые сценарии по обработке дат
и времени

Продолжение
таблицы 4

• Качество
  данных.

Изначальное качество и правдивость
предоставляемой информации должно быть
определено еще на этапе сбора требований
к разрабатываемому курсу. В таблице 5
представлены тестовые сценарии по
проверки качества данных.

Таблица
5 – Тестовые сценарии по качеству данных

Продолжение
таблицы 5

• Локализация.

Электронные курсы, как уже говорилось,
чаще всего используют сеть. Вопрос
локализации электронных курсов
затрагивает такие понятия, как
кроссбраузерность, отображение и
загрузка курсов в разных условиях и
т.д. В таблице 6 представлены варианты
тестовых сценариев.

Таблица
6 – Тестовые сценарии локализации

• Безопасность.

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

• Документирование.

Документирование сложных систем
происходит еще с этапа сбора требований.

Таблица
7 – Тестовые сценарии по документированию

• Удобство
  использования.

Последнее время все большее внимание
уделяется Usability (в пер. с
англ. «удобство использования»). Вопросы
связанные с удобством и понимание
каких-либо систем должны быть тщательно
рассмотрены, в том числе в электронных
курсах. Варианты, когда пользователь
не понимает вопросов или навигации
системы, влечет за собой отказ от данного
продукта и последующее падение престижа
и прибыли компании. В таблице 8 представлены
варианты тестовых сценариев по удобству
использования.

Таблица
8 – Тестовые сценарии по Usability

Продолжение
таблицы 8

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Тест-анализ и тест дизайн

latest update of the page: 17-01-2023, 21:53 UTC

Нажмите здесь, если видео не доступно

Как создать тестовый набор

Давайте создадим тестовый сценарий для сценария: Проверка функциональности входа

Шаг 1) Простой тестовый сценарий для сценария будет

Шаг 2) Чтобы выполнить тестовый пример, вам понадобятся тестовые данные. Добавляя это ниже

Идентификация тестовых данных может занимать много времени и иногда может потребовать создания тестовых данных заново. Причину этого нужно документировать.

Шаг 3) Чтобы выполнить тестовый пример, тестер должен выполнить определенный набор действий над AUT. Это задокументировано как ниже:

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

Шаг 4) Целью тестовых случаев является проверка поведения AUT на ожидаемый результат. Это должно быть задокументировано как ниже

Во время выполнения теста, тестер будет проверять ожидаемые результаты по сравнению с реальными результатами и назначать статус прохождения или сбоя

Шаг 5) Кроме того, в вашем тестовом случае может быть поле типа Pre-Condition, в котором указаны вещи, которые должны быть выполнены до запуска теста. Для нашего тестового примера предварительным условием было бы установить браузер для доступа к тестируемому сайту. Тестовый набор также может включать в себя постусловия, в которых указывается все, что применяется после его завершения. Для нашего тестового примера постусловием будет время и дата входа в систему, хранящиеся в базе данных.

Формат стандартных тестовых случаев

Ниже приведен формат стандартного логина Test case

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

При составлении контрольного примера, чтобы включить следующую информацию

• Описание того, что требование проверяется
• Объяснение того, как система будет тестироваться
• Настройка теста, такая как версия тестируемого приложения, программное обеспечение, файлы данных, операционная система, оборудование, доступ к безопасности, физическая или логическая дата, время дня, предварительные условия, такие как другие тесты, и любая другая информация о настройке, относящаяся к тестируемым требованиям.
• Входы и выходы или действия и ожидаемые результаты
• Любые доказательства или вложения
• Используйте активный язык кейсов
• Тестовый кейс не должен быть более 15 шагов
• Скрипт автоматизированного теста комментируется с входными данными, целью и ожидаемыми результатами
• Установка предлагает альтернативу предварительным тестам
• С другими тестами это должен быть неправильный порядок бизнес-сценария

Лучшая практика для написания хорошего примера теста.

1. Тестовые случаи должны быть простыми и прозрачными:

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

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

2. Создайте контрольный пример, помня конечного пользователя

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

3. Избегайте повторения тестовых случаев.

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

4. Не предполагайте

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

5. Обеспечить 100% охват

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

6. Тестовые случаи должны быть опознаваемыми.

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

7. Внедрить методы тестирования

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

• Анализ граничных значений (BVA). Как следует из названия, это метод, который определяет тестирование границ для указанного диапазона значений.
• Разделение эквивалентности (EP): этот метод разбивает диапазон на равные части / группы, которые имеют одинаковое поведение.
• Техника перехода между состояниями : этот метод используется, когда поведение программного обеспечения изменяется от одного состояния к другому после определенного действия.
• Техника угадывания ошибок: это угадывание / ожидание ошибки, которая может возникнуть при выполнении ручного тестирования. Это не формальный метод и использует опыт тестера с приложением

8. Самоочищающийся

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

9. Повторяемость и самостоятельность

Тестовый пример должен давать одинаковые результаты каждый раз, независимо от того, кто его тестирует

10. Рецензирование.

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

Инструменты управления тест-кейсами

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

1. Для документирования тестовых случаев: с помощью инструментов вы можете ускорить создание тестового набора с использованием шаблонов
2. Выполните контрольный пример и запишите результаты: контрольный пример можно выполнить с помощью инструментов, а полученные результаты легко записать.
3. Автоматизация отслеживания дефектов. Неудачные тесты автоматически связываются с системой отслеживания ошибок, которая, в свою очередь, может быть назначена разработчикам и отслеживаться посредством уведомлений по электронной почте.
4. Прослеживаемость: требования, тестовые случаи, выполнение тестовых случаев — все они связаны через инструменты, и каждый случай может быть прослежен друг к другу, чтобы проверить покрытие теста.
5. Защита тестовых случаев: тестовые случаи должны быть многоразовыми и должны быть защищены от потери или повреждения из-за плохого контроля версий. Инструменты управления тест-кейсами предлагают такие функции, как

• Соглашения об именах и нумерации
• Versioning
• Хранение только для чтения
• Контролируемый доступ
• Резервное копирование вне сайта

Популярные инструменты управления тестированием: Quality Center и JIRA

Ресурсы

• Обратите внимание, что используемый шаблон будет отличаться от проекта к проекту. Прочтите это руководство, чтобы изучить шаблон тестового примера с объяснением важных полей.

Загрузите приведенный выше шаблон тестового примера Excel (.xls)

What exactly is test coverage?

In software testing, test coverage is defined as a statistic that indicates the quantity of testing completed by a collection of tests. It will entail obtaining information about which sections of a program are executed when the test suite is performed in order to establish whether conditional statement branches have been taken.

It is a way for making sure that your tests are testing your code or how much of your code you exercised by running the test.

Code Coverage and Test Coverage

Code coverage and test coverage are frequently mistaken. Even while the basic concepts are the same, they are not the same.

• Code Coverage refers to unit testing procedures that must target all parts of the code at least once and are performed by developers.

• Test Coverage, on the other hand, entails testing every requirement at least once and is clearly the responsibility of the QA team.

What truly counts as a covered need is determined by each team’s perspective.

Some teams, for example, consider a requirement covered if it has at least one test case against it. It is occasionally covered if at least one team member is assigned to it. Alternatively, if all of the test cases connected with it are run.

If there are 10 requirements and 100 tests are written, we call this appropriate testing coverage at the design level if the 100 tests target all of the 10 criteria and do not leave any out.

When just 80 of the prepared tests are performed and only 6 of the requirements are targeted. Despite the fact that 80 percent of testing has been completed, we claim that four standards have not been met. This is coverage data at the execution level.

When only 90 tests related to 8 requirements have testers assigned to them and the remainder do not, we say the test assignment coverage is 80%. (8 out of 10 requirements).

It is also critical to know when to compute coverage.

If you do this too early in the process, you will see a lot of gaps since items are still missing. As a result, it is typically recommended to wait until the Last Build, often known as the Final Regression Build. This ensures that the Tests run for the supplied Requirements are correctly covered.

What is the purpose of Test Coverage?

• Identifying the region of a requirement that is not covered by a collection of test cases

• It aids in the creation of new test cases in order to enhance coverage.

• Developing a quantifiable metric of test coverage as an indirect technique of quality control

• Identifying useless test scenarios that do not contribute to increased coverage

How is Test Coverage Achievable?

• Test coverage may be achieved by the use of static review techniques such as peer reviews, inspections, and walkthroughs.

• By converting ad hoc flaws into executable test cases

• Test coverage may be done at the code or unit test level by using automated code coverage or unit test coverage technologies.

• Functional test coverage may be accomplished with the assistance of appropriate test management technologies.

Advantages of Test Coverage

• It can ensure the test’s quality.

• It can aid in determining whether parts of the code were actually modified for release or repair.

• It can aid in identifying untested pathways in your application.

• Prevent the spread of flaws.

• Time, scope, and cost may all be managed.

• Prevention of defects at an early point of the project’s lifetime

• It can determine all of the application’s decision points and pathways, allowing you to enhance test coverage.

• Gaps in requirements, test cases, and problems at the unit and code levels may be easily identified.

How should a good Test Coverage technique be implemented?

Everything revolves around awareness −

• First and foremost, the QA team must understand the scope of the project and the status of the design activities. They will be notified if further tests are introduced in this manner. You might utilize an RTM to do this, as is common practice.

• Second, look into the resource assignment and test execution procedures to ensure that everything is tested as quickly as feasible.

How can you ensure that everything has been tested?

• Every tester should be knowledgeable of the requirements as well as the testing procedures.

• Prioritize your needs and direct your efforts where it is most required.

• Be aware of how a particular release differs from prior ones so that you may more precisely identify important needs and focus on maximum positive coverage

• Modify Test Automation

• Use test management tools to ensure that you are constantly up to date.

• Assignment of intelligent work- Concentrate your finest personnel on important tasks and allow new testers to explore more from a different viewpoint.

• Keeping a checklist for all jobs and other activities

• Interact more with your Dev/Scrum/BA teams to have a better understanding of the application’s behavior.

• Maintain a record of all your build cycles and fixes.

• Be aware of how a particular release differs from prior ones so that you may more precisely identify important needs and focus on maximum positive coverage.

• Use test management tools to ensure that you are constantly up to date.

• Assignment of intelligent work- Concentrate your finest personnel on important tasks and allow new testers to explore more from a different viewpoint.

• Keeping a checklist for all jobs and other activities

• Interact more with your Dev/Scrum/BA teams to have a better understanding of the application’s behavior.

• Maintain a record of all your build cycles and fixes.

Areas and techniques for efficient testing that are critical

• Resource jumbling − Distribute duties among your team members. This improves engagement while preventing information focus.

• Compatibility coverage − Ensure that you are aware of and include the various browsers and systems while testing your application.

• Ownership − Hold testers accountable and give them complete autonomy (with monitoring and assistance, of course) over the module/task they are working on. This fosters responsibility and allows them to experiment with new approaches rather than sticking to the tried-and-true.

• Deadlines − Knowing the release deadlines before the testing process begins aids inefficient planning.

• Communication − Keep in touch with the development and other teams in between release cycles to stay up to date on what’s going on.

• Maintain an RTM − Serves as a good derivative to stakeholders or clients, allowing the release schedule to be confirmed.

Test Coverage Calculation Formula

To determine test coverage, follow the methods outlined below −

• Step 1 − The total number of lines of code in the program quality you are assessing.

• Step 2 −The total amount of lines of code that all test cases are presently executing.

You must now multiply (X divided by Y) by 100. This computation yields your test coverage percentage.

As an example −

If you have 500 lines of code in a system component and 50 lines run across all current test cases, your test coverage is −

10% = (50 / 500) * 100

Product coverage – Which parts of the product did you examine?

Yes, while measuring testing coverage in terms of product, the primary topic to focus on is — which sections of the product have you tested and which remain untested?

• Example #1 − If you’re testing a «knife,» don’t worry about whether or not it slices the vegetables/fruits properly. Other factors to consider are the user’s ability to handle it comfortably.

• Example #2 − Checking relevant features is a requirement if you are evaluating an application called «notepad.» Other considerations include: the application responding properly while using other applications at the same time, the application not crashing when the user tries to do something unusual, the user receiving proper warning/error messages, the user being able to understand and use the application easily, and the availability of help content when needed. You cannot say that the application’s testing coverage is comprehensive unless you investigate the aforementioned scenarios.

Risk Coverage – What risks have you checked for?

Another component of having comprehensive testing coverage is risk coverage. You cannot label a product or application as «tested» until you have also tested the related hazards. Coverage of related hazards is a critical component of total testing coverage.

• Example #1 − What would your reaction be if, when testing an airplane, a tester told you that he/she had completely examined the internal system of the airplane and that it was operating properly, but that only the flying capacity of the airplane had not been covered during testing? That is, after all, what risk coverage entails. Identifying risks specific to the application/product and properly testing it is always a smart approach.

• Example #2 − While testing an e-commerce site, the tester assessed every effective feature but failed to account for the potential of a huge number of consumers accessing the website at the same time, which proved to be a major error on Super OFFER day.

Coverage of requirements – What requirements have you tested for?

If a product or application is well-developed but does not meet the needs of the client, it is useless. Product coverage is just as essential as requirement coverage during testing.

• Example #1 − You requested the tailor to sew your dress and add those peacock blue display buttons on the neckline since you were excited about the family gathering. While stitching the garment, the tailor decided that putting those buttons on the neckline would be unappealing, so he embroidered a golden border instead. Certainly, on the trial day, the dissatisfied customer yelled at the tailor for not adhering to the specifications.

• Example #2 − While testing a chat application, the tester took care of all the important points, such as multiple users chatting in a group, two users chatting independently, all types of emoticons available, updates sent to the user immediately, and so on, but forgot to look at the requirement document, which clearly stated that when two users chat independently, the video call option should be enabled. The client advertised the chat program as allowing calling while two people talk independently. You can picture what would have happened to the chat application if this had occurred.

Cons

Because there are no tools to automate most of the activities in the test coverage manual. As a result, it requires a significant amount of time to assess the requirements and develop test cases.

Test coverage allows you to count features and then compare them to many tests. However, there is always room for blunders in judgment.

What exactly is test coverage?

In software testing, test coverage is defined as a statistic that indicates the quantity of testing completed by a collection of tests. It will entail obtaining information about which sections of a program are executed when the test suite is performed in order to establish whether conditional statement branches have been taken.

It is a way for making sure that your tests are testing your code or how much of your code you exercised by running the test.

Code Coverage and Test Coverage

Code coverage and test coverage are frequently mistaken. Even while the basic concepts are the same, they are not the same.

• Code Coverage refers to unit testing procedures that must target all parts of the code at least once and are performed by developers.

• Test Coverage, on the other hand, entails testing every requirement at least once and is clearly the responsibility of the QA team.

What truly counts as a covered need is determined by each team’s perspective.

Some teams, for example, consider a requirement covered if it has at least one test case against it. It is occasionally covered if at least one team member is assigned to it. Alternatively, if all of the test cases connected with it are run.

If there are 10 requirements and 100 tests are written, we call this appropriate testing coverage at the design level if the 100 tests target all of the 10 criteria and do not leave any out.

When just 80 of the prepared tests are performed and only 6 of the requirements are targeted. Despite the fact that 80 percent of testing has been completed, we claim that four standards have not been met. This is coverage data at the execution level.

When only 90 tests related to 8 requirements have testers assigned to them and the remainder do not, we say the test assignment coverage is 80%. (8 out of 10 requirements).

It is also critical to know when to compute coverage.

If you do this too early in the process, you will see a lot of gaps since items are still missing. As a result, it is typically recommended to wait until the Last Build, often known as the Final Regression Build. This ensures that the Tests run for the supplied Requirements are correctly covered.

What is the purpose of Test Coverage?

• Identifying the region of a requirement that is not covered by a collection of test cases

• It aids in the creation of new test cases in order to enhance coverage.

• Developing a quantifiable metric of test coverage as an indirect technique of quality control

• Identifying useless test scenarios that do not contribute to increased coverage

How is Test Coverage Achievable?

• Test coverage may be achieved by the use of static review techniques such as peer reviews, inspections, and walkthroughs.

• By converting ad hoc flaws into executable test cases

• Test coverage may be done at the code or unit test level by using automated code coverage or unit test coverage technologies.

• Functional test coverage may be accomplished with the assistance of appropriate test management technologies.

Advantages of Test Coverage

• It can ensure the test’s quality.

• It can aid in determining whether parts of the code were actually modified for release or repair.

• It can aid in identifying untested pathways in your application.

• Prevent the spread of flaws.

• Time, scope, and cost may all be managed.

• Prevention of defects at an early point of the project’s lifetime

• It can determine all of the application’s decision points and pathways, allowing you to enhance test coverage.

• Gaps in requirements, test cases, and problems at the unit and code levels may be easily identified.

How should a good Test Coverage technique be implemented?

Everything revolves around awareness −

• First and foremost, the QA team must understand the scope of the project and the status of the design activities. They will be notified if further tests are introduced in this manner. You might utilize an RTM to do this, as is common practice.

• Second, look into the resource assignment and test execution procedures to ensure that everything is tested as quickly as feasible.

How can you ensure that everything has been tested?

• Every tester should be knowledgeable of the requirements as well as the testing procedures.

• Prioritize your needs and direct your efforts where it is most required.

• Be aware of how a particular release differs from prior ones so that you may more precisely identify important needs and focus on maximum positive coverage

• Modify Test Automation

• Use test management tools to ensure that you are constantly up to date.

• Assignment of intelligent work- Concentrate your finest personnel on important tasks and allow new testers to explore more from a different viewpoint.

• Keeping a checklist for all jobs and other activities

• Interact more with your Dev/Scrum/BA teams to have a better understanding of the application’s behavior.

• Maintain a record of all your build cycles and fixes.

• Be aware of how a particular release differs from prior ones so that you may more precisely identify important needs and focus on maximum positive coverage.

• Use test management tools to ensure that you are constantly up to date.

• Assignment of intelligent work- Concentrate your finest personnel on important tasks and allow new testers to explore more from a different viewpoint.

• Keeping a checklist for all jobs and other activities

• Interact more with your Dev/Scrum/BA teams to have a better understanding of the application’s behavior.

• Maintain a record of all your build cycles and fixes.

Areas and techniques for efficient testing that are critical

• Resource jumbling − Distribute duties among your team members. This improves engagement while preventing information focus.

• Compatibility coverage − Ensure that you are aware of and include the various browsers and systems while testing your application.

• Ownership − Hold testers accountable and give them complete autonomy (with monitoring and assistance, of course) over the module/task they are working on. This fosters responsibility and allows them to experiment with new approaches rather than sticking to the tried-and-true.

• Deadlines − Knowing the release deadlines before the testing process begins aids inefficient planning.

• Communication − Keep in touch with the development and other teams in between release cycles to stay up to date on what’s going on.

• Maintain an RTM − Serves as a good derivative to stakeholders or clients, allowing the release schedule to be confirmed.

Test Coverage Calculation Formula

To determine test coverage, follow the methods outlined below −

• Step 1 − The total number of lines of code in the program quality you are assessing.

• Step 2 −The total amount of lines of code that all test cases are presently executing.

You must now multiply (X divided by Y) by 100. This computation yields your test coverage percentage.

As an example −

If you have 500 lines of code in a system component and 50 lines run across all current test cases, your test coverage is −

10% = (50 / 500) * 100

Product coverage – Which parts of the product did you examine?

Yes, while measuring testing coverage in terms of product, the primary topic to focus on is — which sections of the product have you tested and which remain untested?

• Example #1 − If you’re testing a «knife,» don’t worry about whether or not it slices the vegetables/fruits properly. Other factors to consider are the user’s ability to handle it comfortably.

• Example #2 − Checking relevant features is a requirement if you are evaluating an application called «notepad.» Other considerations include: the application responding properly while using other applications at the same time, the application not crashing when the user tries to do something unusual, the user receiving proper warning/error messages, the user being able to understand and use the application easily, and the availability of help content when needed. You cannot say that the application’s testing coverage is comprehensive unless you investigate the aforementioned scenarios.

Risk Coverage – What risks have you checked for?

Another component of having comprehensive testing coverage is risk coverage. You cannot label a product or application as «tested» until you have also tested the related hazards. Coverage of related hazards is a critical component of total testing coverage.

• Example #1 − What would your reaction be if, when testing an airplane, a tester told you that he/she had completely examined the internal system of the airplane and that it was operating properly, but that only the flying capacity of the airplane had not been covered during testing? That is, after all, what risk coverage entails. Identifying risks specific to the application/product and properly testing it is always a smart approach.

• Example #2 − While testing an e-commerce site, the tester assessed every effective feature but failed to account for the potential of a huge number of consumers accessing the website at the same time, which proved to be a major error on Super OFFER day.

Coverage of requirements – What requirements have you tested for?

If a product or application is well-developed but does not meet the needs of the client, it is useless. Product coverage is just as essential as requirement coverage during testing.

• Example #1 − You requested the tailor to sew your dress and add those peacock blue display buttons on the neckline since you were excited about the family gathering. While stitching the garment, the tailor decided that putting those buttons on the neckline would be unappealing, so he embroidered a golden border instead. Certainly, on the trial day, the dissatisfied customer yelled at the tailor for not adhering to the specifications.

• Example #2 − While testing a chat application, the tester took care of all the important points, such as multiple users chatting in a group, two users chatting independently, all types of emoticons available, updates sent to the user immediately, and so on, but forgot to look at the requirement document, which clearly stated that when two users chat independently, the video call option should be enabled. The client advertised the chat program as allowing calling while two people talk independently. You can picture what would have happened to the chat application if this had occurred.

Cons

Because there are no tools to automate most of the activities in the test coverage manual. As a result, it requires a significant amount of time to assess the requirements and develop test cases.

Test coverage allows you to count features and then compare them to many tests. However, there is always room for blunders in judgment.

Подборка по базе: ШАБЛОН ПАКЕТА СЕРВИСНОГО ДИЗАЙНА (SDP).docx, РП ОП.17 Пакеты прикладных программ для систем организационного , 4 44 сценарий, 4класс — копия.docx, Интегрированные пакеты MS Office.doc, Диагностический пакет дефектолога 5-11 лет.pdf, Практическое занятие №5. Формирование пакета документов организа, 2.1_9 Анализаторы сетевых пакетов.doc, 3 урок Файлы и пакеты.docx, Лекции Пакеты прикладных программ.docx

Лекционное занятие

Тема: Тестовый сценарий, тестовый пакет.

Цель: Ознакомиться с практическим применением техник тест дизайна при разработке тест кейсов. Анализом требований. Определением набора тестовых данных. Разработкой шаблона теста. Написанием тест кейсов на основании первоначальных требований, тестовых данных и шагов теста.

Оборудование: персональный компьютер, мультимедиа-проектор, MS Visio, Visual Studio, MS Office, методические рекомендации к проведению лекционных занятий, Гагарина, Л. Г. Технология разработки программного обеспечения: учеб. пособие / Л. Г. Гагарина, Е. В. Кокорева, Б. Д. Виснадул; Под ред. Л. Г. Гагариной. — М.: ФОРУМ: ИНФРА-М, 2017.-400 с., инструкционная карта для проведения лекционного занятия.
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

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

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

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

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

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

Тестовый пакет

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

Набор тестов – это контейнер с набором тестов, который помогает тестировщикам выполнять и сообщать о состоянии выполнения теста. Может принимать любое из трех состояний: «Активно», «Выполняется» и «Завершено».
Тестовый набор может быть добавлен в несколько наборов тестов и планов тестирования. После создания плана тестирования создаются наборы тестов, которые, в свою очередь, могут иметь любое количество тестов.
Как правило, модульные тесты и тестовые конфигурации разрабатываются самими разработчиками, основная задача тестера в этом случае — организовать все тесты в упорядоченную структуру пакетов и указать, какие пакеты должны исполняться в каких условиях. Вся иерархия тестов хранится в так называемом файле метаданных, имеющем расширение vsmdi. Этот файл находится в системе контроля версий и может быть включен в решение как отдельный элемент.
Процесс тестирования

Как отмечалось ранее, в тестировании выделяются три основных уровня, или три фазы:

1. Модульное тестирование.
2. Интеграционное тестирование.
3. Системное тестирование.

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

Фазы процесса тестирования

В процессе тестирования выделяют следующие фазы:

1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п.
2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы, поскольку наличие исполняемой версии разрабатываемой системы ( Implementation Under Testing (IUT) или Application Under Testing (AUT) – часто употребляемые обозначения для тестируемой системы) является одним из необходимых условий тестирования, что создает взаимозависимость в работе команд тестировщиков и разработчиков.
3. Разработка тестов, то есть тестового кода для тестируемой системы, если необходимо — кода системы автоматизации тестирования и тестовых процедур (выполняемых вручную).
4. Выполнение тестов: реализация тестовых циклов.
5. Анализ результатов.

После анализа результатов возможно повторение процесса тестирования, начиная с пунктов 3, 2 или даже 1.

Тестовый цикл

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

1. Проверка готовности системы и тестов к проведению тестового цикла включающая:
   • Проверку того, что все тесты, запланированные для исполнения на данном цикле, разработаны и помещены в систему версионного контроля.
   • Проверку того, что все подсистемы, запланированные для тестирования на данном цикле, разработаны и помещены в систему версионного контроля.
   • Проверку того, что разработана и задокументирована процедура определения и создания среза системы, или build.
   • Проверки некоторых дополнительных критериев.
2. Подготовка тестовой машины в соответствии с требованиями, определенными на этапе планирования (например, полная очистка и переустановка системного программного обеспечения). Конфигурация тестовой машины, так же, как и срез системы, должны быть однозначно воспроизводимыми.
3. Воспроизведение среза системы.
4. Прогон тестов в соответствии с задокументированными процедурами.
5. Сохранение тестовых протоколов (test log). Test log может содержать вывод системы в STDOUT, список результатов сравнения полученных при исполнении данных с эталонными или любые другие выходные данные тестов, с помощью которых можно проверить правильность работы системы.
6. Анализ протоколов тестирования и принятие решения о том прошел или не прошел каждый из тестов ( Pass/Fail ).
7. Анализ и документирование результатов цикла.

Последний перед выпуском продукта тестовый цикл не должен включать изменений кода build или кода продукта тестируемой системы. Этот цикл называется » финальным «. Таким образом обеспечивается ситуация, когда финальный цикл полностью повторяем, а выпускаемый продукт полностью совпадает с продуктом, который прошел тестирование. Финальный цикл необходим для гарантии достоверности результатов тестирования.
Что такое тестовый сценарий

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

Что такое тестирование сценария

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

Тестовые сценарии создаются по следующим причинам:

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

Когда не создать тестовый сценарий

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

Как тестер, вы можете выполнить следующие пять шагов для создания тестовых сценариев:

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

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

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.
Тестовый сценарий 2. Проверка функциональности поиска

Тестовый сценарий 3: проверьте страницу описания продукта

Сценарий тестирования 4: Проверьте функциональность платежей

Тестовый сценарий 5: проверка истории заказов

Помимо этих 5 сценариев, здесь приведен список всех других сценариев.

• Проверьте поведение домашней страницы для постоянных клиентов
• Проверьте категорию / страницы продукта
• Проверьте службу поддержки / контактные страницы
• Проверьте страницы ежедневных предложений

Пример 2: Тестовые сценарии для банковского сайта

Тестовый сценарий 1 : Проверьте функциональность входа и аутентификации

Тестовый сценарий 2 : Проверить перевод денег можно

Тестовый сценарий 3. Проверьте выписку со счета.

Тестовый сценарий 4 : Проверка фиксированного депозита / периодического депозита может быть создана

И так далее…
Литература: Гагарина, Л. Г. Технология разработки программного обеспечения: учеб. пособие / Л. Г. Гагарина, Е. В. Кокорева, Б. Д. Виснадул; Под ред. Л. Г. Гагариной. — М.: ФОРУМ: ИНФРА-М, 2017.-400 с.

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

ОСНОВНЫЕ ТЕРМИНЫ

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

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

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

3. выполнением тестирования (Test Execution)

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

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

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

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

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

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

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

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

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

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

Атрибуты дефекта

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

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

• Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

1. Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

2. Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

3. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.

4. Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

5. Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

6. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

7. Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

8. Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT).

9. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

10. Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.

ВИДЫ ТЕСТИРОВАНИЯ

Классификация по целям

• Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Классификация по позитивности сценария

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

• Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

• Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

• Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

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

Классификация по исполнителям тестирования

• Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.

• Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.

Классификация по уровню тестирования

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

• Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

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

• Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.

• Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.

Классификация по исполнению кода

• Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.

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

Классификация по хронологии выполнения

• Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

• Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.

• Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

• Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

• Недвусмысленность — требование должно содержать однозначные формулировки.

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

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

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

• Что нужно тестировать?

• Как будет проводиться тестирование?

• Когда будет проводиться тестирование?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий.

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

• Предусловия (PreConditions) используются, если предварительно систему нужно приводить к состоянию пригодному для проведения проверки; т.е. указываются либо действия, с помощью которых система оказывается в нужном состоянии, либо список условий, выполнение которых говорит о том, что система находится в нужном состоянии для основного теста.

• Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.

• Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.

• иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего для Test script), так и независимыми (Test suite).

Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется