Disclaimer: These are my experiences and may not be shared by individuals or industry “experts”…now that I’ve said it out loud, let me rant

Dictionary defines word Creativity as (as per Dictionary app running on OS X 10.6)

Creativity [noun]: The use of the imagination or original ideas, esp. in the production of an artistic work

Wikipedia says

Creativity – A mental process involving the discovery of new ideas or concepts, or new associations of the existing ideas or concepts,fueled by the process of either conscious or unconscious insight.

Ok ok ok, this is not a rant about definitions…so, what does this have to do with Software Testing?
Well, I believe it relates to software testing in a fundamental way, specially in the context of Indian software testers I happen to encounter via interviews, work, personal interaction, reading their thoughts on the internet.

How so?

Most testers are “trained” either via institutes or on-the-job training which mainly involves the process of forcing out ones innate ability to be curious (and explore) and indoctrinate the culture of reading reams and reams of testing literature. This process makes us believe that the literature provides answer to all problems to our testing challenges (even though the documentation was written years ago and the challenges are ever changing) and we should adhere to it for success or perish to mediocrity (as a tester) if we fail. It all sounds so familiar to me when compared to how grown up’s taught youngsters about “age old rituals” and things like “make sure you put right foot out of the house first on your examination days to get good marks”. The indoctrination is pretty smooth and consistent which forces testers to let go of their most basic quality of being creative when trying to solve a problem which eventually gets lost as months/years progress in your work life.

No, that’s not true – we need documentation/literature to learn about previous successes and mistakes.

That’s true but it doesn’t mean that we hold such things to a higher standard and do all our current problem solving using it as reference. People are creative/inquisitive by nature and if they are taught to hone that skill, I believe they become better at problem solving than making them read hundreds of pages on Processes. The key in my mind is to have an environment where mistakes are considered failures/bad. If a test team is fearful of being wrong, they’d not be creative.

This doesn’t mean that making mistakes can be termed as “being creative” but, if one is not prepared to be wrong (and acknowledge/take responsibility when wrong), you won’t come up with creative/original ideas. I constantly come into situations where I’ve seen testers being afraid of being wrong when trying/doing something new which concerns me because that feeling (of being afraid) seeps very quickly into a tester’s normal way of life which in turn stops/stagnates his potential.

Ok so if you are a Guru, what in your opinion is the solution

Well, I told you that this is a rant (read my disclaimer) and though I do not consider myself a Guru of some kind but I do believe that there are some fundamental areas of ones life that need to be radically improved if the new generation of software testers are to be better / more constructive and more contributive towards a successful product. I believe that testers need to take up the baton of not being afraid to try new things or ideas (remember kids? if they didn’t know, they’d have a go with no fear of failure). This is not a silver bullet but it certainly is something that helps one to come out of one’s comfort zone and improve – and that’s (improving) the real silver bullet

I believe that all testers can be good at what they are doing because we are an intelligent species, we think diverse, we think dynamically, we experience the world around us in so many different ways (senses) like visually, sound, abstract and above all all of us are unique, we bring different things to the table. Then why should we stop doing this and chain ourselves to few set of ideas that were created years ago (in a different context) and in most cases hurting the evolution of new ideas.

This blog is merely a brain-dump of something I’ve thought often, specially when I read about someone breaking the shackles of tradition and try out something different or use her own thoughts/ideas to explore. If you have any comments/experiences, I’d like to hear them.

PS: special thanks to Parimala Shankaraiah whose coaxing (and my promise to her) helped me in getting this post out sooner than it would have otherwise.

“I was selected during a campus recruitment as Test Engineer.”
“To save my job I switched from development to testing.”
“I just picked up the first job available and it was as software tester.”
And a numerous variations on above lines…

