Pg 2
CBO_Testplan Revision History
Version
Author
Reviewed By
Approved By
Comments
Approval Date
1 .. … manager Name of Version 1.0 is developed dd/mm/yyyy
1.1 .. .. " "
Version 1.1 is developed. XYZ
feature is added dd/mm/yyyy
… … … … … … … … TABLE OF CONTENTS 1 Objective pg 1 2 Scope pg 2 3 Approach pg 3 .. … … …
124 | P a g e Pg 3 – Pg 19
Pg 20
In the 1st page – we initially fill in only version(write as Draft 1.0), author, comments and reviewed by. Later on when the manager approves it, we fill in the Approved by and approval date and also remove (Draft) written in version column.
Generally Test Engineers only review it and the test plan is approved by Test Manager.
When new features come, we modify the Test Plan. Change the version and whichever features need to be changed. Again it is reviewed, updated and approved by manager. Test Plan must be updated whenever changes happen.
References (Pg 20) contains all the documents that are used to write the test plan document. Who writes Test Plan ?
Test Lead – 60%
Test Manager – 20%
Test Engineer – 20%
Thus, we can see from above – in 60% of projects, Test plan is written by Test Lead and so on as shown above.
Who reviews Test Plan ?
Test Engineer Test Lead Test Manager Customer Development team …. …. … ….
…. Entire Test Plan document
…. …. …. …. …. REFERENCES 1) CRS 2) SRS 3) FS 4) Design document … … …
125 | P a g e Test Engineer looks at the Test plan from his module point of view.
Test Manager looks at the Test plan from the customer point of view. Who approves Test Plan ?
Test Manager
Customer
Who writes Test Cases ?
Test Engineer
Test Lead
Who reviews Test Cases ?
Test Lead
Test Engineer
Development Team
Customer
Who approves Test Cases ?
Test Lead
Test Manager
Customer
TRACEABILITY MATRIX
We have learnt about TM earlier. Once the missing requirements are identified – we write the test cases for the requirements which we have missed – review it and get it approved – and then store the test cases in the repository and then fill in the name of the test case for which the requirements have been missed.
Traceability Matrix is a document which has got the mapping between requirements and test cases. We write TM to make sure that every requirement has got atleast 1 test case.
REQUIREMNTS … … …. …. …. …. …
126 | P a g e Serial
No. Module Name Requirements High Level Requirement Detailed Test Case Name
Automation Script Name 1 LOANS 1.1 Personal Loans 1.1.1 … CBO_PL_Approval 1.1.2 … CBO_PL_Elgibility check 1.2 Home Loans 1.2.1 … 1.2.2 … 2 TRANSFER AMOUNT
2.1 FAN text field
2.1.1 Should accept
only 10 digit integer … 2.1.2 Should accept
only those numbers which are created
by manager
..
2.2 TAN text field
2.2.1 Should accept
only 10 digit integer … 2.2.2 Should accept
only those numbers
created by manager
2.3 Amount Text field
2.3.1 Should accept only 100 - 5000, positive integer
…
2.3.2 Should not accept more than
balance
… … …
In the above TM – we have written the above TM looking at the requirements. For every requirement, we write the test case name(given in the header of the test case) and thus we know that we have written a test case for that particular requirement. Now, we block the cells for which we have not written test cases. Thus we have missed out on these requirements.
We block it in red. For whichever requirement we have not written test case – we read the requirements – write test cases – review it and get it approved – store it in repository – then go fill in the test case name for whichever requirements we have missed. Thus, in this way for every requirements we have atleast 1 test case.
Look at the figure in the next page,
Thus now all the blocked cells have been removed and test cases have been written for the missing requirements.
127 | P a g e Serial
No. Module Name Requirements High Level Requirement Detailed Test Case Name
Automation Script Name 1 LOANS 1.1 Personal Loans 1.1.1 … CBO_PL_Approval 1.1.2 … CBO_PL_Elgibility check 1.2 Home Loans 1.2.1 … … 1.2.2 … … 2 AMOUNT TRANSFER
2.1 FAN text field
2.1.1 Should accept
only 10 digit integer … 2.1.2 Should accept
only those numbers which are created
by manager
…
2.2 TAN text field
2.2.1 Should accept
only 10 digit integer … 2.2.2 Should accept
only those numbers created by manager
…
2.3 Amount Text field
2.3.1 Should accept only 100 - 5000, positive integer
…
2.3.2 Should not accept more than
balance
…
… … …
But 100% coverage is not assured in Traceability matrix. For ex, a requirement may have about 10 scenarios, but we have covered only 3 scenarios. Thus, TM will not promise you that we have 100% coverage. Instead it ensures that every requirement has atleast 1 test case which in turn gives the confidence that we are touching all the features atleast once.
In the above table, we have a column named automation script name. If we are automating any test case, we fill in the automation script name (which is same as manual test case name) and which we are not converting, we write it as manual. Thus, we can know which test case is automated and manual. We write this because we cant check every test case to see if it is manual or automated. This is shown in the table given below,
128 | P a g e Serial
No. Module Name Requirements High Level Requirement Detailed Test Case Name Automation Script Name
1 LOANS
1.1 Personal Loans
1.1.1 … CBO_PL_Approval CBO_PL_Approval 1.1.2 … CBO_PL_Elgibility check CBO_PL_Elgibility check
1.2 Home Loans 1.2.1 … … ..
1.2.2 … … …
2 TRANSFER AMOUNT
2.1 FAN text field
2.1.1 Should accept only 10
digit integer
… Manual
2.1.2 Should accept only those
numbers which are created by
manager
… Manual
2.2 TAN text field
2.2.1 Should accept only 10
digit integer … …
2.2.2 Should accept only those numbers created by manager … … 2.3 Amount Text field 2.3.1 Should accept only 100 - 5000, positive integer … … 2.3.2 Should not accept more than
balance
… Manual
… … …
TM gives traceability from high level requirements to automation script name. Advantages of Traceability Matrix
Ensures that every requirement has atleast 1 test case
If suddenly requirement is changed – we will be knowing which is the exact test case or automation script to be modified
We will come to know which test case should be executed manually and which are to be done automatically.
Who writes Traceability Matrix?
Test Lead gives an empty template and Test Engineer fills it up for his respective modules. Each Test Engineer fills it up for their modules. For ex, TE concerned with Loans feature will fill in the details(test case names) for Loans feature. Similarly other TE(s) do for their features.
129 | P a g e What is Test Strategy?
It is a document which captures the approach on how we go about testing the product. The approach can be from ,
a) resource point of view b) automation or not ..
..
Like this from many points of view, we capture the approach.
After Test Strategy, only then we start writing the detailed Test Plan and continue further. The Test Strategy is reviewed by development team and after changes are made, it is approved.