Test documentation

• Test plan

• Test case

• Test plan model

Test plan

• The point of a plan is to balance the scope and quality constraints against the time and resource
constraints while minimizing the risks.

• Test planning is, together with requirements analysis, the first and foremost activity that
happens in a testing project.

Test plan purpose

• Plan all the testing topics that will be used as the basis to design testing activities

• Define the policy of working with the other involved teams throughout the testing process

• Identify the testing risks and their severity in advance

• Hai sa vorbim putin despre scopul test planului:

• Planificam toate topicurile de testare ce vor fi folosite ca si baza pentru activitatile de test design

• Definim o serie de reguli in ceea ce priveste modul de lucru in echipe pe tot parcursul procesului
de testare

• Indentificam riskuri si gradul de impact al acestora.

The test plan is a dynamic document that should be updated during the testing process to reflect the
correct plan.

For example:

• new testing risk is identified

• the probability of a risk is changed

• the availability of specific interface is delayed

The Test Plan must address and answer 5 basic questions:

 1. What should be tested?

2. How should testing be carried out?

3. When should testing start and stop?

4. Who does the testing?

5. Where will the testing take place?

Test plan content:

Testing scope

• test scenarios/test objectives that will be validated

• functional tests

• non-functional tests

• external interfaces integration tests

• business processes

• Ce contine un Test Plan?

• In Scope - acest capitol trebuie sa se regaseasca in orice test plan

• In testing scope intra Scenariile de test; testele functionale si non functional; posibile integrari
cu alte interfete; o descriere a procesului de business;

Out of scope

• Enhanced clarity on what we are not going to cover

• Functions or features that are part of 3rd-party products

• For any reason based on the project management decisions

• Assumptions

- All the conditions that need to hold true for us to be able to proceed successfully

• Test schedule

- test scenarios and cases preparations

- test data and environment preparations

 - test execution and how many run cycles

- start and end dates for execution

• Roles and Responsibilities

- who is doing what

- responsible from each team is listed

• Deliverables

- what documents each test activity is going to produce

- should be identified according to the defined procedure and include who is responsible to deliver
them (within the testing team)

- test plan, traceability matrix, test scenarios & cases, execution status, defects status, summary
report

Rolurile din echipa si responsabilitatile fiecaruia. Ex cu release manager; PO/ Customer serivice
responsible

Deliverables - ce documente se vor a fi livrate la finalul procesului de testare.

• Environment

- kind of environment needed

- specify the number of environments needed and the main reasons for requesting this number of
environments

• Tools

- to be used during entire testing process

• Defect Management

- who are we going to report the defects to

- what is the tool and what is the defect lifecycle flow

• Risks Management

- list of risks, their impact and mitigation plan

 • Test Plan is a document that is the point of reference based on which testing is carried out
within the testing team.

• It is also a document we share with the Business Analysts, Project Managers, Dev team and the
other teams. It is documented by the Test manager/Test lead based on the inputs from the Test
team members.

• The test plan doesn’t include test cases, use cases or bug reports. It may include a link to where
these are found, but the documents are not written inside the test plan.

• TP este un document. Sa retinem asta. Este un document de referinta in baza caruia are loc
testarea. Toata echipa trebuie sa-l citeasca. Toata echipa trebuie sa fie deacord cu el.

• Acest test plan trebuie distribuit catre stakeholders aka project manageri, development team
a,i, ei sa vina cu o serie de completari.

• Este creat de ™ sau TL dar contribuie si membri din echipa,.

• Test Planning is typically allocated 1/3 of the time it takes for the entire QA engagement. The
other 1/3 is for Test Designing and rest is for Test Execution.

• Test plan is not static and is updated on demand basis.

• The more detailed and comprehensive the Test plan, the more successful the testing activity.

TEST CASE

• The test cases documentation is an important deliverable by the testing team and is shared to
BA, PM and other teams, when done, for their review and feedback.

• Work is divided among the testing team members and each member is going to be responsible
for creating test cases for a certain module/area or a part of a certain module/area.

What is a test case?

• It is a validation procedure that provides the test engineers with step by step instructions of how
to validate the requirement during test execution.

• The test case describes HOW the requirement is going to be validated.

• HOW means "Describe all the ways and data that is going to be used in order to validate system
behavior"

Test case structure

• Test case ID - generic one, unique identifier

 • Test case description – short description of the objective to be achieved

• Precondition - any prerequisites or preconditions that must be fulfilled prior to executing the
test

• Actions/Steps - activities to be performed in order to achieve a result

• Test Data - the explicit/specific data that are to be used while conducting the test (name,
emails, values)

• Expected results - what we are expecting to happen after performing the activities (what is the
requirement)

• Test Environment - the environment (Hardware/Software/Network) in which the test was

executed

• Created By - test case writer/author

• Date of Creation - the date of creation of the test case

• Executed By - the name of the person who executed the test

• Date of Execution - the date of execution of the test

• Status - Pass or Fail; other statuses can be ‘Not Executed’ if testing is not performed or ‘Blocked’
if testing is blocked or even ‘Not Relevant’ for specific situation

• Remarks - any comments on the test case or test execution

NOTES:

• write test cases in such way that you test only one thing at a time. Do not overlap or complicate
test cases. Attempt to make your test cases ‘atomic’

• for complex business logic need to involve one of the boundary values analysis, equivalence
partitioning or decision table techniques for writing optimal test cases

• it is very important to have reviews over test cases

• keep in mind that the test cases we create are not only the point of reference for the internal
testing phase, but they can be referred also to the acceptance phase

• be in 100% sync with your traceability matrix (where the matrix is your testing goal)

• ensure that all positive and negative scenarios are covered

• perform a spell and grammar check on each and every document you create
 • we (testers) are the quality representatives for IT projects – and it doesn’t reflect positively on
us if our deliverables themselves are of inferior quality.

• write in simple and easy to understand language.

• use active voice when writing test case: Do this, do that.

• use exact and consistent names (of forms, fields, etc).

GOOD TEST CASE:

• Accurate: Exacts the purpose

• Economical: No unnecessary steps or words, simple

• Traceable: Capable of being traced to requirements

• Repeatable: Can be used to perform the test over and over

• Reusable: Can be reused, if necessary