The common theme I see in such replies is that, we never thought of software testing as a profession we’d take up by our own choice (this is my experience in last 12years – and I will be very happy if someone points out they chose this field willingly). This way of picking up a profession (software testing) brings forth an important point – testers start at a disadvantage (maybe a better word is back-foot) as they were not formally introduced to the wonder of testing and the plethora of human behavior it encompasses to be good at it. This is very evident when I see people with designations like “Test Engineer”, “Verification & Validation Engineer” who have spent anywhere between 0-3 years in this industry. Every fresher who joins software testing teams is “taught” testing as if its something new to human brain – on the contrary, its the most natural thing we know since our birth unlike learning to write object-oriented code, designing software, etc…

Wait a minute…What did I just say? Testing is the most natural thing we as humans do since birth? Okay, let me elaborate.

One of the definition of word “Testing” as per Oxford American Dictionary is as follows:

[Noun] A procedure intended to establish the quality, performance, or reliability of something, esp. before it is taken into widespread use.

Now, this is perfectly obvious explanation and nothing spectacular but, the point I want to highlight is that, we’ve been doing testing using similar oracle since our birth and learning the world around us. Take a look at how you a child tests the reliability of his procedure to cry when she wants attention for things like food, diaper change, actually anything (mother runs to her and attends to her immediately). This simple test is done enough times by us to check its reliability before we use to widespread use for various situations in our life (kid will cry when she wants something, doesn’t want something, etc…).

We also do a varied form of exploratory testing during our growing up days, do you remember we’d touch a hot cup of coffee to learn that its not pleasant. We’d also touch, lick and consume all kinds of things to find out information about its “quality” (to us, the stakeholder). This is prevalent for all the things we do in life and we call it the process of “learning” – well, you learn things by exploring and testing.

Now, think again, isn’t this also true for field of software testing? We perform various procedures (testing) on it to find out its reliability before its taken into widespread use (aka product release).

The  fundamentals of software testing hence, highlights the fact that all of us do it (all the time) and we are pretty good at it (see we survived our toddler-hood and teens! ). The key to improve as tester therefore, includes realizing the fact that reading up hundreds of pages of documentation prepared by someone else (analogous to our parents telling us not to touch hot coffee cup, but we still test it) would never help you learn all the information available. Exploratory Testing (confused with ad-hoc testing) is a very natural way to test anything and all of us do it.

Once we realize this fundamental process of exploring and how it closely relates to software testing, we’d see the products we test daily in a different light – a software is like a box full of answers which is waiting to be asked questions and if you ask the “right” questions they’d bring forth answers that were not obvious to you in plain sight.

Summary: Testing and Exploring things is in our DNA – human brain is optimized for curiosity and therein lies the beauty of exploring things and the world around us. In context of software, it means, we are genetically programmed to do Exploratory Testing – we just don’t realize it and have forgotten the most natural way we had been doing all our lives to help do our job better.

QAI had been gracious enough to provide for a floor (not AC but hey, that wouldn’t stop a group of enthusiastic software testers to meet ). Thank you Mohan Panguluri for providing the space.

Intro’s and pleasantries

To my surprise almost all of us were at the venue relatively on time (we Indians are famous for late arrivals to meetings, gatherings) and we had a round of informal introductions. It was nice to note that almost entire group was comprising of young testers. I was specially impressed with Raghu and Shikhar who had come down all the way from Mumbai to attend this meet. I believe this kind of enthusiasm is critical for ones development of skills, networking and an attitude of “get-go” which sadly is not encouraged in our education system.

It was nice to meetup with some known faces in there (Manoj and Pradeep) but rest were new acquaintances which was interesting for me. Below is the list of people that attended BWST-1:

Aishwarya D Shukla, Ajay Balamurugadas, Guruprasad, Manjunath, Manoj Nair, Pradeep Soundararajan, Raghu Sahay, Rahul Mirakhur, Rahul Verma, Ravisuriya, Santhosh Tuppad, Sharath Byregowda, Shikhar Singh, Shrini Kulkarni
Once the initial settling down period was over and all were present, a formal introduction was done to give everyone a taste of things to come. The group present that day was very varied and that’s always a good sign – ideas thrive in diversity.

