When I first got to hear about a meetup of a group of like-minded software testers on an upcoming Saturday (02.May.09 to be precise), I was more than happy to take up the opportunity. Now, this was something I don’t get to do too often, that is, meet software testers outside my company or some of my ex-collegues so, I was expectedly looking forward to the weekend.
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! (more…)