Stepped-in to STeP-IN Summit 2011

Conference, Meetups, Testing 4 Responses »
Feb 262011

One of my to-do list item from last year was that I didn’t do justice was, blogging, and I (in all earnest effort) hope I’ll do better this year, so let me start afresh (again).

This month QSIT hosted STeP-IN Summit-2011 in multiple cities, I had earmarked attending their Bangalore chapter hoping to catch-up on new trends of Software Testing that Indian IT is raving about, along with catching up with some old friends I somehow only end-up meeting in conferences.

True to its promise, STeP-IN had a wide range of topics spread over 2 days. Icing on the cake was their decision to do a 1-day pre-conference covering 4 separate half-day sessions on select topics. I had chosen to attend sessions from Lee Copeland who I had been following for quite some time for his great endeavour for STAREAST/STARWEST and, Rahul Verma whose constant pursuit to improve his knowledge of Software Testing amazes me everytime I meet him. Selecting these 2 topics were no-brainer for me and, here is a quick summary for all the readers out there who couldn’t make it – I hope I’m not breaking any NDA and will try and keep it to a generic-enough level so as not to get sued :)

Pre-Conference sessions (Feb-16)

Advanced Test Case Design using Pair-Wise Testing (Lee Copeland)
This is not a new concept or innovative test technique however, I was not surprised how it was received as something new by a lot of testers attending this session.

Initial half-hour or so Lee covered more generic testing topics which set him up nicely for the topic-of-the-day which was Pairwise testing. Lee has a knack for story telling (typical of good testers) and he used that to good effect to highlight how it is very important for testers to constantly question their beliefs and challenge claims by people to things they like to call “best practices”. I was surprised that not many had heard much about Exploratory Testing during this session, had somehow assumed that most testers in India already knew this testing approach well and practice it in various levels. I think there’s still a long road for us Exploratory Testers’s to carry the light and get it the exposure it deserves.

Pairwise testing is a technique that is very handy when you have to test a set of variables that result in a big list of combinations of possible test cases. Think of a typical use-case for web testing team who have to test a web page on different flavours of Operating Systems (Win-XP, Win-7, Ubuntu, Mac OS X, iPhone, Android) running different Browsers (IE, Firefox, Safari, Chrome). To test it “completely” you’d end up with a huge list and yet, we really don’t need to test “all” of them because most of the bugs may be identified if we hit upon all of these variables (OS and Browser types) at least once. So how do we get a smaller/more manageable set of test cases? say hello to Pair-Wise testing.

There were 3 different flavours of Pairwise testing that were discussed during the session, which were:

All 3 try to achieve the same goal of minimizing a real big list of possible test cases to a more realistically (and executable) number of test cases while ensuring that each variable is covered at least once.

This is not a silver bullet that testers can use in every situation where they have a matrix of variables to create testable combinations from. The caveats are aptly highlighted by James Bach in one of his papers on All-Pairs which I’ll try to summarize below:

  • You must identify variables that interact. It’s tempting just to throw a bunch of variables into the mixer, but there is no probability of a bug unless the variables interact in some way.
  • You must identify variables that can vary independently. In practice there are often many dependencies between variables. This leads to illegal test cases.
  • You must choose specific values for each variable. Usually this means partitioning the variable into “interestingly different” values. But in practice you can’t know for sure what is interesting.
  • You must provide the test procedure. All the pairing tool will do for you is tell you which sets of pairs to try. You still have a lot of work to do to make a good test.
  • You must provide the oracle. This is more difficult in pairwise testing. So much changes with each test, there is a LOT to check.
  • You must add cases for interesting combinations that pairwise testing ignores.

Key take-away for me: I had used all-pairs sporadically over the last few years with my teams and though, it hadn’t been as relevant to my testing needs on regular basis, I’m sure this refresher will make me remember to check for its usage in coming projects.

Designing and implementing a Common Test Automation Platform (Rahul Verma)
I’ve known Rahul for some time now and he is one of those presenters who relishes an audience. True to his nature, he was in full flow and at his eloquent best when tackling a daunting challenge of talking about a new way of thinking/designing/creating/implementing a generic Test Automation Platform. This was not a typical presentation on “how” to make an automation framework BUT, was about “what” things to keep in mind “when” deciding on making an automation framework. He used his current job’s use-case for most part of the presentation but there some good insights on the pitfalls, lessons learnt, tips and caveats ppl. need to remember when creating an automation framework.

