Testing??????
In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was believed to be lost in space due to a simple data conversion error. It was determined that spacecraft software used certain data in English units that should have been in metric units. Among other tasks, the orbiter was to serve as a communications relay for the Mars Polar Lander mission, which failed for unknown reasons in December 1999'

Thanks to the many emerging highly technological fields, testing has carved a niche for itself. Constructive destructivism is perhaps this. Testing on a broader perspective has many facets. Be it product testing, Web Testing (add another type), manual intervention is indispensable, Onus lying on the Tester. The article deals with the different scenarios one comes across during an end to end testing of a web based application using manual effort.

Having taught us the joy of taking responsibilities, do we really own it when a missed bug is reported? Many a nights have we spent to find an excuse…was that really my fault? Was it working fine before? How did the scripts miss it? ...a few of the many questions that would run through our mind...Did we really find an answer and did we have the nerve to accept the truth??? Had we admitted the truth and proceeded with the next set of execution without corrective action we go wrong and in the process fortuitously make ourselves susceptible to more such unreported bugs where more streamlined approach would do the trick.

We are in a stage where the project proposal, estimation, Coding is done and the Requirements are sent to the Software testers for clearing the ambiguities. Clearing ambiguities at the right phase and at the right time is very vital for increasing one's test efficiency. Be it automation or manual testing one has to have the aptitude to come up with clear ambiguities to find bugs at an earlier stage. Clearing ambiguities might be more challenging in situations where the application is yet to be developed while Test scenarios needs to be identified and test cases to be prepared while the coding is still in its nascent stage unlike and testing an enhancement. Visualization of the requirement accords greater importance here and congruous thoughts needs to be established. Good Testing skills also require the ability to be prepared for the answers for the queries asked to complete the task effectively.

Often referred to as the Quality Assurance team, on a note of retrospection do we actually improve quality? Tests designed before coding begins can improve quality. We can inform the developer of the kinds of tests that will be run, including the special cases that will be checked. The developer can use that information while thinking about the design, during design inspections, and in his own developer testing. That indeed is a value add.

Early test design can do more than prevent coding bugs. The process of designing them can find user interface and usability problems before expensive rework is required. However one should be wary of the fact that involving testing early feels unnatural to many programmers .There may be feelings that we are intruding on their turf or not giving them the chance to make the mistakes that are an essential part of design. Care can be taken, especially at first, not to increase their workload or slow them down. It may take one or two entire projects to establish your credibility and usefulness.

To cite an example for this case, if we were to test a text box, ambiguities might include the number of characters to be displayed, scenario when the number of characters would exceed the size of the text box for the latter while preparing the ambiguity one needs to know the three possible solutions for the same.

1. Number of characters would not exceed the size of the text box
2. Horizontal Scroll bar
3. Vertical Scroll bar

If the answer were to be either choice 2 or 3, then the immediate question would be on the final cursor position upon striking the return key, whether this would be on the starting or the final character. Ambiguities with foresight serves two purpose, identifying bugs at an earlier stage and saves time to get issues clarified specifically when the location of the business, development and testing team work from different time zones. Translating business requirements into test cases and mapping each test case to the requirement accords significance. On a generic note, the system is prone to be unstable when negative tests are performed. Hence clearly identifying the positive and negative logic and mapping both the types to the corresponding requirements and in turn to the actual field in the application is a good practice. One key differentiating factor would be preparing different set of test data for manual testing as well. A stitch in time saves nine!

Unpredictable is what would describe most systems generally! Many a times, we come across situations where a scenario would pass one day and fail the other, while the tester being in the dark. As we own responsibility for the outcome, it is our duty to substantiate the claims as well. One of the easiest ways to prove the validity is snapshots! An Alt+Print Screen on a simple word doc would suffice! Voila! No more tensions of any proof!

Checklists! The guiding star to keep us updated of the events. Checklists contribute to the quality of a software system by (1) bringing the experience of many people to bear on each situation and (2) standardizing the review process so that the results are independent of the participants. These lists include those items that we want to be certain are included in the system as well as those items that are most likely to contain defects.

Stop Knowing when to stop is a skill. Having identified the completion criteria in our initial stages metrics is all that helps us in determining the release threshold. A diligently maintained metrics is a living proof to project where we stand and what difference we have made as a tester in short, a true source for retrospection.

Happy Testing!!