Testing Web Application Part-3

4.5. Test Execution and Defect Tracking: This phase begins with the execution of Test Design described in previous phase of STLC. This includes:

1. Execution of test cases manually.

2. Execution of automation script.

3. Update the test case status(pass/fail) after comparing the expected result with actual result.

4. Defect Reporting and Tracking.

5. Re-testing of defects fixes

6. Regression testing of modules.

7. Perform Sanity Testing on current build.

During this phase, we comply to the guideline that is set for us. Here

1. Execute the test cases which are meant for test to pass first.

2. Execute the test cases priority wise.

3. Execute the test case group wise which are interrelated.

4. Execute the test cases which are written to break the functionality.

Once we go through the test case execution process, there might be the case that some test cases will fail and some will pass. Now, it is of utmost important to track those fail test cases. This situation invokes the need of some defect management tools to track those fail test cases (bugs). To meet this need, we use defect tracking tools like Bugzilla, Mantis, Jira etc as per availability.

Now, you might think what happens once a bug is found. Well, once a bug is found in the system, it takes it own life cycle. A bugs goes through many stages before it get fixed. Here, we are trying to elaborate the Bug Life Cycle a bug goes through. We are depicting the Big Life Cycle with the following diagram:

Now, we are going to explore different stages of the Bug from it’s inception to closer. The life of bug starts from when it is logged and ends when it is fixed by developer, and verified & closed by Software Tester. Following are the status associated with a bug:

1- New:When a bug is found/discovered for the first time, we, the tester communicates it to Team Lead in order to confirm if that is a valid bug. After getting confirmation from the Test/Team Lead, we log the bug in defect tracker and status of the bug become ‘New’.

2- Assigned: Once a bugs is reported as “New” developers review it. If it is a valid bugs developers or team lead assigned the bug to appropriate person to fix it and the status of bug get changed to “Assigned”.

3- Resolved: Once a bug is assigned to developer, he/she make some changes in code and fix it, the state of bug becomes “Resolved”. Developers change the state to Resolved in bug tracker. In this Resolved state the bug might take various possible Resolutions which are listed below:

• Rejected: the bug is invalid as per the explanation from the development, he/she rejects the bug and marks its status as ‘Rejected’.

• Unable to reproduce: If developers can not produce the bug at their end the he/she can assign “Unable to reproduce” state to bug.

• Won't fix: Sometimes it may happens that improvement can not be fixed. In this state bug is said “Won't fix”.

• Deferred: If developers thinks that this bugs is not so important to fix and can be avoided then he/she can change the state of bug to “Deferred”. It means that the

bugs will be taken care of at later release.

• Duplicate: It may happens that the same bug is filed again, then this bug can be resolved with the resolution “Duplicate”.

4- Closed: Once the bug state gets changed to Resolved, tester verified this bug to make sure that it is fixed actually. If the bug found resolved then tester close the bugs and the state becomes “Closed”.

5- Reopened: If after retesting the software for the bug opened, if the system behaves in the same way or same bug arises once again, then the tester reopens the bug and again sends it back to the developer marking its status as “Reopened”.

Many times we have encountered such a situation where developer is unable to reproduce a bug. This situation might lead to conflict between testers and developers. In this case, tester need to keep their head cool and communicate the bug effectively so that developer can understand the bug easily. We need to improve our skills in order to reproduce such issues. The following tips might work wonder in this confrontation:

• Try to capture the story around the issue and not just steps.
• Capture the complete Test Environment
• Capture all the available Test Execution Results. This includes your test data, screen shots, applications logs, system logs, server logs
• Need more patience (they won’t occur easily)
• Need more observation skills on the application behavior under test.
• Narrate the story around the issue to the stake holders and to corner the issue.

Type of testing we perform in this phases are:

• Functional Testing: We carry out this type of testing to ensure that the functionality of any feature is working as expected. This may go to integration and system testing.

• User Interface Testing: This type of testing we done to ensure that the objects like buttons, text fields, check box, its color, font and image are placed on the interface as according to the specifications.

• Cross Browser Testing: This is big a challenge for tester to run and test the application on different browser as you never know what browser is going to be used by users. We test the application to ensure it's working on different browser like Mozilla Firefox, IE-6 and 7, Safari, Netscape etc. This also ascertain the UI issues existence in the application.

• Usability Testing: This type testing is carried out for ‘user-friendliness’. This is a subjective matter and we will depend on the targeted end-user or customer's perception. At times we think as users of the application and advise some improvement on from user's prospective.

4.6. Test Report and Acceptance: This is the phase in which we, the tester, prepare test reports. The test report is the primary work deliverable from the testing phase. It passes around the information from the test execution phase that is needed for project managers, as well as the clients, to make further decisions. This reports is the summery of the test performed and the their results. The test report includes:

• Details of test cases(or test script) executed.
• Name of the software tester.
• The location of all test logs.
• Summaries of the results of each test non-conformity
• Summaries of the results of each test failure.
• The details of any code changes made during testing and the location of the modified source code.
• Recommendations of any action to be taken as a result of the acceptance tests, where applicable.
• Suggestion to the scope of improvement

Apart from that, one more important aspect is defects analysis. This is where we report defect information such as the number of defects found, defect severity classification, defect density, etc. We use Test Metrics to complement this section. Below are list of available metrics that can be used:

• Test defect by test phase -- Analyze test defects by test phase
• Test defect by severity level -- Analyze test defects by severity level
• Accepted vs. rejected test defects
• Defect density -- The number of defects per test cases

In general, writing the test report is important to make sure readers can make correct conclusions based on it. The output of this report will mold your readers' perception of you. The better your report, the better your reputation as tester.

Once we are done with Test Report, the User Acceptance Testing has taken place. It is the process that a client uses to verify that the delivered and installed product is ready to be put into production use. From the user's point of view, this means that every user oriented function should be thoroughly exercised. In this process what we will need to hand over to the team that will test your product is:

• User's Manual or Guide.
• An Installation Guide that tells the testing team how to install your product/application and who to contact in the event of problems.
• A link to your Project Plan which should describe the user requirements that our team committed to at the beginning of the project.

5. Conclusion: As the software testing is never ending process and its an art, obviously, we can not limit ourself to a defined process. There are lots of scope to venture and explore this field and software testing is becoming more challenging. We have written this document to share our knowledge that we have gain from experience and how we overcome the challenges we faced while testing. One thing is for sure that it is the tester who makes the life of user/customer easier. To become a good tester, one should have good understanding and listening power with an eye which can see the things from users point of view.

Before we sign off, I owe to my colleague and friend Vishal Sachan for his active association on preparing this article. I would like to thank our Director Mr. Manish Dhingra for his moral support and encouragement which make it possible to deploy this White Paper. Also I am thankful to all Teknokrats (Employee in Tekriti called as Teknokrat) for sharing their views and experience.

Besides, we can not ignore the author's articles to which I refer for help. Thank You. I am signing off.