Friday 14 September 2012

Inside the mind of a tester and how to don the role better

Software Bugs by FastJack, on Flickr
Software Quality Assurance a.k.a. Bug Spotting
Creative Commons Attribution 2.0 Generic License  by  FastJack 

This is often a hat that has to be worn by me, mostly after periods of activity slumber. In the midst of an interesting research about the future development of the projects or at the helm of one of those tech fruitions - 'TA DA!!!' - a mail from my partner arrives. 

"New version, here's a list of what it covers and what it does not do! Test!". Like a child being called back home by its mother in the evening, to do the never-ending homework - I start trudging, pushing myself to this world. 

The world of software testing
Software testing is the process of testing the correctness of executable code which does operation on data. Tester will provide various data to the executable code to see if it works as expected or if that handles all possible errors on various environments. 
OK OK - That's about being a good boy - and being politically correct as to what software testing is. But here's what I personally think about software testing: 
Any code is guilty, until proven innocent. I don the role of a paranoid - always suspicious, uncompromising and cunning, trying to frame the developer. 


Missing Hugh II by Little Miss no Name, on Flickr
A PARANOID
Creative Commons Attribution 2.0 Generic License  by  Little Miss no Name 

The only difference here is, it is a case of constructive paranoia. What makes it super special is my developer (well, most of the times) loves me for this. 
Deep-in I realize, that validation and then subsequently testing is the second most important activity involved in a project after the conceptualization. However there is always a melancholy associated at the beginning. I began to ponder over the reasons.

Why testing is the least glamorous actress around?
  • NO RECOGNITION: Foremost, there might not be any rewards from the end user in terms of approval or recognition for our testing. Give your customer a totally bug-free product. Prod him and state him the amazing fact that it does not have any bugs. Invariably his reaction to this would be: "Whats so great about this? Aren't these software applications supposed to be bug-free?". Bug-free attribute will never become a selling point for the application. And here's another killer - 'Bug-free'ness can never be demoed.
  • RESPONSIBLE FOR EVERY FAULT: Tester is responsible for every fault of the software. There is so much at stake, if I miss anything but at the same time very little that I get if I find one.
  • ANY MORTAL CAN DO TESTING: It is also a common perception that there is lesser skill levels associated with testing. To put it in other words, we think that testing can be done by any mortals. There is no proficiency that can be showcased to the world by doing a fine act of testing.
  • NO CLEAR END: A testing act at the outset, has no clear 'THE END' stage. We have grown up with the idea in mind that any software will have bugs. This vox populi retards the motivation of performing a perfect job. 
  • CUMBERSOME: Testing is also an umbrella act - there are many testing categories involved in an act of testing. To identify which are the relevant test categories that a given version needs to be put to and to stack up the relevant resources involved - this is a cumbersome task in itself.
  • VICIOUS CYCLE OF BUG FINDING - FIXING - REGRESSIVE BUG TESTING - REPORTING: Rigorous bug testing will be inhibited by the following cycle. Any version given initially for testing - will contain a bug. Fixing this bug will throw other bugs. Also other bugs might regress after the fix. So why do a rigorous test, when you have to go through the same vicious cycle after a fix is going to come? So a typical attitude will be: 'At the sight of any bug - abandon further testing. Let's rigorous test this when the fix for this comes.' 
  • BORING: There is some repetitiveness associated which might make it boring.
  • STATUS: Management doesn't consider testers equally with developers.
Why all the wooing then?
I was able to feel all the above points in my heart. But the issue was: If all this were there, why do our directors (a.k.a coders / product developers) keep spurring on the testers. They spend a good portion of their energies, motivating these guys. They seem to be pinning a lot of hopes on an act the result of which will not make the product sell more.After significant pondering over this, the parallelism dawned upon me:
'Testing is not a heroine - she is a character artist'. A character artist may not be able to attract people to come and watch the movie, but if there is no character artist and the associated scenes of emotion, the film will crash at the box office. That is what testing is : Its the character of a software. No matter how good the looks of a software may be (features), it will not be liked by people if it lacks character (being bug-free).

Reliability - A testers brainchild
The principal objective of software testing is to give confidence in the software. A customer can wait more for a new build or product release, but they don't like to work with defected software. Reliability is a hugely understated but yet powerful attribute to an application. Reliability can be defined as the probability of a computer program performing its intended functions, without any failure for a specified time under a specified environment. It is solely a testers brainchild.
"Reliability - Directly proportional to - Customer Satisfaction"
Reliability enhances (or diminishes) a product and in-turn a company's reputation.

Testers provide an environment of positive reinforcements to developers
For programmers, getting better at what they do requires quick feedback - positive and negative - on what they have done. The faster they they get the feedback, the faster they will learn. A great tester is such a precious asset to a developer. There is no better way to improve a programmer's morale, happiness and subjective sense of well-being than to have dedicated testers, who get frequent releases from developers, try them out and give negative and positive feedback. 

Even developers spend large chunk of their time testing too!
Microsoft chairman Bill Gates quotes the following about testing:
"Microsoft in terms of this quality stuff–we have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We’re more of a testing, a quality software organization than we’re software organizations ."

Testing is an act of a discovery
Discovering the unexpected is as important and in some cases more important than conforming the known. While doing testing initial rounds of testing, wear the second hat first and the first hat from there on. As to the attitude of a discoverer, Isaac Asimov quotes: 
"The most exciting phrase to hear in Science, the one that heralds discoveries, is not 'Eureka!' but 'Now that's funny..."

Every bug missed is a learning activity
Don't worry too much about a bug (may be a big one) that slipped through. Identify it, acknowledge it and learn from it. Every bug missed and acknowledged later - is a learning activity. The right spirit would be: 'This particular bug path will be considered every single time from now on and shall never be missed in my future tests.'

Testing activity as a team
It can also be an environment of fun and challenge, if testing can be done as a group activity. This provides ample scope for learning more about the software as well as the testing procedures.  

Graduate from testers to test designers
More than the act of testing, the act of designing tests in one of the best bug preventers known. Use all of your analytical and cognizant abilities, to design a testing procedure. 

Before any of the testing sessions, prepare:
  1. Testing documents - stating:
    1. features covered in the version
    2. features not addressed
    3. any other special environmental and process exceptions specified by the developer
    4. suitable knowledge base materials
    5. smoke areas for bugs
    6. testing categories that this version can be subjected to
  2. Resources for testing
 To conclude software testers do not make software; they make them better.
In God we trust, the rest we test....

No comments:

Post a Comment