IST Clock

Friday, April 30, 2010

Basics Of Software Testing – 2

In my previous posts I discussed about the basic of software testing and bugs. Continuing the series, I would like to discuss about the software testing process followed in the industry. First we will talk about the software development life cycle , the SDLC. Be it any model followed in your organization all the models are based on the pioneer WATERFALL model which contains following general phases –
- Requirement Analysis,
- System design,
- System development / Coding ,
- Testing and
- Implementation & maintenance.

In brief , we analyze OR study the present system and get detail understating of the client’s requirements in context to the system to be built. Further we document these requirements in the form of SRS/FRS/Use Cases/Specification document. Moving to the next step we design the system on the basis of the requirement and we produce System Design Document(s). Based on the SDD, developers code the system. Once the system is build and released for testing , testers test the system against the documented requirements by executing test cases and adhering to a test plan. Once the system is ready for client release it enters into the last phase under which the system is implemented at the client site and then maintenance of the system can be done either by the same organization Or it can be outsourced to a different organization depending on the terms and condition in the initial contract.

Most important point to remember is that output of every phase in SDLC is a document. Even at the end of the last phase we prepare documents such as User Manuals and other related stuff. Now coming back to our main topic where does the testing process starts / fits in / comes into picture in the SDLC and the answer is just after the requirement phase. As soon as requirement phase is over and the SRS is freezes and is ready to use further then the activities progresses in two direction. One direction heads towards development and combines with next phase of SDLC. Another direction correlates to the fourth phase of SDLC , testing phase. Under this we first prepare the “Test Plan” . Test Plan is the bible of the whole testing activity to be carried out in the particular project. It contains various details but the most important which is / should be there in every test plan are –
- Brief description/introduction/overview of the system.
- Intended parties / reference documents
- Test items
- Features to be tested
- Features not to be tested
- Approach
- Item pass/fail criteria
- Suspension criteria and resumption requirements
- Test deliverables
- Testing tasks
- Environmental needs
- Responsibilities
- Staffing and training needs
- Schedule
- Risks and contingencies
- Approvals

Just a small note on who creates the test plan , it is the responsibility of senior member of testing team be it team lead/project lead. Once the test plan is freeze, testers are clear with the schedule, what is and how it is to be tested, approach to be followed and their individual responsibilities. Now the testing can proceed to the next step of designing test cases/scripts. Designing of test cases requires detailed knowledge of the system and thus test cases are designed on the basis of SRS/FRS/Requirement Specification. Best practice is to study the requirements , understands it and then come up with TEST SCENARIOS. A test scenarios is just a one line description of what are we testing. Now for testing this, you will perform some steps (Steps to be performed) which may / may not take some input data (Test Data) and has some result (Expected Result)

Thus, Test Case = Description + Steps + Test Data + Expected Result + Actual Result (Only at the time of execution) + some optional components like defect ID, severity, priority etc.. )

Once the test cases are created they are to reviewed by peers/BA’s/Senior members of the team. It’s a good practice to review the test cases as the creator of these test cases might miss some scenario, test cases may contain some language related mistakes. Further it’s good to have a TEST CASE CREATION CHECKLIST to reduce the review time. As per the recommended process review results should also be recorded in TEST CASE REVIEW RECORD (After all it helps in appraisals of testing team members J ). Once the test cases/scripts are freezes they are ready to execute on the build. When the developers releases the build for testing WE the testers execute the test cases and start fining the defects. Defects are then logged , fixed, resolved , closed and tracked carefully. In the test execution phase there are iteration cycles which depends on bug fixes, number of critical defects open/fixed. The decision to stop testing depends on many factors like –
- Testing budget of the project.
- Project deadline and test completion deadline.
- Critical test cases are successfully completed with no show stoppers OR even if some test cases fail does not have any show stoppers.
- Meeting the client requirements to certain point.
- Defect rates fall below certain specified level & High priority bugs are resolved.

Once the testing is over systems is released for customer usage.


END of POST , needless to say as always comments/suggestions are most welcome.

No comments:

Post a Comment