To watch in YouTube , click here : Test Plan in Software Testing
Test Plan is a detailed document about the testing process to be carried out. It includes the detail information about estimation , activities, resources and schedule etc. The various information included in a test plan are discussed below. Test Plan is prepared by Test Lead or Test Manager or Testers.
Types of Test plan :
1. Master Test Plan -- This is a top level test plan document for the testing process. Other individual test plans(supporting test plans) are part of this major test plan.
2. Supporting Test Plan -- To carry out complete software testing, the process goes through different level or types of testing such as Unit Testing , Integration Testing, Regression Testing, User Acceptance Testing etc. Supporting test plans are created for these individual testing processes. These test plans are part of the Master Test Plan.
1. Master Test Plan -- This is a top level test plan document for the testing process. Other individual test plans(supporting test plans) are part of this major test plan.
2. Supporting Test Plan -- To carry out complete software testing, the process goes through different level or types of testing such as Unit Testing , Integration Testing, Regression Testing, User Acceptance Testing etc. Supporting test plans are created for these individual testing processes. These test plans are part of the Master Test Plan.
A Test Plan includes below information:
1. Objectives
2. Approach
3. Resources
4. Software
5. Hardware
6. Environments
7. Test Schedule
8. Deliverables
9. Responsibilities
10. Features to be tested
11. Features not to be tested
12. Entry and Exit criteria
13. Risks and contingencies
14. Pass Fail criteria
15. Estimation of time / cost
16. Assumptions and Dependencies
17. Approval Criteria
Objectives:
This talks about the objectives , the goal of the testing.
Approach:
It defines the testing steps, methods, types, testing process or techniques.
Resources:
This talks about the resources required in terms of technical skills, number of resources , team structure, size etc.
Software:
This talks about the software or application , database , web services, network configurations , operating systems etc required for testing.
Hardware:
This talks about the required hardware , machines , Virtual machines etc.
Environments:
This talks about the number of testing environments required for the testing. Because we might require more than one testing environments based on functionalities purposes and properties.
Test Schedule:
This talks about the test schedule, how much time we have, when we will start and complete the testing.
Deliverables:
These are test documents or reports or other testing artifacts which testing team gives to the stakeholders. The artifacts are given before the testing , during the testing and after the testing.
Responsibilities:
It defines the roles and responsibilities of the team members.
Features to be Tested:
It is the scope of testing. It defines the list of the features, of the software or the product, which are in scope. They will be be tested.
Features not to be Tested;
This also talks about the scope of the testing. It defines the list of features of the software or product which are out of scope of the testing. They will not be tested.
Entry and Exit Criteria:
Entry Criteria defines the conditions or requirements to be fulfilled before starting the testing. Such as availability of all software , access , test data, test environment being up and running etc.
Exit Criteria defines the conditions or requirements to be fulfilled before declaring the test as completed. Such as deadlines, coverage of requirements and functionalities , no defects left etc.
Risks and contingencies:
Every project is associated with some risks, you should be ready for possible risks and should have proper solution plan for them. The common risks are: lack of resources, lack of software or hardware , lack of skill , late delivery of the code, change in the requirement, risk of budge/cost or time etc.
When the risk takes place, then you should come up with the appropriate solution. Some common actions for the risks are : shifting the delivery date(this is not recommended though) , changing(usually reducing the functionalities for testing ) the scope of testing, adding resources etc. For the kind of risk, if appears, whichever step is most appropriate , that step will be taken.
Pass Fail criteria:
It is a minimum standard or criteria for completing the test. To mark the test as PASSED, the criteria should be fulfilled. Such as , the product should be defect free or sometimes it will be acceptable with minor defects. This does not talk about individual test result, it talks about the testing of the overall product or software under test.
Estimation of time / cost:
Time : It talks about the time required to complete the testing , in other word, the deadline to complete testing.
Cost : It is the budget for the testing.
Assumptions and Dependencies:
It is part of risk management. The risks are future unexpected events which might occur. So, you make proper assumptions based on your experience and information.
The testing activities might be dependent to each other and other factors. You have to prioritize and carryout the testing activities accordingly.
Approval Criteria:
You will need approval of the test plan and other deliverables at different stages of testing(before testing, during testing, after completing the testing). The client or stakeholders can approve the test plan or the deliverables. You take the approvers' name , role, signature and approval date.
1. Objectives
2. Approach
3. Resources
4. Software
5. Hardware
6. Environments
7. Test Schedule
8. Deliverables
9. Responsibilities
10. Features to be tested
11. Features not to be tested
12. Entry and Exit criteria
13. Risks and contingencies
14. Pass Fail criteria
15. Estimation of time / cost
16. Assumptions and Dependencies
17. Approval Criteria
Objectives:
This talks about the objectives , the goal of the testing.
Approach:
It defines the testing steps, methods, types, testing process or techniques.
Resources:
This talks about the resources required in terms of technical skills, number of resources , team structure, size etc.
Software:
This talks about the software or application , database , web services, network configurations , operating systems etc required for testing.
Hardware:
This talks about the required hardware , machines , Virtual machines etc.
Environments:
This talks about the number of testing environments required for the testing. Because we might require more than one testing environments based on functionalities purposes and properties.
Test Schedule:
This talks about the test schedule, how much time we have, when we will start and complete the testing.
Deliverables:
These are test documents or reports or other testing artifacts which testing team gives to the stakeholders. The artifacts are given before the testing , during the testing and after the testing.
Responsibilities:
It defines the roles and responsibilities of the team members.
Features to be Tested:
It is the scope of testing. It defines the list of the features, of the software or the product, which are in scope. They will be be tested.
Features not to be Tested;
This also talks about the scope of the testing. It defines the list of features of the software or product which are out of scope of the testing. They will not be tested.
Entry and Exit Criteria:
Entry Criteria defines the conditions or requirements to be fulfilled before starting the testing. Such as availability of all software , access , test data, test environment being up and running etc.
Exit Criteria defines the conditions or requirements to be fulfilled before declaring the test as completed. Such as deadlines, coverage of requirements and functionalities , no defects left etc.
Risks and contingencies:
Every project is associated with some risks, you should be ready for possible risks and should have proper solution plan for them. The common risks are: lack of resources, lack of software or hardware , lack of skill , late delivery of the code, change in the requirement, risk of budge/cost or time etc.
When the risk takes place, then you should come up with the appropriate solution. Some common actions for the risks are : shifting the delivery date(this is not recommended though) , changing(usually reducing the functionalities for testing ) the scope of testing, adding resources etc. For the kind of risk, if appears, whichever step is most appropriate , that step will be taken.
Pass Fail criteria:
It is a minimum standard or criteria for completing the test. To mark the test as PASSED, the criteria should be fulfilled. Such as , the product should be defect free or sometimes it will be acceptable with minor defects. This does not talk about individual test result, it talks about the testing of the overall product or software under test.
Estimation of time / cost:
Time : It talks about the time required to complete the testing , in other word, the deadline to complete testing.
Cost : It is the budget for the testing.
Assumptions and Dependencies:
It is part of risk management. The risks are future unexpected events which might occur. So, you make proper assumptions based on your experience and information.
The testing activities might be dependent to each other and other factors. You have to prioritize and carryout the testing activities accordingly.
Approval Criteria:
You will need approval of the test plan and other deliverables at different stages of testing(before testing, during testing, after completing the testing). The client or stakeholders can approve the test plan or the deliverables. You take the approvers' name , role, signature and approval date.
Test case:
A test case is a set of steps to carry out a specific
scenario or case or condition. A test case mainly has test case ID, Description about the Test case, Test steps , Expected result, Actual result, Testing status. Depending upon a tester , a test case can be
long or short, and Test case number also varies. If you include more functionalities in a single Test case then the Test case will have more steps and the number of test cases will be few. If you write separate test cases for each functionality , then each test case will have few steps and the number of test cases will be many. So it depends upon the tester how he wants to write test case. In what ever way you write the test case , the requirement (or functionalities to be tested) should be fully covered. If the test case is dependent on other test
case or something else, then that condition should be mentioned as "Pre Condition" in the test case.
A test case is considered pass when all the steps in it pass. If any step or steps fail then the test case is
considered as fail. If the test case fails, then we need to log/create defect for the failure and the defect can be
associated/linked with the test case. The status of a test case can be PASS,
FAIL, ON HOLD, BLOCKED, UNTESTED etc.
Sample Test case format:
Depending upon the project type and project needs , the format might be slightly different. However, below format includes the most common test case components. As per your project need, the admin of your test management tool , will add or remove the fields or customize them .
Requirement Traceability Matrix:
It is a job of a tester to acquire the business
requirements( or design document or FDD or mapping document or user stories) . After getting the
business requirement document , a tester needs to convert the requirement to test cases
which is later tested whenever the code/software is ready for testing. While
converting the requirements to test cases, we need to make sure that everything in the
requirements have been covered. To make sure that all the requirements have
been covered , a matrix is created for the requirements vs test cases. This gives clarity that all the requirements
have been covered ( which will be tested ). This matrix is called Requirement Traceability Matrix or RTM . If
any piece of requirement is not covered , it becomes easily visible in the RTM.
No comments:
Post a Comment