Pradeep was the moderator and judging by the methodical approach he took, it looked that he had prepared well in advance for things (which is good). He set up few basic ground rules of engagement and handed down 3 colored cards to each member to use them appropriately– this was a K-cards approach where everyone got 3 separately colored card each of them had a different significance, here’s what they meant:

1. Red Interrupt presentation immediately to let you speak
2. Geen I want to talk about something that’s related to ongoing presentation
3. Blue I want to talk about something which is not directly related to the ongoing presentation
A person can use red card only once per presentation though, other colors can be used multiple times.

Once the rules of engagement were defined, discussed, argued and agreed upon, the day kicked-off.

Topics presented

Ajay Balamurugadas (Rapid Software Testing)
Ajay talked about his learning journey from starting as a fresher in testing (as profession) and how slowly he kept on realizing that he was mostly expected to read instructions from a spreadsheet (as a set of test cases) and then execute them on every build thrown at him. The job expectation was exclusively to follow instructions of executing test cases listed in spreadsheet (religiously) and report their (I think inevitable) passing.

As Ajay discovered Exploratory Testing concepts , he attended a RST session which evolved his testing techniques and that, as expected, helped him find more bugs. This however, wasn’t expected by his organization and it seems that they kind of got suspicious of how he was suddenly able to find more bugs (was he hoarding bugs or did he develop a special sense? hmm…). This has brought him into some tough situations but he has withered the storm and organization views him as someone who can “jump-in” any project and find bugs. I think its a good sign that Ajay is doing things in the right direction.
My Take-Away: Thirst for learning new things doesn’t need to be pushed from others (specially employers) but is intrinsic in people. Exploratory testing when done consciously allows testers to attain more information than traditional testing techniques will ever give.  Ajay looks to have a sound head on his young shoulders and has realized the benefits of RST. All the best to him for his future.

Manoj Nair (An attempt for better testing)
Manoj shared his experience of how (in his previous job) once the team thought they had finished testing an app however, he took upon himself to review some project documentation that had not been up-to-date as per latest design. This brought out some test ideas which he wanted to test however the time that it would take to test it out “completely” was way more than what the team had. His Manager gave him the go-ahead on “exploring” the unexplored regions – important to note is that he set the expectation that he won’t be jotting down detailed test cases/reports during his exploration (good thinking Manoj!).

Now as Manoj’s exploration started to turn up important bugs and design issues, it was clear to team that the project was not ship-ready (o oh!). This was great news from testing stand-point as Manoj was able to  unearth some key issues which would have costed company way more than the decision to stop the release and fix the issues however, as he had not kept detailed documented track of his exploration, it created a problem for Manoj when Management asked for documentation of his testing i.e test case, test design, etc…

Manoj then mentioned that in hindsight he should have used Session Based Test Management technique to better track his test ideas so that he could share more detailed information about his testing.
My Take-Away: Manoj’s conundrum of how much to document and how much time to spend doing “real testing” is a typical one. The piece that interested me was the foresight he demonstrated to set correct expectations with his Manager before embarking on his mission. The part which I felt could have been improved was the push-back his Manager could have done to Management for creating post-mortem documentation and simply use the results to setup similar exercises for future projects (from the beginning instead of at the end).

Manjunath (Bug report reviews)
This one is something I am sure everyone in that meet enjoyed and had the most laughs out of (no pun intended).
Manjunath’s team on one of the projects had looked their bug reporting and found that had a big scope of improvement. This led to him (and I think some more team members) to start reviewing the bug-reports and providing feedback to bug reporters. The outcome of the exercise was that the bug-reporting had improved and the Management was impressed by the improved quality of bug reporting. This experiment was then extended to the next project Manjunath was part of.

Now, as with many good idea that when pursued with incorrect implementation/understanding/foresight bears unexpected (and mostly devastating) results, this one failed. The bug reviewers and reporters were spending way more time nitpicking on things like grammer, layout than testing the product. This kind of review also demoralized testers as they were picked upon their command of English language (personal experience – this is a sensitive topic for Indian testers and needs to be treaded carefully).