The new thing that sprung out at me during this session was that it used a very simple mechanism of Object-Orientedness to devise the entire framework and gave more importance to the actual Test Case than the process of writing scripts in sequence to automate workflows. There were quite a lot of things covered so here’s a snapshot checklist of them – there are quite a few details that I haven’t listed here and if you have questions, feel free to contact the actual dude directly :)

  • Creating a Test Automation Framework (TAF) is a very common requirement in big teams, we typically go look for tools and they mostly do not do all what we need so we end up customizing them OR mostly, end up creating our own TAF’s
  • There are some important decisions to be taken way before you even start writing up your TAF. These decision are critical to success/stress you’ll experience when you are making or using the TAF
  • Focus more on Tests when designing TAF rather than things like integration with Bugzilla, Email, Reports, etc…all these are noise that seem to overshadow the TAF designing time rather than thinking on what the actual Test should do
  • We should look to design the TAF modular, scalable and flexible so that we can integrate additional features later on
  • Don’t distinguish your Tests outside of TAF, distinguishing means – categorizing Tests as functional, regression, performance, load, stress, fuzzing, etc
  • Empower each Test with ability to decide on runtime what it should do
  • Use Test Encapsulation to allow them to decide on runtime with help of using meta-data for things like I list below – there are a lot of things a Test would like to KNOW for itself at run-time
    • Priority (do you want me to run now?)
    • Logging (should I use central logging mechanism or log something local)
    • Performance (should I time myself?)
    • Bugs (are these related to bugs we already know about?)
    • Platform (what platform am I running under?)
  • Think in modular terms when designing Tests, think running them as
    • Prepare mode
    • Set-Up
    • Run
    • Report
    • Clean-up

Key take-away for me: There needs to a lot of thought that should be put way before teams think of designing their TAF and this session just highlights the benefits of planning rather than jumping in using tools and hoping everything will work out. There’s no shortcut to hard planning for successful frameworks.

Conference days (Feb 17-18)

The conference had hordes of software testers from a whole range of IT companies but it seemed to me that, the bunch of attendees were mainly from big MNC’s and less from small organizations who I think, would have benefitted more from such conference, maybe its the cost? not sure. I think Testers should try and network as often as possible via such mediums, blogging does help but conferences still has an advantage of face-to-face interaction which is quite unbeatable. The topics ranged from how testing is optimized in Trading domain, seemingly popular among many, Performance testing to, every testers all-time favourite, Requirement analysis. One thing that Lee had mentioned just 1 day before (and resonates with me quite a lot) was the way presentations were done, a lot of information was crammed into small Powerpoint files which were literally unreadable from 3rd row onwards. I wished either there were really good projectors OR, presenters used a format that helped audience read them better.

Here are few topics that I discussed, overheard, contributed to during the conference

  • Testers do not get enough visibility during initial phase of project
  • Test teams do not get enough time and always hard-pressed for resources (Me: I think we should really stop whining and be creative for solutions — no one ever has enough time!)
  • Testers do not get heard or respected enough (Me: Respect is earned, providing timely & useful information will go a long way to earn respect)
  • Everyone wants to claim that they use Agile even through they “really don’t. Its the buzz-word of the industry for quite some time now
  • Automation (of any kind as long as we can throw that word) is still an enigma which everyone wants to tame but has trouble with, despite throwing tons of money/hours at it
  • Testers are realizing that they need to add more value than just running scripted test cases and that learning more about the business models is going to give them an added edge in today’s competitive world
  • Working in large companies gets you the brand but the quality of work (aka job appreciation/satisfaction) still seems to come from working in smaller companies/teams

As usual, the part I liked the best was the out-of-room networking and catching up with old friends and fellow Testers who I typically only see during conferences. One thing I wish could’ve been different was to meet more often than not.

Topics that flattered to deceive

  • Testers aren’t born, they acquire greatness! I had expected to see some discussions about Exploratory testing, creative testers, how we do not need to stick to traditional biases and guidelines of testing. Sadly it wasn’t what I hoped it was but, the regular rigamarol of how we need to do things like manage timeline, attention to detail, etc. Oh one more thing, I don’t think that testers are NOT born, on the contrary, I think we all are born testers (read an earlier blog from me).
  • Testing mobile applications for usability and context, “Crowd-sourced”, the topic looked interesting to me as I do iPhone/iPad testing for living but the things covered were pretty basic and something I could’ve learned via Bing anyways. No disrespect to the presenter – just that I had hoped for more.

All in all, they were great 3 days of interacting with Testers, listening to interesting topics and seeing what some of the big Software firms of India had to say about Testing and the future of this cult.

Did you attend Summit-2011? Is there something you want to add/rebut/discuss? lets talk some more in comments section.

Thanks for reading!

 

Posted by Rahul at 11:34 am Tagged with: ,

We get educated "out" of creativity.

Testing 5 Responses »
Apr 012010

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.

Posted by admin at 5:07 am Tagged with: ,

I do Exploratory Testing. Actually...everyone does.

Testing 2 Responses »
Jul 112009

I think being a software tester by profession is very interesting and exciting. I constantly get into discussions of how did I get “into” doing testing. Of course this is a very simple question and am sure you never stop and think about the answer you generally give which ranges from:

“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.

Posted by admin at 2:47 pm Tagged with: ,

BWST - Tester's meet up!

Meetups 6 Responses »
Jun 232009

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! Continue reading »

Posted by admin at 7:01 am Tagged with: ,

Hello world!

Uncategorized 3 Responses »
May 162009

Welcome to my Oracles And Heuristics. This is just a placeholder post for now and will soon be starting with my blogs.

Stay tuned!

Rahul.

Posted by admin at 9:40 am
© 2011 Thinking Rock Suffusion theme by Sayontan Sinha
Theme Tweaker by Unreal