Why testing??

Well yeah, Adhering to the custom, the essential 'Why testing?' post, as every other Software QA blog would have :) albeit, in my view

Let's see 

      

      Why Testing needs to be done for a project

      Benefits of testing early.

      Why it needs to be done by any person other than a Developer who developed a module

First of all, why testing is needed for a software? Why there is a team sitting and doing nothing other than finding faults? Why the organization employs such a team and give them salary when they don't create something? They don't create any products, programs. They just create documents and screenshots of what was already created by a Development team. Why this bunch of people win their bread so easily by finding faults when other teams are putting hours of effort in coding,giving production support? And why there is a need for these testers when the developer itself does a round of testing for his/her programs?

All of these questions will be wandering in your brain, if you are a software developer. And, you would think about these ferociously, if the code you wrote is being tested.

Well, take a look at this picture.

In a typical software company, a new project or enhancement will not be a run-of-the-mill item. There will be lot of meetings between the client and business analysts, business analysts to Project Managers and then to the actual team. And, let's accept the truth that communication gaps are bound to happen. After all, we are humans.

How it will be, if a company delivers something that is different from what the Client actually wants??. Depends on who the client is? That's right to some extent. If your client is the NASA, then the tolerance levels will be very stringent even if you are working with a software responsible for a tiny piece of work done there. But, as a Software company, How big your client doesn't matter. Maintaining consistent quality to all clients is the key to success in such a time and age.

Quite few years back Testing was given least priority in software industry, may be it was coming under last phase of a Project delivery cycle, might be it curse :-)jokes apart, now this thoughts has been changed over a course of time in the Industry. To retain its Customers (To be precise to defect their competitors) every Organization is working hard to deliver top notch product. So success of a Product is fully based on its Quality.

         Say for example Consider I am a Customer who is paying some $$$$ to an Organization XYZ to develop a product which I think bring more Profits to my business. I got my product delivered for real time usage after it got developed by XYZ may be with less quality. Obviously this will affect  my business which in turn reduce my profit and also my investment on this product will also get wasted. Finally the reputation of XYZ Organization will also get grounded. So a single word "Quality" is having lot of adverse effects if it not treated properly.

Catch the bug before it spoil the grains

         Most of us having some common assumptions like, unless until a product/project is developed, the role of tester is minimal. Hope this is not the case. The best practice that every tester needs to do, is test early. Somebody might be thinking does this guy is mad? How can I test a product/Project which is not yet delivered to QA's plate.  Okay, if you are a tester Execution alone is not a testing. Go through the requirement part (Definitely your business team would have made some mistake, if not you can feel you are lucky.). If you are good with your requirement documents, pen down your use cases and discuss with the Project team. This will help developer to understand the project more clearly as most of the developers will work in small modules if it’s a large project. Since as a QA we will have full clear picture apart from the business team.

Say for an example, consider for a project I have my use cases ready. My geeky developer (as always :-)) missed one of the use case. Project is delivered to QA Team for testing. And you also started testing your project and on worst case scenario, you are testing the use case missed by the developer on the last day of the testing cycle. With more joy you are logging a defect. Now look back how this will affect this project. Now the developer needs to fix this issue. And then after he move the code to QA for testing, as a tester you need to test this part along with a regression testing if this code is impacting other part of the software.

An extra pair of eyes is always good

              Developers quite often will tend to think why I need a third person to test my code. I code this module, I am aware of nook and corner of the module. So I'm the right person to test this code. Moreover this will save time of others. Obviously not. If you did something physiologically will tend to have soft corner towards it. This will pave way for issues. If the same module is tested by other person, they will go hard at it, so that quality will be maintained.

          Best example, this article itself. Even I am the author, this was reviewed by my team members for any grammatical mistakes or spelling mistakes, in software testing term "Errors /Issues/bugs".

Have a nice time. I'll be back with an article with loads of interesting stuffs to keep you engaged.