My experiments with Testing

Well to say that this is a technical article is totally unfair. Here, I share my learning, experiences and expertise that I gained during my journey as a Trainee to Technical Lead in testing domain.

In general everyone is under impression that Software testing is nothing but only finding bugs (or you may call them issues also) in the application or product. And if someone has a fare idea about that, then the definition could be “Software Testing is the task of trying the software application to see if it works and trying to break it.”

If this is all about the Software Testing, then what is the basic idea to keep this phase in the Software Development Life Cycle (SDLC)? We all are aware of the SDLC. It has some phases that come while developing the Software. The main phases of SDLC are:
1. Feasibility study
2. Requirement Analysis
3. System Design
4. Coding
5. Testing
6. Implementation and Maintenance

Now the first thing is how is Software made? Well for that, we can say that someone has a good idea and define some requirement. Sometimes these guys are from Marketing, sometimes an Engineer (not necessarily a computer engineer), sometimes a very cool hunk, and sometimes an ordinary person (not from Computer’s line). They do some research or they have some good experience in different areas. They define their requirements. That basically includes what they want from the software to be developed. Now the requirement also includes how the software will work and most importantly, when it will be shipped to the customer. After that, the engineers worked on those requirements. They work on the detailed design document, how the software will work behind the scenes, how the user will interact with the software. The decision will be made by the upper management that which software language and tools will be used to develop the software and write the code. After developing the software, testing will be done. The software testers test the product and verify that it works properly. If everything goes fine, the product is shipped to the customer.

Now let’s see the testing part of this cycle. First thing is when this is done? This is done before the product is shipped to the customer. Now what will be the base for the software test team to test the product? Sometimes a tester can rely on the written specifications to explain what software is supposed to do. Using those written specifications, they are supposed to create a good amount of test cases (Quality + Quantity), test the product and shipped to the customer within the defined timeline. Here the bold and the underline point is that the product should be shipped to the customer within the defined timeline. To achieve this, most of the times testing team has to suffer a lot. These are the guys that have been mostly affected to achieve the deadlines. In one of my previous project, my manager instructed me to test the release within two days. I was the only tester in the team and the development team of six had spent more than 30 days to develop the application!!!

Sometime, it happens that the testing team has no requirement specifications documents but they are supposed to test the release thoroughly and fire some good bugs (Quality + Quantity). Now why I am referring to Quality and Quantity both? Quantity should be more means the number of test cases and bugs should be more. Quality means good and deep level test cases with some really showstopper kind of issues. Now come to the requirement specification part. As I am saying sometimes it happens that there are no requirement specifications documents and testing team has to test the application. This is really a painful situation for the testing team. They have to test the release and deliver it to the customer. After that, they are the people who receive some R*E*A*L*L*Y good comments from the customer. In one of my previous projects, the development team developed an application for more than 6 months and we tested it thoroughly. When we showed the application to the customer, he simply said “What is this? This is not the application that I want. This is totally different.”!!! &$#@!&&*!!!! So just remember one thing:

WHEN THERE IS NO REQUIREMENT SPECIFICATIONS, EVERYTHING IS A BUG.

Sometimes, testing team is the only team who has to shrink their testing life cycle to achieve the defined target dates. Or they have to stretch themselves beyond the expectations. In another project of mine (one of the very reputed project of my career), I used to work from 6:00 AM till 12:00 midnight only to deliver the quality release to the customer. Although the satisfactory fact is application is today being used by thousands of users and I proudly claim myself being part of it.

I started my career as a System Administrator guy. Then, I worked with one of the greatest and coolest boss of my career. He is the person from whom I learnt a lot. My boss supported me a lot. A really great guy and a great human being. Anyways, let’s come to business. When I was in system administration team, I always thought why testers are always troubling developers. One of my friends was in testing team and I always used to ask him what the hell they are doing? Development team writes the code and you are cracking it. But that was not true. Testing team &development team both have combined responsibility of delivering a quality release to the customer. Now the point is “What is Quality?”. The best one liner about the quality is:

CUSTOMER SATISFACTION IS QUALITY.

If the customer is happy with your work, you have done a quality work. That means, if all the features, modules and functionalities, that customer wants, are present in the software and all the features, modules and functionalities, that customer don’t want, are absent in the software, you have done a great job. Irrespective of the fact that the development team developed the application in 20 days and testing team tested it for 4 hrs only, if customer is happy, all are happy. And the life goes on and on and on. I mean the company goes on and on and on ……………………..

More often in consumer products, a requirements specification doesn’t exist. In this scenario, a tester must figure out what to test and what software should do on their own. To do that, they used a combination of asking questions of the product manager and the engineers, their knowledge of how the software runs and their intuition based upon their experience. This helps the testing team to create a good amount of test cases and execute them according to the requirement (that is not specified). Using this technique, testing team can fire some good number of bugs in the application. A bug is not just an error or defect in the software. It is deemed a bug if the software doesn’t perform as required, specified or expected.

In brief, I want to summarize some of the good qualities that a tester should have to fight these kinds of scenarios and deliver a QUALITY release to the customer.
· Quick Learner
· Curious
· Well Organized
· Good observer (Mr. Perfectionist!!!)
· Ability to work with a ambiguity and with a minimum of direction
· Self motivated with a excellent written and verbal communications skills

Although all the qualities referred above are important, but one thing I want to say that a tester should have a good communication skills. Why? As a tester, your job is finding bugs and informs this to the development team. So you are always a bad news reader. If you present this bad news in an ambiguous way or with a bad attitude, the recipient’s natural response may be to “kill the messenger”. I have faced this behavior once in my career. By having professional and accurate communication skills, a tester can easily be viewed as a valuable member of the team and not as a “necessary evil”.

As far as bugs are concern, if the testing team is working in a proper way, they can find a huge number of bugs. I am listing some of the points that are majorly responsible for most of the bugs in the software:
· Communication Gap within the teams
· Complexity of the Software
· Changing requirements and programming errors
· Time pressure and poorly documented code
· Errors in Software development tools

So now the question is “What is the goal of software testing?” In my opinion, software testing team goal is to demonstrate that the faults are NOT present and not merely finding the number of faults present. To achieve this, they should get involved from the first phase of the SDLC. Testing team should ensure that all the functionalities are working fine according to the requirements. And most importantly, the customer should be HAPPY. He should get what he wants from the software

To achieve all these goals, we should follow structured approach to testing. Test Planning, Test Design and Test Execution should be conducted in a proper way. I’ll cover more on this in my forthcoming articles.

Finally, in my opinion, we as a testing community should just remember: We are guardians of quality on behalf of business community, particularly where time pressures force developers to take short cuts in normal development process.

-- Sanat Sharma