Software Process

Based on the experience gained over the past few years in Software Testing have put down some points to be followed to have effective testing. This can be set as a process if there is no defined process.

1. Systematic Requirement Analysis.

•      Prioritize the requirements.
•      List the function requirements.
•      List the non-functional requirements.
•      Prepare a requirement traceability metrics.

2. Use Cases.

•      Identify the different users.
•      Create a user profile for each category of user, including all the relevant roles the user play.
•      Create a use case for each goal, following the use case template. Maintain the same level of  abstraction throughout the use case.
•      Review & validate the use cases. (*Review should be done by someone other than the author* )

3. Prototype.

•      Identify the basic requirements.
•      Develop initial prototype.
•      Review. (Get customer’s feedback)
•      Revise & enhance the prototype. (*Review should be done by someone other than the author* )

4. Test Plan.

•      All the testing activities should be mentioned in a test plan.
•      It should define what is to be tested & what is to be overlooked.
•      It should contain only the necessary information & nothing more.
•      Use the standard test plan template.
•      Review the test plan.
•      Revise & enhance the test plan. (*Review should be done by someone other than the author*) 

* All the reviews should be done formally. The documents of comments or feedback by the reviewer should be maintained always. Revision history chart should also be maintained, so that we can trace the change made.

5. Test Cases.

•      Good test cases should expose a maximum numbers of defects.
•      It should cover all the functionalities of an application.
•      A tool or a template can be used for time saving.
•      Review the test cases.
•      Revise & enhance the test cases. (*Review should be done by someone other than the author *)

6. Code Review.

•      Follow the coding standards.
•      Revise & enhance the code developed. (*Review should be done by someone other developer*)

 7. Informal Testing.

•      There can be an informal round of testing, before the module is released for actual testing.
•      This testing is also done by testers.
•      This should be an informal discussion between developers & testers.
•      This avoids more bugs to occur.    

8. Cycle 1 Testing. 

•      Don’t waste time in testing the wrong things. Test what matters.
•      Perform the dynamic testing in the test server.
•      Communicate the bugs or defects.
•      Try to get most of the bugs fixed in this version only.

9. Cycle 2 Testing.

•      Spend more time for testing in this phase.
•      Perform the dynamic testing in the online server.
•      Communicate the bugs.
•      Get all the found bugs fixed.
•      Review the process before internal release.   

10. Internal Release.

•      Internal releases builds up the confidence for quality.
•      Communicate the found bugs & get it fixed immediately.
•      Review the process before UAT.    

11.  User Acceptance Testing.

•      Get the feedback from the client.
•      Communicate the found bugs & get it fixed immediately.
•      Review the process before the release of the application.   

12. Release.

How to address the issue of changing requirements during Testing Phase?

I have noticed that a lot of times there are changes to the FRD/BRD even after planning phase. This really is not a very good approach if the FRD is updated and sent to the QA team. There would be a lot of rework in the Test Scenarios and Test Cases and a lot of time is involved in this process. This may seem fine as long these changes are taking place in the Planning phase but imagine if the requirements keep on changing.

During the execution phase then there are many chances that the requirements may not be fully tested and a lot of UAT defects may arise. To avoid all these there are some measures given below which have been successfully implemented and saw the result which resulted in the UAT defects being decreased.

1. The QA team needs to make sure that the FRD received is the final approved version from the Business/Development team.
2. Any cosmetic changes can be accommodated during the planning phase.
3. Any functional changes should come as Change Request and should be taken care by during planning phase.
4. It should be communicated to the business or Development team that the FRDs should not be just updated for functional changes if this is the process then it should be intimated to the QA team
5. During execution phase any type of changes should come as Change Request. These changes can be by business to enhance any requirements or because of the defects raised by the QA team some functionality needs to be changed. This should not be changed in the FRD and the defect should not be cancelled.
6. Instead all the changes should come as Change Request and QA should estimate the  effort for planning and execution and should be taken care after the execution phase. The process may defer from company to company.

Conclusion: Any type of changes in the requirements should not hamper the work of the QA but should come in the forms of CRs so that QA team can analyze and have additional time to test.