Eventually Management realized the writing on the wall and scrapped this idea for any future projects.
My Take-Away: This was a wonderful topic to highlight some subtle things that we (Indian testers) never realize i.e. how important English as a language is in our line of work. I think reviewing quality of bug-reports was a very good idea however, the way it was mandated and applied had set it up for failure from the start and then, as it happens quite often, blame was put on the concept than on the application of the approach and shelved.
I believe that testers need to realize that written and spoken English plays a very important part in our success of communicating important information to project stakeholders. Command over language is the icing on the cake, not the cake. This is not easy for us Indians as its not our first language however, the only common language in IT domain and its very easy to improve with practice (just like anything else in life I guess).

Rahul Verma (Confessions of a fallible tester)
Rahul’s presentation was interesting on couple of scales. He has a flair for presenting which I guess comes from his early exposure to Theatre (personally I think such experiences make a huge impact in how you develop as tester) and also the topic he chose i.e of sharing his mistakes rather than the successes – I believe its very important to remember your mistakes in life as that’s a great way to improve (in anything in life).

The presentation focussed around his early experience with the term “best” – on one of his early projects, he was mandated to use a certain Performance tool as it was the “best tool in the world” (tall claim in the ever changing world of technology). All of us could relate to such mandates as when you are new to a job or domain, you tend to NOT question your seniors claim and do things as directed. So, just like all of us, he also used the tool and during the project found out that it wasn’t that great. He then highlighted the reasons why using that tool proved to be disastrous to the project – a valuable lesson to learn indeed.

He also shared an interesting bug he had experienced when scripting a tool where, just because of 2 blank lines at the end of the script, tests that were supposed to fail were passing – I couldn’t help but smile at that point as I have had similar (an innocent looking space played havoc) experience – maybe a topic for another blog.
My Take-Away: Another confirmation to the fact that nothing is BEST forever. One of the dictionary definitions of word “Best” is – most excellent, effective, or desirable type or quality. This definition highlights why we shouldn’t use this term in our domain as its parameters are (by nature) ever changing. However, I guess we still haven’t realized this and continue to use the term loosely and end up costing our clients money.


Rahul Mirakhur (My career and experience in testing)
This presentation was more like a Q&A from the start. The main thread was why do we look down upon software testing as a profession, this I put forth as the statement “When people say WHY will you want to be a software tester, I ask WHY NOT”.

I highlighted the fact that humans are born explorers. We explore and test from the day we come to this world by crying and finding out (a very important information I may add) that we get fed when we do that. We also explore and learn valuable information while growing up hence, the trait of exploratory testing is innate in us and we can excel in this field of profession if we only continue to do what we did in our childhood i.e. Explore areas to find new information.

Another point that I touched upon was the way  current testers come into this field. It is mostly (if not always) a forced decision, either because of failing an aptitude test in a big company interview round or directed to test a project from your Management. This gave rise to some interesting side-discussions one of which also touched upon capacity to learn new things as one gets older. I made a point that its relatively hard to learn radically new things when you are old compared to when you are young to which, Srini pointed out that he constantly looks out to learn new things all the time and finds it easy.

Presentation also highlighted the value of various functions of a team e.g. Tech Support who holds an enormous amount of knowledge about the product that you’ve released. Tapping into this knowledge allows you to have access to greater test ideas for future (related) projects and also helps you find bugs when you are very early in project life cycle e.g Requirement gathering or Design.
My Take-Away: Well, I was the presenter so didn’t take back much however, I was happy to put forth my ideas/thoughts to an attentive audience and got some interesting questions during the discussion.

Sharath Byregowda (Session Based Test Management)
Sharath’s presentation revolved around his experience with SBTM (Session Based Test Management) and how he was able to work within a restricted hardware access issue. It was interesting to note that he creatively split the team in 2 parts so that only team was using the hardware when testing and the other one was reviewing all the test notes, ideas, bugs they had noted down during their round of hardware testing. The approach helped Sharath attain good confidence in his testing effort and resulted in Management recognizing his effort and awarding him. His management then decided to term this approach as a “best practice” (o oh!) so that every team follows it. Sharath shared his concern on this and mentioned that he did not wanted that to happen as every team may or may not need the “style” of SBTM he had done and that it would be impossible for him to monitor and correct such failings which will eventually result in poor or wrong results and then people will be quick to blame SBTM rather than the actual problem.

