Software Testing Life Cycle – Test Planning – Manual Testing

 

Software Testing Life Cycle – Test Planning – Manual Testing

 

II. Test Planning:

a) Team level changes if needed:

In Test planning, SM job can start with team level changes w.r.t complexity in current sprint or software.

Example:

Types of Software or Sprint	Developers  :  Testers
Commercial software like client/server and websites ( Banking, Insurance, E-commerce, healthcare, Logistics, Finance.)	3:1
Network based and embedded software (Hardware related software).	1:1
Artificial Intelligence software and expert systems ( Satellites, Robotics, Aeronautical, Typical games , Health equipments software etc..).	1:7

 

b) Identifying Risks:

After completion of team level changes, SM can concentrate on risks Identifications.

Example:

1. Lack of Time.
2. Lack of Resources.
3. Lack of Documentation.
4. Lack of Skills.
5. Sudden changes in requirements.
6. Delays in delivery ( Unexpected problems).
7. Lack of Seriousness to developers.
8. Lack of Communication.

 

c) Prepare Test Plan:

After completion team level changes and risks identification corresponding scrum masters can follow IEEE 829 Standard format to prepare test plan like shown below.

1. Test Plan Document ID:

Unique number or Name as Title.

2. Introduction:

About client and current sprint or software.

(What to test?)

3. Features:

Names of all modules in current sprint or software.

4. Features to be tested:

Names of modules to be tested.

5. Features not to be tested:

Names of modules not to be tested ( Those modules are already tested in previous sprint).

(How to test?)

6. Approach:

Paste of strategy given by PO.

7. Test Environment:

Required hardware and software for testers in current sprint or software testing.

8. Test Deliverables:

Documents to be prepared by testers.

Example:

Test scenarios, test cases, test data, test scripts, defect reports and test logs.

9. Entry criteria ( To start test execution):

-> Sprint / software is build to ready to release by developers for testing.

->  Test Environment established.

->  Test scenarios, test cases and test data was ready.

 

10. Suspension criteria ( to interrupt testing):

->  Critical / Show stopper bug came.

->  Test environment doomed.

->  More minor bugs in pending ( Quality gap).

 

11. Exit Criteria ( To stop testing):

-> Time exceeded.

->  All major bugs closed.

->  All modules or features are tested.

 

(Who to Test?)

12. Staff:

Names of  testers in ST.

13. Responsibilities:

Work allocation to testers in any one of two ways, such as modules wise allocation and topics wise allocation.

Example:

Modules wise allocation:

Topics wise allocation:

(When to test?)

14. Schedule:

Dates and time for testers.

15. Risks and assumptions:

Previously analyzed risks and solutions to overcome those risks.

16. Approvals:

Signatures of PO and SH.

Note 1:

The above IEEE 829 test plan format will be followed by scrum master in MS word or Open office word.

Note 2:

Test strategy is a part of test plan but strategy will be prepared by PO and plan will be prepared by SM.

Note 3:

IEEE 829 standards test plan document is classified into four parts such as :

1. What to test?
2. How to test?
3. Who to test?
4. When to test?

 

d) Review test plan:

Scrum master can take approval on test plan document from PO and SH. And then SM can take feedback on test plan from testers to change plan if needed.

 

In this article we have seen Software Testing Life Cycle – Test Planning – Manual Testing. In the next article will see Test Design.