Archive

Thursday, June 26, 2008

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.

Tuesday, May 27, 2008

Watch out the special character- A lesson I learnt

Many have experienced most of the Social Networking site is built on using php. This is because of the fact that php has enormous in build rich functions which made "developing a web site" easy. These web site give users the facility to publish blog post to showcase their experience, work in the form of web page.

While testing a social networking site in our company, I got to learn many nitty-gritty of web testing. But one incident/lesson that I learnt from it which I will remember through out my life. Do you think it was the criticism that I had to face? No, not at all. It is because of the behavior to certain parameter displayed by php.

In this application, apart from blog posting user also can comment on blog post. I have tested this feature applying all the techniques that satisfies a form testing. And the outcome is good as it is doing what is expected to be. And you know once the build is certified by tester, it is deployed in production server where end user explore the functionalities.

To my surprised, we received a bug in our bug tracking tool from client saying that user can not post comment on blog post. I kept wondering all the day- how it can happen. I started retesting the functionality and did not get much success. At our end that bug was supposed to get a new status which is "Not reproducible". Generally, we assign this status when a bug can not be reproduced at our end. It's not unusual, sometimes it happens that the same bug can not be reproduced at the later stage of development. Anyway, lets get back to our topic of interest. Before I changed the status, I though for a while thinking that it would be better to break the ice communicating with end user.

I just shot a mail to them asking the parameter or the input they entered in to this feature. All I got an input parameter i.e. Karol & I. I though, "Does it make sense?"

Yes, it does. When I put the content in Comment field and clicked on "Post", it generates a lot of error notices by php which corrupts the user interface and makes the page unusable. Interesting, isn't it? But, in fact, that was a big blow to me. I was completely bull-headed. I could not rest without investigating the actual cause of the issue. I narrowed down the input to "&" only and that did the trick. Though it was amazing, but it turned up the heat on me.

So tester guys, don't limit yourself to the orthodox testing, do something extra to break the functionality of the feature. Find out all the possible way to test a feature. Wish you a very happy and exciting journey ahead...!!!

Monday, February 11, 2008

Bill Visit to India

Please don't misinterpret by name Bill as Bill Gates, but it's Bill Brinner, the Managing Director of Acteva. Bill paid a visit to our Company on Monday(11/02/2008) morning and acquired the progress of SocialWorld( formerly, zDi). Though I had never met him, I guessed him as a young guy. But it turned as wrong he is a matured guy and aged something near about 50 or so. He appreciated our work and wanted to give away treat for the effort we have put forward for zDi. He invited our team for lunch and took us to a Chinese restaurant called "The Monk". On way to the restaurant, I accompanied him and started to get little comfortable with him. I began with a question related to our projects and the conversation started up. Once you start a conversation, it always ends with personal questions. And that was what happened to me. I ended up my conversation with some personal questions like about his family, where he lives, what his likes and dislikes etc. It did not seem awkward to him. He responded nicely to those question. Finally, we reached "The Monk" and sat down for the lunch. We passed time, till the ordered lunch come, covering all the talks of life and it's daily hurdles.

Friday, October 12, 2007

Let us know some Software Testing activities.

What is Testing :
Intentionally finding errors from the software is called testing. Errors may be functional errors or usability errors or excess functionality which is not defined by client.

Inadequately Tested software negative impacts:
It is difficult to test software products, as evidenced by the problems we find in our software every day. The customer risks of not adequately testing software can be as minor as user inconvenience or as major as loss of life. Not only are there customer (end-user) risks for inadequately tested software, there are also corporate risks. Especially for mature products, an inadequately tested product can have serious negative consequences for a company.

So, What an organizations doing now :

Organizations are actively working to improve their testing processes and increase the number of people devoted to product test.However, many organizations still rely on structured manual tests that test the product at its uppermost levels, the levels closest to the user. If you need to reduce the number of defects or meet stringent performance or reliability criteria, then user level testing is not adequate. You must look at the product architecture and develop tests based on the major modules, the interactions between those modules, and the flow of data between modules


Every Test consists of 3 steps :-
¨Planning : Inputs to be given, results to be obtained and the process to proceed is to planned.
¨Execution : preparing test environment, Completing the test, and determining test results.
¨Evaluation : compare the actual test outcome with what the correct outcome should have been.

Every project need a tester :
Which projects may not need independent test staff? The answer depends on the size and context of the project, the risks, the development methodology, the skill and experience of the developers, and other factors. For instance, if the project is a short-term, small, low risk project, with highly experienced programmers utilizing thorough unit testing or test-first development, then test engineers may not be required for the project to succeed.

What are Test Deliverables :
Test Plan, Test Case, Defect-Fault, and Status Report are the sets of test deliverables in any testing phase. This does not represent a definitive set of test deliverables but it will help any test organization begin the process of determining an appropriate set of deliverables. Test deliverables’ goal is to capture the required content in a useful and consistent framework as concisely as possible