2.2 Разделы плана тестирования

Состав проекта и основные цели проекта
Требования, которые будут протестированы
Требования, которые не будут протестированы
Тестовая стратегия и подходы
Критерии
Ресурсы
Расписание
Роли и ответственности
Оценка рисков
Документация
Метрики

1. Состав проекта и основные цели проекта

Очень краткое описание цели разработки приложения. Этот раздел напоминает бизнес-требования, но информация подается в более сжатом виде с акцентами на наиболее важные задачи.

Project scope and main goals

Correct automated conversion of text documents in different source encodings to one destination encoding with performance significantly higher than human performance during the same actions.

2. Требования, которые будут протестированы

Список функциональных и/или нефункциональных требований, которые нужно протестировать. Здесь перечислены только те тредования, которые должны быть покрыты тест-кейсами.

Requirements to be tested

See referenced sections in “File Converter Requirements.docx”:

UR-1.*: smoke test.
UR-2.*: smoke test, critical path test.
UR-3.*: critical path test.
BR-1.*: smoke test, critical path test.
QA-2.*: smoke test, critical path test.
L-4: smoke test.
L-5: smoke test.
DS-*: smoke test, critical path test.

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

3. Требования, которые не будут протестированы

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

Requirements NOT to be tested

See referenced sections in “File Converter Requirements.docx”:

SC-1: the application is a console one by design.
SC-2, L-1, L-2: the application is developed with proper PHP version.
QA-1.1: this performance characteristic is at the bottom border of typical operations
performance for such applications.
L-3: no implementation required.
L-6: no implementation required.

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

4. Стратегия тестирования и подходы

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

Test strategy and approach

4.1. General approach

The application is to be configured once by an experienced specialist and later used by end users, for whom only one operation is available – placing the file into the input directory. Therefore, issues of usability, security, etc. not explored during testing.

4.2. Functional testing levels

Smoke test: automated with batch files under Windows and Linux.
Critical path test: executed manually.
Extended test: not executed as the probability of defects detection on this level is
negligibly small.

Due to the team cross-functionality, a significant contribution to quality improvement can be expected from the code review combined with manual testing using the white box method. Unit-testing will not be applied due to extreme time limitations.

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

5. Критерии

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

Обычно критерий имеет ссылку на метрику, к которой он привязан.

Criteria

Acceptance criteria: 100% success of test cases on smoke test level and 90% success of test cases on critical path test level (see “Test cases success percentage” metric) if 100% of critical and major bugs are fixed (see “Overall defects fixed percentage” metric). Final requirements coverage by tests (see “Requirements coverage by tests” metric) should be at least 80%.
Testing start criteria: new build.
Testing pause criteria: critical path test must begin only after 100% success of testcases on the smoke test (see “Test cases success percentage”); test process may be paused is with at least 25% test-cases executed there is at least 50% failure rate (see “Stop-factor” metric).
Testing resumption criteria: more than 50% of bugs found during the previous iteration are fixed (see “Ongoing defects fixed percentage” metric).
Testing finish criteria: more than 80% planned for the current iteration test cases are executed (see “Test-cases execution percentage”).

6. Ресурсы

Список ресурсов необходимых для успешного тестирования:

программное обеспечение
оборудование
люди
время
деньги (обычно такая информацию конфиденциальна, поэтому просто прикладывается ссылка на бюджет)

Resources

Software: four virtual machines (two with Windows 10 Ent x64, two with Linux Ubuntu 18 LTS x64), two PHP Storm licenses (latest version available).
Hardware: two standard workstations (8GB RAM, i7 3GHz).
Personnel:
- One senior developer with testing experience (100% workload during all
  project time). Roles: team lead, senior developer.
- One tester with PHP knowledge (100% workload during all project time). Role: tester.
Time: one workweek (40 work hours).
Finances: according to the approved budget.

7. Расписание

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

Расписание не обязательно должно быть подробным, оно может корректироваться.

Schedule

25.05 – requirements testing and finalizing.
26.05 – test-cases and scripts for automated testing creation.
27.05-28.05 – main testing stage (test-cases execution, defect reports creation).
29.05 – testing finalization, reporting.

8. Роли и ответственность

Список основных сотрудников на проекте тестирования и их ключевые обязанности.

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

Roles and responsibilities

Senior developer: participation in requirements testing and code review.
Tester: documentation creation, test-cases execution, participation in code-review.

В примере выше старший разработчик помогает тестировать требования, так как проект состоит всего из 2-х человек.

9. Оценка рисков

Список рисков, которые могут возникнуть в процессе тестирования. Для каждого риска приводится оценка вероятности и несколько вариантов выхода из ситуации.

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

Risk evaluation

Personnel (low probability): if any team member is inaccessible, we can contact the representatives of the “Cataloger” project to get a temporary replacement (the commitment from the “Cataloger” PM John Smith was received).
Time (high probability): the customer has indicated a deadline of 01.06, therefore time is a critical resource. It is recommended to do our best to complete the project by 28.05 so that one day (29.05) remains available for any unexpected issues.
Other risks: no other specific risks have been identified.

10. Документация

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

Эти документы чаще всего интересны заказчику и команде. Особенно новичкам. Прежде чем приступать к работе нужно ознакомиться с документами и понять суть проекта.

Documentation

Requirements. Responsible person – tester, deadline – 25.05.
Test cases and defect reports. Responsible – tester, creation period – 26.05-28.05.
Test result report. Responsible person – tester, deadline – 29.05.

11. Метрики

Список числовых характеристик качества, какие-то методы оценки качества, формулы и тд.

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

Metrics

Test cases success percentage.
Overall defects fixed percentage.
Ongoing defects fixed percentage.
Stop-factor.
Test-cases execution percentage.
Requirements coverage by tests.

Пример плана тестирования

Test-Plan-Sample.pdf