He has a blog dedicated to SBTM detailing his approach and experience, do read it.
My Take-Away: The approach which Sharath had taken was creative and the fact that he realized the pitfalls of pushing success stories as “best practices” tells me that he is going in right direction. Its way too easy to fall in the

Shrini Kulkarni (Test automation consulting)
Srini’s presentation was about sharing his experience of Automation Testing in ITES domain (where most of his expertise lies) and how most of his clients more often than not request for metrics of some kind or the other. He illustrated the point of collaborating with stakeholders by talking about a project where he did not know much about a technology when he went visiting a client (all his collegues discouraged him as he did not *know* the stuff) however, he used his collaborative skills to talk to clients and find out what exactly they needed out of the system and by the end of the trip had more understanding of the tool than the clients themselves. This is an interesting point to note – one can not be expert at everything, specially in the world of software where technologies keep changing (as a rule) however, its important to have the skill of questioning and observing that helps you more than one realizes when learning new things (isn’t that true for everything in life?).

Srini then went on to involve the audience in a Q&A type of discussion which led to us discussing various aspects of ITES doamain and its peculiar challenges.
My Take-Away: World of service-based and product-based software companies are quite different and a tester needs to quickly realize the way to deal with these differences. Personally speaking, when I switched from product-based to service-based company 2 years back it took me a while to fully realize how the perception of quality changes between these two worlds – Srini has spent all his experience in one part of this world which have a specific kind of challenge when dealing with client expectations. I am interested to learn a bit more of this world.

Side discussions I found interesting

During the presentations, as expected, there were a lot of digressions/tangent chit-chats which were equally interesting and worthy of their own presentations but due to time limitations had to be summarized quickly, below are few topics that came up (there were more but I don’t recollect them all):

• Management likes metrics not bugs that stop releases
• Executing test cases that capture requirements “never” found bugs – Exploratorty testing always did
• How much documentation to do when testing, specially when a tester is “in the zone” and following up interesting test ideas
• If a tester wears different stakeholder hats (perceptions) she can find a lot of valuable information about a product
• Use of new technologies like Wiki to collaborate more effectively during testing – there are so many free tools available these days that empower testers to tester better
• Discussion around how testers need to “earn” the credibilty to be part of design meetings or else entire testing department gets tagged as “not needed” during such important meetings
• Effective bug reporting – using video or audio (where relevant) tools to add more information when reporting a bug. Discussed briefly on bug advocacy (very apt)
• How testing tools are “favored” by Management (or deciding person) which impact what gets purchased and “dumped” onto teams — I believe this is a serious issue if true (I don’t have personal knowledge of this actually happening though)
• Discussions around pros-cons when a technique like SBTM gets pushed by Management as “best practice” without looking at every projects context (I remember talking at length on this to Sharath as he had some genuine concerns)

Interesting statements made during discussions

• Testing is like asking questions to a software. A bug is found by a question that gets a wrong or unexpected answer (Rahul Verma)
• Testers can wear different (stakeholder) hats to represent varied interests of real stakeholder (Rahul Mirakhur, that’s me )
• Value depends on what stakeholders define it as (Shrini Kulkarni)
• How much information do we need, when does it become an overflow (Aishwarya)

Some more talk over food/drinks @ Oasis

After the official meeting was over, some of us still wanted to butt our heads against few more topics (testers never stop questioning or talking!) so we all stopped over at a near-by shopping mall’s (Oasis) food court. Inicidently there was a T20 cricket match was going on and needless to say most of our talks included keeping our eyes on the big TV, putting food in our mouth and talking about software testing – all at the same time

End note

Great meetup with passionate software testers along with some freshers who I hope will carry the torch! Look forward to the next edition in coming months – Pradeep are you listening!

Stay tuned!

Rahul.