Buggy Reporting

What’s buggy reporting? You might ask. No, No. It’s not yet another new term. I don’t want to add newer terms to the technical jargon wars going on in different parts of the world already.

Buggy reporting talks about how buggy real bug reports can be. It bugs me a lot to read buggy bug reports which hardly talk about bugs in a understandable way. As testers, we all know that bug reports are important for providing information to the stakeholders. Still, we don’t take any effort to review our own bug reports. If we ourselves are not interested in reading our own bug reports for clarity, how can we expect programmers and other stakeholders to not just read them, but also decide whether to fix problems reported in those bugs? Height of Optimism!

Awesome Titles

“Script warning”

“Spelling mistake”

“file not loading” and

My personal favorite “Thomas is a fool!”

“Thomas is a fool” was a real bug in one of my previous organizations. As part of learning a complex component, I was reviewing all the older bugs that were reported and fixed within that component. That’s when I chanced upon this “Antique Piece". Thomas was one of the managers in the organization who may or may not have done anything good to one of the employees who literally reported this bug on last day of his employment. Quite a cool bug, I never know if Thomas was a bug or the guy who called Thomas a bug was a bug. Nevertheless, If you plan to report such a bug, please don’t quote me on that!

Jokes apart, let’s change roles for a moment as we become programmers. If you are entrusted with the responsibility of fixing bugs with bug summaries as above, what would your first thought be? Scratch your head or Trash them? Once, twice, thrice. If I were a programmer, I would trash not just the bugs, but even folks who write such bugs. And yes I am harsh, because every important bug that fails to catch stakeholders attention due to bad reporting is as good as a dead one.

Some of us might wonder “Oh! The product is so buggy that I have to report at least 20 bugs a day. With whatever little time I have, I can only make my bug reports shorter so I can write more bugs in a day”. My question to such testers is “How much are you bothered or not bothered if none of the 20 bugs reported this way are fixed”. Don’t tell me “That’s not my problem”. Agreed that we are information providers and not decision makers. But are we really providing useful information? Just a thought.

Detailed Descriptions

“Why I need to login?”

“search for item, I got script error”

“when my transaction failed, link to database cannot establish”

“in payment by debit card the bak name is choosen from the drop down menu , after that there is no requirement in the gateway page to ask the name of the ‘Issuing Bank’”

Don’t be surprised. These are real descriptions of real bugs. In other words, "Steps to reproduce" if that is the word your organization uses. At first sight, it might look like I am making fun of all those non-English speaking testers who confess openly about their lack of good English writing skills. Bug reporting is much more than knowing English well. Can’t we just look back and read/re-read the bug before hitting the submit button? Is that so hard?

“What’s the fun in detailed reporting? Am I so jobless to type tons of information for every bug I report? Can’t programmers figure out such a simple thing? Won’t my expertise go away if I gave all this information out for free? Let’s be honest - I struggled a lot to get here and find this bug, why should I give away information just like that. Let people come back to me, I’ll tell them and I’ll tell them only if I like them”

Some descriptions are so painless. A simple copy/paste of the bug summary. It’s as though the bug reporter was held at gunpoint and asked to report a bug one last time before giving away his life forever and ever. Or maybe his bowel movements didn’t permit him to do so in the time available for him to rush from his desk to the washroom. No offense meant – frankly it’s that annoying to read bad bugs to figure out what’s going on. Total waste of time.

Attachments

We have many free tools to take screenshots, many more to capture videos and above that, we have the freedom to attach logs, xmls, data files, test files and lot more options to help with bug investigation and fixing. Again, the same old question – who has the time? We don’t want to provide anything until the bug goes to “Needs more Information” state. And we would be offended if it’s moved to “Invalid” state, all this for no mistake of folks who read our dead bug reports.

 Reputation Points

Rajesh filed about 22 bugs in 2 days timeframe while Anil who was testing the same module reported only 4 bugs in same time. Both have 6.5 years experience, both are from computer science background, both should be filing at least reasonably equal number of bugs. Hence, Rajesh is a better tester. Till now, not a single soul would have looked at the following factors:

1. Bug reporting skills

2. Investigation skills

3. Ability to provide detailed information so that programmers don’t float between the bug and the bug reporter to get additional information
4. How many bugs are valid versus invalid?

5. Questioning skills (No, not the “why I need to login” type of bugs)

6. How many of the bugs reported did the tester get fixed finally?

All that mattered to the management was Rajesh has reported the highest number of bugs and he should be given the ‘Star Tester of the Quarter’ award in Q4 2010.

What a fishy method to earn reputation? Just because you are testing a buggy product or you find a bug every minute doesn’t mean you have to report bugs in a lousy way. Just because you want to beat your counterpart in the number of bugs reported as part of the bet you had with him or your manager rates you this way, doesn’t mean that you can stoop to any level of lack of quality in your own bugs.

If you are a tester, go back and read your bug reports as if you did not report it at all. Identify the gaps and work on those gaps by practicising writing good bug reports. If you are programmer who is annoyed with your tester’s bug reporting skills, tell them politely about what basic information you expect instead of running to his desk every 5 minutes which wastes not just his time, but yours too!

I recently met up with a CTO of one company whose product was tested by a bunch of testers outside his organization. When I questioned him about what he thought about the bugs reported by independent testers, he just said one thing, “Each time I read the bugs reported by these testers, I often wondered - why aren’t our in-house testers reporting bugs this way…….. " And he kept scratching his head for the next 30 seconds after uttering this. I felt a lot of pain in what he said. I wish he goes back to them and politely tells them that they need to improve in their bug reporting skills.

Happy Bug Reporting,

Regards,
Parimala Shankaraiah

What does your Customer want?

Product Conclave 2010

I had the privilege of attending Product Conclave 2010 conference organized by Nasscom recently thanks to my organization’s sponsorship. Apart from the fact that I was nominated to learn about Cloud based services, all that the agenda said was that it was targeted towards entrepreneurs. And it feels good to think that you are an entrepreneur, isn’t it? At least, an entrepreneur in the future?

One really nice thing about this conference was the wide array of panel discussions and workshops spread over two days.  I happened to attend one such workshop on “Building Great Products with Inspiration and Rigor”. What struck me at the end of the workshop was how stupidly we as engineers build products by thinking less about the customer and more about the profits we need to make.

Goal of the Workshop

You need to design and build the best pet possible in a competitive market. Your goal is to make more net revenue in units than your competitors. The team that has made the most units, not necessarily sold the most animals, will win the competition. Legos will be provided to build the pets.

Strategy

Our team was a complete set of strangers including a senior manager, two entrepreneurs, one marketing person, two directors of a startup, a developer and a tester (Me!).   For a moment, I felt like the worst nerd in the team and being the worst helped me as you’ll find out in a while.

The senior manager and the developer suggested that we break into two teams: Core pet building team and the revenue team. Pet building team started building the pet based on the specifications given to them while the revenue strategy team started working out the pricing detail. We would have 3 iterations to build the pet. At the end of each iteration, a record number of 24 customers would walk by for a demo after which they would decide to buy or reject the pet.

Lost Once, Lost Forever               

At the end of first iteration, we were ready with a sexy pet we called ‘Pet-O-Smart’ – an alien dog which is not just a caring pet, but also acts as a robot to entertain the pet owner [This is just a simulation, remember?].  When the customers came by, our team collectively decided that we would not sell the pet yet as we thought it wasn’t fully ready. Our pet needed some more development while the revenue team was busy working out the pricing based on the market research we bought during first iteration. Some customers found our partially developed pet very attractive to buy, but were disappointed with our decision not to sell the pet yet.

Lesson: Customers who visited us at the end of 1^st iteration were not only interested in our pet, but were cash rich. There was a high possibility that they would have bought many pets at the price we quoted. We didn’t intend to sell at this point and we prided in that decision as we heard cheers from other teams as they made their sales. It was a pretty bad decision for a reason. Even if we did not want to sell it, we could have demoed our pet to many customers (Campaign Management) and develop some leads (potential customers) for subsequent iterations. We lost some customers some of whom never came back because they were offended that we drove them away.

Conservative – May Buy

At the end of second iteration, Pet-O-Smart was fully ready for demo and sale. We priced it at 61 units per pet. First customer came in and all that we did as a team was surround like ants around a sugar cube and confuse him with all sorts of data of what it doesn’t do. We highlighted how our pet does bite now and then, but it’s harmless. Customer got angry. Another customer was driven away knowing our pet barked.

After a little retrospection, I informed the team how we were talking less about the positives and more about the negatives of the pet which forced the customer not to buy our pet. I took the lead in demoing to the customers henceforth. The approach I used was simple: Focus and highlight all the features and advantages in the pet. Don’t even mention the negatives. It went well. Some customers were smart. They asked ‘Does your pet bite?’, ‘Does it bark?’, ‘How aggressive is your pet?’ In addition to answering these direct questions, I also highlighted how our pet was harmless and could be child friendly for kids to play with. Impressive. We sold about 5 pets after 2^nd iteration.

Lesson: We thought we were smart. Some customers ended up asking key questions like ‘How many legs does your pet have?’ When our answer did not meet their requirement, they simply walked away yelling ‘Oh! This is not what I am looking for’.  For some customers, their requirements did not match ours.

I wish it was a little Cheaper

To spice up the whole workshop, we were not told about what the customers expected from the pet. All we were told was we had to answer customer’s questions and based on that we had to build/re-build our pet. How insane? We don’t get to talk to our customer about a product they want? Sounded foolish. But what about customers whom you don’t even get to know about in your lifetime, but still may be potential users of the product.

In spite of being warned that we are not supposed to ask questions, our team started drilling information from customers based on their reactions, their body language and sometimes even their comments. Some of them provided valuable information for us based on which we changed our design a bit and repriced our product at 57 units. And our sales increased by another 3 pets.

Lesson: At the end of third iteration, we met up with many customers who were interested to buy our pet, but were falling short of money. This is when we realized that we shouldn’t have driven away customers after first iteration when they had the most money. We did not adapt quickly. We took time not just to build the product, but to market it as well. It cost us a few more sales deals.

Our team stood 4^th in the total number of sales made, but that’s not the point. The point is where we faltered. The whole idea of the workshop was to identify those failure points and learn from them. And we did.

What does a Customer want anyway?

Customers are of prime importance.  Engineers have talent, Customers have money. Engineers build products; Customers are ready to pay for them. Some customers have rich cash flow, some are conservative in spending, but they don’t mind investing once in a while on products which will profit them and some customers are desperate to buy your product, but they just don’t have the money. There are all types of customers and it's important to study them and the markets they cater to in order to build products that are suitable for them.

Customers doesn’t need an infinite number of features in the product to make them look super cool in a room of a hundred people at a conference. They’ll be happy with a single feature that can touch lakhs of people’s lives and make a difference and of course, fetches a reasonable profit in turn for their hard work. Is that so hard?


Regards,
Parimala Shankaraiah

Wherez my Cappuccino?

I am Back!
I am back or should I say tentatively. I have been focusing on my personal priorities and a couple of releases both at work and home  :-). Hence hectic. As I type this, I know that it’s all crap! The reality is I haven’t been able to focus for a while on the stuff that I am passionate about. And consequently, several excuses follow. Finally, I thought today was the day to start over again.

Morning Cappuccino
The first thing I do in the morning when I get to office is to head to the pantry to get a fresh cup of coffee. It’s not necessarily ‘Fresh’ as it comes out of a vending machine. However, machine coffee is better than no coffee especially during rainy and winter seasons.

Given a small organization like ours, there are just a handful of employees who come in early to work and are potential coffee drinkers - one of my colleagues, Director, VP and myself. Among the four of us, my director and I have coffee pretty much first thing in the morning even before checking emails. Why should you know about who drinks coffee or not?

Here’s the story. On some days, I reach office before my director does, hence being the first one to use the coffee machine. When I select "Cappuccino" on the coffee vending machine, milk pours over and coffee follows. That is the expected result. Isn't it? On some days, I prefer tea. On all days that I select Cappuccino the first time, I see that only milk pours over, but coffee doesn’t. If you were me, you would end up feeling guilty for wasting one full glass of milk which is a potential savior for under nourished kids in several parts of the world. Keeping emotions aside about what happened to the milk which failed to transform to Cappuccino, if I selected Cappuccino second time, I would get coffee – milk followed by coffee. Hurray! I would rush back to my seat to check my emails as I sip coffee with a lovely view of busy morning traffic of which I am not a victim as I walk to my office.

One fine day, my colleague Selva ended up early in office. Incidentally, Selva opted for coffee. He was frustrated when he got milk inspite of selecting Cappuccino. I was like “Oh, Selva. If you didn’t know, you don’t get coffee the first time. You get it the second time”. Now, Selva had already gone nuts because I had demonstrated the elevator bug a few days ago. He replied with his trademark smile “Are you kidding me?”. “Ok, check it yourself”, I replied as I washed my mug.

Every human being is a tester by birth. How skilled he/she is varies. Selva went on and tested the flow himself and figured out he got cappuccino the second time. Selva burst out laughing as we discussed about the fun involved in finding bugs on live systems be it the elevator, coffee machine, music player on the cell phone or even the appliances we use on a daily basis.

Background

Cappuccino doesn’t like first time user [Assumption 1]

What happened when I selected cappuccino the first time ?
How did it work second time?
Does it work the third time?or
Does it alternate its behavior?

Questions. Being able to ask questions. A true boon to testers.

With good intentions to save electricity, the housekeeping guys switch off all the appliances in the night once all the employees leave office. This includes the refridgerator, microwave, coffee vending machine, hand dryers and lights. Every day, milk, butter, cheese and other supplies that need refridgeration are bought typically lasting for not more than a day. At the end of the day, most of it is over if not all and hence refridgerator can be switched off.

The coffee vending machine is cleared of the contents as well [Assumption 2]. The milk container is emptied, washed and dried. Water dispenser is disconnected and the machine is switched off. Coffee beans continue to remain in the coffee dispenser. Next day morning, fresh milk is filled in, water dispenser reconnected and the machine is switched on.

When a first time user (on that particular day) selects Cappucino, it takes a while for the system to start up Since the user won’t wait that long and selects Cappuccino, as the milk flows, the coffee beans container is not yet ready to supply coffee beans [ Analogous to logging into a machine where the system starts applying basic settings for that user]. End result – milks flows out minus the coffee. By the time user is ready to select second time, coffee beans would be ready to disperse. So, the moment cappuccino is selected, milk flows, followed by coffee beans drilling down from the container eventually followed by coffee.

What happens third time? Once cappuccino flows out second time, it will continue to work consistently without any hassles. Now, what if the machine is left unused for a couple of hours contrary to overnight time of 8 hrs)? Does leaving the coffee vending machine idle and unused render the same state similar to switching off the machine overnight? May be. May not.

Find the culprit - He must be elsewhere too!
If a typical night break between switching off the machine to switching it on is say ~8 hrs, we can try to reproduce the issue without switching off the machine as well.

Keep the machine switched on, but leave it unused starting with 5 minutes
Select Cappuccino and check if coffee arrives
Keep trying every 5 minutes until you hit closer to 8 hrs of idling to reproduce the problem without switching off the system.
Stop when you are able to reproduce the issue

The above approach would tell me if similar behavior is observed in other situations as well

Nail the Problem
Now that the problem is reproducible consistently by first time users everyday, it’s important to isolate the problem and investigate further.

States of the Coffee Beans Dispenser
Initial State after the machine is switched on
State when the machine is on, but has been idle for ‘X’ units of time
State when user presses/holds down Cappucino option
State when user releases Cappucino option
State after the user releases Cappucino option

Dismantling the coffee vending machine and watching over different aspects of its functionality would help me determine above listed states and corresponding behavior of the coffee beans dispenser. This would have provided additional clue as to why the beans were not getting pushed to the grinder interface on first attempt. How I wish this machine was at home? Not to mention the cell phone charger I recently damaged in the name of testing and troubleshooting.

Making and breaking assumptions

[Assumption 1] – Cappuccino doesn’t like first time user
I do not really know if anyone other than IT employees like housekeeping guys, receptionists use the coffee machine before me or some other first time user. It’s an assumption I made because on days when I have come earlier than the housekeeping guys, I have switched on the appliances myself though I would wait for them to fill up milk and other supplies.

[Assumption 2] - The coffee vending machine is cleared of the contents as well
Above illustration of cleaning a coffee vending machine is my view of how it is cleaned and may not be the professionally correct way of cleaning it. This is again based on my observations of how they are cleaned when I worked on a couple of weekends.

[Assumption 3] – The problem lies with Cappuccino option alone
I did try a few dry runs while reproducing the above problem with other options like tea , milk, espresso, latte, water and others. I used MFAT (Multiple Factors at a Time) heuristic and got a lead that this happens for Cappuccino only. This was an assumption because in depth testing of other options might have given me more hints about the problem behavior.

Listing down my assumptions about the system, environment and the type of users (myself, Selva and Giri) helped me to evaluate my understanding of many more parameters within the system. If I proved or disproved my assumptions based on the facts/information I was collecting about the system, I would get closer to the root cause of the problem.

Yet another First Time User
The other day Giri, another colleague of mine came early to office. As I entered pantry, I heard Selva talking about the "Cappucino bug" to Giri. At least, Selva was glad that he was not the first user that day. It was Giri’s turn to crib. And he did

Giri gave a quick fix for this problem. He looked at me and said “Parimala, I’ll fix this bug. Look. If I shake the coffee bean dispenser” moving his hands harshly over the dispenser, “I’ll get coffee”. I asked “Giri, have you unit tested it?”. He said “Yes. I am doing it right now”. As he selected Cappuccino, only half the amount of milk poured out and coffee never arrived. We had another round of laughter when I said “I reject your quick fix. Your fix not just fails to fix the problem, but has introduced a newer problem”. Giri’s fix failed buddy testing and consequent regression as well. He has promised to work on the fix someday. In the meantime, I was telling Giri and Selva how much fun it is to play with live systems and investigate problems. If you have not forgotten, the coffee machine is not owned by me. I would have loved to dismantle the entire system to see how each component works - be it milk container, milk pipe, coffee beans dispenser, grinder inside the vending machine, water flow and many others. But, if it stops working completely after my real time investigation, I might have to refund the cost for replacing it. Do you see a connection here? How often do we stop investigating bugs to avoid witnessing further failures?

I’ll end the investigation halfway while I wait for the monthly maintenance engineer to arrive so I can pair with him on this problem while he opens up the vending machine. For now, we continue to use the same coffee vending machine while many more testers struggle to understand how their Cappuccino disappeared.

Regards,
Parimala Shankaraiah

The Testing Planet

A long pending blog post!

Feb 2010 saw the birth of a testing magazine from Software Testing Club (STC). It was an awesome magazine with lots of cool stuff from context driven testers across the world. Be it the nail biting moments of doing the right things at the right time or laughing at cartoons and making fun of oneself, it was truly Awesome! It struck me very late that I could have written one too without thinking about acceptance or rejection. I was late.

Tomorrow never dies. STC had started collecting articles for July 2010 magazine. I thought I should write one, but wasn’t really sure if it would work given my hectic schedule and health. I wrote one which eventually became a blog post as it did not go well with the spirit of the magazine. I churned out another one in a short span (record time!) and sent it to Rob Lambert without any expectations. A week later, my article was in!

Three pleasant surprises in the second edition of STC magazine. One, the magazine has a name “The Testing Planet”. Two, the magazine came out in newspaper format. It rocks. Three, the magazine was on print!

You can download the July 2010 magazine HERE

The first edition of STC magazine can be found HERE

High fives to the STC team - Rosie, Rob and many others for amazing team work!

Read and Rejoice!

Regards,
Parimala Shankaraiah

An idea - that can ruin your credibility and sometimes your career!

Recently, I opposed giving written tests for interviewing testers for hiring few testers for my team. I screened resumes, I shortlisted people from non-computer science backgrounds, I opted for people with tech support experience, I did many things the unconventional way. I experimented a bit with the hiring process as I have “some” power to suggest changes to the existing process or so I thought.

When it came to selecting candidates for 4 vacant positions out of 35+ candidates, the easiest means of evaluation was a written test. When I suggested that we give a sample program to test with a mission, evaluation took centre stage. “It is hard to evaluate subjective tests”, “it’s easy to give multiple choice questions”, “we don’t have so many people to evaluate the test papers”, “In testing, since there is no one standard answer, we might not be evaluating the test papers uniformly hence resulting in unfair evaluation” and many more. Atleast, I was given a chance to suggest a program. A rather small win, but a big one for me.

Once I finalized on a program (with due credits to the program author) and came up with a list of bugs, I sent it to hiring team for review. They had enough time to build their own impressions about the program. When we met, it was a completely different scenario. I was so delighted to know that many of them had found some bugs in the program already. Awesome. Isn’t it? May be, not so awesome. Some of them had memorized the bug list I sent rather than executing the program. Ah! The same way that our educational systems have trained us to learn – by rote.

Mistake 1: Give them a problem and give them a solution. Why will anyone think about solving the problem? There was this big fight over how dirty the program was and how it did not help find any logical bugs. All it had was UI and usability bugs which we anyway live with, sometimes for the entire lifetime of the products. This was the collective opinion from the group.

Mistake 2: I was offended when people made fun of the program without testing it on their own. The general consensus on the program was that it is too easy to test and hence should not be considered for testing testers’ skills. How easy it that? Easy compared to what? No answers, just reactionless faces!

Mistake 3: When a young orphaned QA team (without a QA Manager) handles the hiring process and a couple of Dev. Architects and managers take over the process of leading such a process, it’s harmful because it becomes an exercise of rating testers versus programmers. Though our Dev. Friends were kind enough to help us with the effort, it was hard to convince them that the chosen program need not look complex and can appear to be easy, yet help us rate testers based on their skills.

What next? Here is a testing questionnaire that could be given for testers (as if testers didn’t know how to scout for such documents on the internet). I had the shock of my life when I saw some questions which was similar to asking someone “If given a chance, which eye would you poke? Left or right?” I am dead against (am I rude? Of course Yes!) such questionnaires and after a little struggle within the team, we came up with an idea to provide a problem statement/test scenario which candidates could solve on a sheet of paper. The next two days went in discussing whose problem statement to solve. Finally, one was chosen. The plan was to provide a problem statement and a mission for the candidates to test. All set for the big day.

Mistake 4: I did not mind the fact that something that I suggested did not work. I was angry and offended that it was made fun of across teams to an extent that the program was called a dirty little program. How mean? I failed to negotiate. I failed to show value of the program.

Biggest Mistake: Many testers who want to bring changes within the organization are nipped in the bud. It’s not necessary that everything be accepted, but one shouldn’t make fun of the effort some people take to come up with an idea. Such people who get frustrated over a period of time either become reputed system dummies or leave the system to become their own bosses (Independent Consultants). Trust me - you wouldn’t mind if a consultant you hired by paying a fat paycheck told you to use the same dirty little program to hire testers. You would have said ‘Wow’!

Whenever an employee comes with an idea, ask “How can the idea help us perform better? Why did the idea come from this person alone? Why not someone else? What is the value that a new idea can bring in? Can we make changes to make it better? Can we brainstorm instead of identify dents in the effort? Should an idea be encouraged only if it came from reputed employees in the organization? Can’t a freshman suggest something reasonable? Don’t new employees come with a fresh pair of eyes?” (A big sigh). Just question marks.

Have you observed how sugarcane juice is extracted? Once done, have you seen the leftover sugarcane? This whole thing about sticking to traditional hiring processes is like taking juiceless sugarcane and extracting juice from it by adding water to it for the next few decades. Are you game for following such a process?

Next time you suggest an idea, Beware! Be well prepared.
Regards,
Parimala Shankaraiah

Auditioning for a Tester’s Role – Part II

Part I witnessed some really interesting comments. If you think Part II will be a pocket book on ”How to Interview Testers”, then you may want to stop reading this post right now.

I interviewed one person on telephone recently where I asked him to test a marker he claimed to have in his hand. He was shocked, “What? Test a marker?” He intended to say “Do you mean I’ll be testing markers in your organization?”

What is the solution? By the way, what is the problem? Interviewers, Interviewees, Who else? It’s the system we have lived with for years without questioning. Ok, the system has worked for many decades. So what? Why not change the system? Why not try?

Why not audition testers?

Have you ever attended a music concert? Have you witnessed an Arangetram? Musicians/Artists/Actors – these people don’t interview for jobs. They perform - in real time. They AUDITION.

Volunteer to test in an interview. Ask for a testing mission. Ask for stakeholder requirements. Ask questions. Get your doubts cleared. Explain your test strategy. Execute your tests. Summarize your test results. Is this so hard? It is if you have tested one module for 3+ years and did not think of anything else at your day job. Think out of the box about what’s inside the box. Keep looking out to learn and explore. Challenge yourself before someone else does it to you. Challenge others to challenge you as often as possible. Write about your experiences. Learn from your mistakes. GROW with time.

If we claim to be passionate to test, why do we shy away from testing in real time during interviews. Why do we express shock when we are given a mission to test? Why do we say “I have never leaked a bug till date” when asked “What will you do if a bug gets leaked into the production code?” What are we scared of? Not getting a job? Not getting good pay? Good designation? How much good enough is the good that you are willing to have?

Never say Never,
Perform in real time,
Audition!

Regards,
Parimala Shankaraiah

Auditioning for a Tester’s Role – Part I

Suppose that you have a friend who asks you to interview a tester for your team, How would you do it?

Here are a few sample questions:

What is the difference between smoke and sanity testing?

What is the difference between verification and validation?

What is the difference between regression and re-testing?

What is the different between a product and an application?
…..

I can’t stop rolling my eyes for the last one though. I have worked on products all my life. Now, what the heck does an application mean for heaven’s sake. OK, I am a nerd.

Did you know that within Regression testing, there are 3 types of regressions. Ah! We don’t read testing books. Do we? “Testing for 9-10 hrs a day itself is deadly boring. And I tell you to read testing books again? After all, Testing is not a sexy sport” At least, I thank you for reading my blog. You are better than many of those ignorant testing souls who don’t read anything about testing at all. Or maybe, you are here to judge my work (a shameless grin!).

Objective and Subjective Tests
Give a written test to testers where all they have to do is select/guess the correct answer to get through the test. Some questions might ask you to list the scenarios to test or even find a few bugs in the login screen that is included in the test paper. Login Screen seems evergreen! It is as good as writing multiple choice answer exams by mugging up model question papers. Meet any tester today and ask him some definitions. There is a high probability he/she will mouth all the important definitions a.k.a. ISTQB style!

Losing good candidates
Go to any ****interviews.com sites. The testing questions are so common that anyone can learn them and clear the tests for a testing job. You may argue “We do have 2-3 face to face technical rounds to evaluate testers where they will be judged on their knowledge”. What about testers who failed the tests simply because they didn’t know the definitions you were looking for. What if they were extremely talented, inspite of not knowing some crude definitions? We don’t care. Good candidates will find a good job anyway, not our headache. Isn't it?

Selection Criteria
There is no doubt that we need outstanding candidates to work with. There has to be some criteria to filter such candidates: number of years of experience, list of reputed colleges, list of relevant degrees, marks they scored in 10th, 12th and graduation, the company they are currently working for, the maximum number of buzzwords in the resume (Automation, QTP, Windows, Unix, Mac, Java, .NET, Perl, Shell Scripting, blah blah blah), how much salary they are drawing currently, How far do they stay from the office (by the way, we expect people to work long hours!), Is the candidate married (if yes, they may leave office after working for 8 hrs. Worst case, they may even plan for a baby next year), Do they have kids? (they may decline to work on weekends) and many more. If the candidate clears this list and is still alive and patient to join the organization, he would be offered. Let me warn you, if you are a woman interviewed in India, few interviewers look for Mangalsutra and Toe rings to confirm if you are married or not. Amazing professionalism!

Round 1
If some candidate comes till here, he/she is extremely lucky. There will be another round of definition/terminology checking session. The first round is cleared as the interviewee knows the definitions including full stops, commas and punctuation marks. After all, he has attended about 35 interviews so far in 35 different companies. And to top it all, he has model interview papers of this organization as well. Obviously, he memorized a lot of stuff last night.

Round 2
Another interviewer comes along. He has an important release that night. In spite of that, his manager forced him to take the interview as he had to leave early to his home town (Smart Manager?). This interviewer is frustrated with his work, with his manager and now this candidate who came out of nowhere to make his life more miserable. Ask same old meaningless questions. Give him a tough puzzle which takes a long time to crack. While the interviewee starts working on the puzzle, this guy makes a phone call to his childhood buddy. Sooner the puzzle gets cracked, angrier the interviewer will be. However, the candidate is shortlisted for the next round.

Round 3
A typical managerial round follows. He would be asked similar questions as in Round 1 and Round 2. The interviewee is asked to solve the same puzzle that was given in Round 2. He is lot more confident this time as he knows the answer already. After all, this was the same puzzle discussed in the Hiring meeting recently (and the sheep present at the meeting followed it blindly without looking for new puzzles). Once this is cleared, its over to HR round and offer letter is issed. It’s all over.

The team believes that the candidate is outstanding, else they wouldn't offer to him/her. What if he isn't? What if he prefers monotonous work to challenging work? What if he is not interested to learn anything? Was he ever tested for some of these attributes during the interviews? Was there feedback of any kind flowing in from the first round to the last one?

As people who want to hire good people for teams, we end up finding people who are very similar to us. We fear to find the ones who can challenge our work and add value to what already exists as well as to what we do. Eventually, the team becomes a group of 'Yes Men' who hardly question anything.

What kind of people are you looking to hire?

Regards,
Parimala Shankaraiah

The New Famous Millionaire Rock Star Tester Dudette

Roughly a year ago, James Bach talked about my work on his blog. I rock on his blogroll too. Michael Bolton recently mentioned my name in his Follow Friday list of tweeples to follow in twitterverse. My blog got listed as 30th top software testing blog. uTest thought I am one of the top 20 tester tweeples’ in twitterverse. I got 2 articles published (as author/co-author) in last one year. What more? I am The New Famous Millionaire Rock Star Tester Dudette on the block!

I love to test. I like to mentor people. I motivate fellow testers to explore. I encourage many to experiment new things. I support people who fail faster and guide them to do so in a safe environment. I empathize with people. I answer questions. I clarify doubts. In return, I learn more from them than they do from me.

With lots of regards to my blog, I have done crazy stuff. I have written good posts, some bad, some worse. Some that people would remember for next few years etc. Should I write blog posts that increase my traffic or that help change the way a few people think? Not just think about how I write, but about what I write and how it can bring a good change in the way they work.

Interestingly, even if I haven’t posted anything in a while, hits to my blog remain pretty constant. Some colleagues discover my blog accidentally and speak highly about it (blush). And I know you as my blog reader too. Do I really deserve this adulation? Honestly, I don’t know. At least, I didn’t ask for it consciously. When the adulation did arrive, it gave me goose bumps. It got me excited and happy. When you do little things without any expectations of end results which somehow turns out to be a great deal for others, your joy will have no bounds. Adding to this, you’ll think of achieving lot more and travel to areas untraveled so far.

I haven't done many things. To list a few:
I have not attended many conferences forget about speaking at some of those prestigious ones.
I have not written profusely in public. Don’t even ask about writing a book.
I have not networked enough on online testing communities to suggest ideas and solve people's problems.
I fail to work closely with my colleagues to suggest good things at work due to lack of good negotiation skills, perseverance and patience.
At times, my ego costs me a ton!

Recently, one person commented on why an upcoming tester like me gets included in an elite list of testers on a reputed public forum. Some people question my existence on the Influential Women tester’s list on STP magazine January issue. Tomorrow, many may question my credibility. Did I ask for this? I didn’t. I am fine with criticism/ridicule/banter or whatsoever you want to call it. It's fine because people who comment are the ones who have not seen me test or work in general. If colleagues who work with you everyday can mistake your intentions and take you for a ride, think about people sitting millions of miles away witnessing flattery about you. And I am fine to say I don't rock at testing yet! At least, I have the courage buddy.

I am yet to travel a lot in my Testing Journey. I have a long way to go. I am not breaking my head thinking about the destination or how I would be when I reach the destination. All I am doing right now is enjoying my journey. If something good comes my way and this helps me do better things by reaching out to more people, I would grab it anyway. But I would not ask for it explicitly (And yes, I have had my lean days too). The whole ‘getting famous’ thing gets as controversial as match fixing in cricket matches because people seem to have problems with upcoming testers since these testers have neither spoken at a conference nor written a book. Simply because they are not famous enough yet! Is that it?

I am glad it’s a small world and I am facing these things so early in my career. It keeps me grounded (I won’t use the word humble). There’s a lot to learn, there’s a lot more to achieve, there is so much I need to do if I want to be that something that I want to be. As a newcomer, I have my fair share of struggles to fight against. Challenge me, but don’t make fun of me. Even if someone did, I’ll take that person as a godsend not because I am philosophical, but because that person is helping me grow. In some way for sure. Thanks to that person, I would be facing rough waters very early.

I want to be a Change Agent in testing. I don’t care if I am famous or not. I don’t care if I’ll be rich or not. All I want is to be a small seed that can grow into a tree and spread its wings so that many testers like me come out in the open as people with tons of pride and self-esteem about the Testing Craft.

And yes, for the change agent that I want to be, I am definitely The New Famous Millionaire Rock Star Tester Dudette “Already”.

Regards,
Parimala Shankaraiah

Inferno around Designations

Appraisals are underway in most organizations. Some of us are hopeful of a raise. Some of us are hopeful of a promotion. After all, we stuck to our guns (the organization to be precise) during the deadly recession. We have executed the responsibilities of an engineer one level up, but our designation rots at one level down. Or so we think. Our friends/batch mates in other organizations are already leads/managers and making lots of money while we still struggle to make ends meet in terms of money as well as the roles we play hiding behind designations.

As a college-goer, I kept staring at Infosys/Wipro/TCS buses and the employees’ access cards on many days as I waited for my bus. I dreamt of finding a job (just any job) for gaining good experience as a fresher. I also dreamt about how I would be promoted to the next level as Senior Test Engineer after two years. I also imagined that by the time, I have like 6 years experience in testing; I would be a Team Lead. And then, obviously I would become a manager in a couple of years. I relived this dream each day until I became the CEO of some company with the fattest paycheck in the family. I was mostly amused with the idea of being a role model to all the younger kids in my family. Till date, it has been just that – a dream.

To the best of my knowledge, higher designations are awarded as promotions to encourage outstanding employees to take on newer responsibilities and help the organization achieve higher objectives. Typically, they are given for people who are already acting in that role for a few years. Promotions also happen to uplift employees salaries if the money they make is too less for the quality and quantity of work they do. Promotions also happen when some key employees threaten to quit if they are not promoted with jazzy designations on time. Promotions happen also because some managers might think that it is one of the easiest ways to project that their team is an outstanding team. You never know. He may be expecting a promotion himself. 

What’s in a name? How does it matter if you are an Associate Software Tester or a Senior Software Tester? You might say “Money” and “Type of Work”. May be, you are right. If these are what matter to you, then why do you quit organizations because you did not get a fancy designation? Why argue over it? Why compare against others? Why fool yourself? As long as you are happy with the work, and get paid well enough, it should not matter what designation you hold.

I have seen designations create a divide rather than unify the teams. The entire concept of bell curve, normalization and foul play wrecks havoc to team spirit. Outcome – demotivated employees.  Some designations appear to give great power over others which are precisely the reasons why many want these high power positions. In this fight for designations, team members end up fighting, involve in useless gossip and encourage unethical ways to promote wrong people who rule from the throne as if they are the chosen warriors for fighting people’s war. As humans, we love money, power, status, position amongst others. In that journey, we sometimes fail to be human.

Are we a designation hungry generation? Why are we making a fuss out of it? Why are some people giving up great jobs just for designations sake? I know of a friend who quit his job just because he did not get designated his way. What I also know is that he was so much in love with the work there that he almost misses it at his new job. Letting go of great work for a fancy designation sounds very weird to me. Weigh down right.

Wake up guys!

Regards,
Parimala Shankaraiah

Ready to Rebel?

Matthew Heusser formed a group called the “Rebel Alliance” at the recently concluded STAREast conference. The Rebel Alliance attended the conference in a group, met up in Eric Jacobson’s Conciege Suite at night after the conference and presented or listened to great lightning talks. It takes passion to do such things.


Videos

Shmuel Gershon’s lightning talk on An exploratory test tool experiment where he demoed an in-house tool they built for assisting testing.

Matt Heusser’s The Software Practitioner Maturity Model where he talks about the testing education system (I would say!)

Justin Hunter’s talk on Combinatorial Testing and the Quadrant of Doom

Jon Bach’s talk on How Do you Think?

Adam Goucher’s lessons from the Pirates Everything I learned about Agile I learned from Pirates

Lanette Creamer’s talk on Herding Cats and how it can be linked to Team Collaboration


Exhilarating talks! There are so many passionate people out there who’ll bring out something useful and credible no matter what the situation is! And passion is contagious. It spreads and it spreads faster. It would be so cool to have similar alliances at our local conferences, get together and learn and share from each other. What does it cost? Passion is all that you need!

I am not familiar with STAREast conference though I have heard about it many times and read some articles here and there. But then, twitter made sure I was present at the conference. Well, at least virtually! It was fun to get all the updates live from the conference [I now understand why my husband is so fond of live cricket matches!]. Keynote after keynote, quote after quote, tweet after tweet, it felt nice to catch up with the conference this way. Twitter is magical. At times. Get on there!

Be Passionate,
Happy Testing,
Parimala Shankaraiah

Eight Manager Hats: Which one are you wearing today?

Sometime ago, My 3 yo asked me “What color is your manager?” I was surprised. I didn't know what to answer. For several days, this question kept lurking in my mind.

A few days later, I thought managers may not have colors, but could wear different hats (managerial styles). The hats they wear could make or break the teams they manage and even have positive/negative impact on entire organization.

The Destructive Manager hats
The Micromanager hat
The Micromanager is always in control of every project executed by his team. It could be as simple as an email sent to a programmer who sits a cubicle away. He would in fact want to review every email before you send it. He loves to micromanage, at least that is what he thinks he is hired for. He keeps a log of non-company websites visited by his team, so he could get them blocked by the Admin team. He often reminds the team how the organization has given lots of freedom (read as free internet access including job websites, ability to chat on Yahoo or Gmail, play games etc). Yet, he says that you are abusing (yeah, abuse not misuse) the facilities given. He will say that his team is the richest team in the entire organization based on the number of machines given per person! He himself does nothing than pushing emails from one person to another. He won’t read his emails 99% of the time. He expects people who sent emails to remind him to read the emails they sent. A typical email from a technical support guy (via his manager) takes about 2.7 days to travel to his team member. The team member is supposed to give an update in 2 hrs time (total execution time was 3 days!). He MICRO MANAGES until the team member finds a better option or moves to a different team.

The Torturer hat
The Torturer tortures the team because he thinks there is no better way to get things done effectively. He tortures not just his team members, but also other teams and its managers. He has a loud rude voice good enough to be heard clearly from a large football stadium. If you don’t wish him Good Morning, he will come to your cubicle and stare at you until you stand up and wish Good Morning. Followed by this, you will be invited to his cabin (the Gas Chamber) to teach you about “How to respect your manager”. He is proactive in taking decisions related to projects scheduled in the next one year – all this without thinking about the new customer escalation that just came in. He says ‘I know what is best for the team’. On some days, he leaves office very early only to come back 20 minutes later to check who else in the team has left. Next day, Gas Chamber awaits the person who left after he left, but did not come back after 20 minutes. And the TORTURE continues……

The Divide and Conquer Manager hat
The Divide and Conquer Manager confuses simplification for divide and conquer rule. He’ll call each team member individually and tell them that they are one of the top performers in the team. Post hike cycle, he’ll even tell each one that they have got maximum hike in the entire team and hence should not reveal it to anyone! And the bakras (as we call it in India meaning fools) give in to it. Divide and Conquer managers will not like it if the team is united. He won’t like it if two people from his team are good friends. He won’t like it if two people are working closely to get a common problem resolved. All he wants is people work in silos as this will give him a chance to prick on their weaknesses and overlook their strengths. If you have improved in the last one year based on the feedback you received the previous year, he will not even acknowledge it. ‘Big Deal! You did what you were told to. Maybe, if you did it right the first time, I would appreciate that.’ And by the way, Divide and Conquer manager will CRUCIFY you if you fail!

The Selfish Manager hats
The I, Me, Myself manager hat
The I, Me, Myself (IMM) belongs to an irritating breed of managers. An IMM manager always puts himself ahead of the team. Instead of leading from the front, he keeps running ahead while the team struggles to come out of the trench. He appears to be supportive of his team’s actions in weekly team meetings, but in front of other teams, he speaks as though he disowns the team. He makes the team feel orphaned whenever he really had to stand up, fight for and support the team. After goofing up, he will schedule urgent meetings during lunch breaks to apologize to the team that he behaved that way to please some people in the senior management. He lets people fail even if he knows that they are failing simply because he can put a red mark in their performance evaluation forms. He forces the team members to wear a yellow shirt with red trousers and a black tie to showcase team unity to other teams during Christmas/New Year party. In the background, team members would know that if they didn’t showcase unity, they would be accused of being loners and poor team players (-1 point on their performance evaluations). By doing all this crap, IMM manager would still have managed to give good impression about himself and how passionately he has been struggling to bring up such a DISINTEGRATED team to speed for the benefit of the organization.

The Passive Manager hat
The Passive manager a.k.a Yes Boss works from the safest place possible. Given any challenge, he figures out a safe way to hang in there without inviting anyone’s wrath. He is an excellent listener, yet hardly empathizes with anyone. He does nothing after listening to team’s problems, in turn starts whining about what problems he is facing from the senior management and how he is tackling them. He indirectly hints “Can’t you see how helpless I am. Why don’t you do something about it yourself? Hopeless fellows!” He is passive to an extent that he does not know how to communicate his own problems to management, forget about the challenges that his team is facing. He continues to be passive until all hell breaks loose by one incident which senior management caught attention of. This is when he puts his scary avatar of a responsible manager to use and starts yelling at his team on how it happened. After a day, he goes back to his passive state, calls his team and apologizes in public. After all, being EGO-FREE is good. At least, it does not give birth to new enemies.

The Helpful and Productive Manager Hats
The Provider hat
The Provider provides for what the team members need. He often provides only what he thinks the team members need, not what the team members actually need. It’s obvious that he thinks he is one of those good Samaritans who takes care of his team so well. He gets provoked when his 360 degree feedback says he has to improve in some areas. He takes examples of other managers who are supposedly bad according to him and hints at how good he is when compared to them. He stands up for the team and sympathizes with them, but does not emphasize. Many team members think about him like this: ‘He did not do X, Y, or Z appropriately. But, he is a very good human being’. He gets things done, but may not be able to RETAIN employees in the long run.

The Motivator hat
The Motivator motivates the team. “Work hard, Party harder” is his motto. Motivator gives you all that you need to be your best self to get things done better. He removes all the obstacles that block you. He might even pitch in to help you. He’ll not just sympathize, but also empathize with you. He will understand if a project gets delayed as long as there is a valid reason - more often, he respects reasons as valid. He will be involved in your project at every stage. If you don’t follow-up, he won’t mind. He will follow up with you thinking that it will save some time of yours that you can use to accomplish your task. He will buy you lunch and deliver them to your desk while you are busy working on weekends. He will not mind if you play Ping Pong to de-stress yourself during high priority releases. He leads from the front, yet keeps looking back to check if the team is catching up. He says ‘It’s OK to fail. But, learn the lesson’. He practices what he preaches. He MOTIVATES!

The Nurturer hat
The Nurturer nurtures his team. He truly believes in Team Work. He helps each and every team member grow based on their key strengths. He also works closely with the team by providing timely feedback about what is lacking within the team, what is the action plan and how to go about executing the plan. Nurturer brainstorms solutions to problems along with the team instead of pushing his decision. He puts the team ahed of everything and everyone including himself. He assigns tasks to the team based on their interests, skills and expertise. Nurturer does what is best in the interest of the team keeping his own ego aside. Nurturer is one of the best breed of managers who NURTURES not just teams, but organizations as a whole.

Wanna throw your bad hat?
With the advent of 360 degree feedback for managers and the annual performance evaluation cycles, it is highly unlikely that the senior management is unaware of the different hats (managerial styles) of managers within the company. It is up to the senior management starting from the CEO to take a call on how employees are being managed in the organization and check if its appropriate. The first few steps could start with as simple as assigning a mentor to each manager just like each employee would have a mentor (in most organizations). This way, it would be good to inspire and motivate managers to lead teams. Managers could be sent to leadership workshops (e.g. Problem Solving Leadership workshop) where they interact with other managers and discuss day to day challenges. Introducing incentives like gifting company shares, books, family trips, gift vouchers etc whenever a manager excels in the team will further encourage people to manage well.

If you are a manager who is wearing one of these bad hats, don't feel like a version 1.0 in a 6.0 world. Fight all the shy bones in your body bravely. Treat your team members as humans rather than resources. Consult your manager. Consult your team members in a group or individually. It could be in the farthest meeting room in your workplace. Ask for feedback frequently - once in a quarter has worked for my managers :). Weigh down pluses versus minuses. Work on the areas of improvement suggested. A few years later, you will become dust or shine elsewhere.

Manage yourself as a Manager. Manage your Manager. Today!

Regards,
Parimala Shankaraiah

BWST 2 - Great Learning Experience

Theme: Cutting (c)trap and getting good things done

Event Sponsor: Vipul Kocher

Venue: Shilton Royal, Bangalore

Co-organizers: Pradeep Soundararajan and Santhosh Tuppad

Co-facilitators: Pradeep Soundararajan and Parimala Shankaraiah

Image Courtesy: Rahul Mirakhur

Presenters: Sharath Byregowda, Selim Mia, Ashok T, Rahul Verma, Vipul Kocher, Dr.Meeta Prakash, Sukanta Bhatt.

Attendees: Swetha Ghorpade, Senthilnathan C S, Allmas Mullah, Eshwar Kumar, LakshmiNarasimha, Gokul Srivathsan, Dhanasekar S, Rayanagouda Patil, Vasu Swami, Rahul Mirakhur, Mandeep Singh, Ajay Balamurugadas, Ravisuriya, Yeshwanth Rao, Sai Divya, Chandrasekhar, Pradeep Soundararajan, Parimala Shankaraiah, Santhosh Tuppad, Sharath Byregowda, Selim Mia, Ashok T, Rahul Verma, Vipul Kocher, Dr.Meeta Prakash, Sukanta Bhatt

Peer Workshops

When I attended STC Conference a few months ago, I had mixed feelings about it with regard to the topics being presented, the length of the presentations, time allotted for questions and discussions post presentation, the speakers, the sponsors and many others. At that time, all I thought was this: "for hands-on testers like me, it would be too much business and very little testing stuff". Although it is good to know about the business aspect of testing, I was not interested to an extent that there was not much related to testing mostly. I had heard about peer testing workshops, read about LAWST, TWST, BWST and AYE in bits and pieces. However, I did not realize that it was in my good taste until I attended BWST 2 held on 3rd April 2010 at Hotel Shilton Royale, Bangalore.

How to Kill a Tester?

Sharath Byregowda, Co-founder of Weekend Testing wanted to present "How to Kill a Tester?" With an extremely hectic work schedule, he hardly had time to attend the workshop, forget about presenting at the workshop. He however made it to the workshop by clearing crappy traps. It was only ideal to get him to talk about his traps and the crap that followed it. It was only hilarious to see that he wanted to talk about How to Kill a Tester? and described how he almost got killed in the process! He talked about unrealistic schedules, short test cycles and subsequent stretching by testers to make ends meet. He also said he learned negotiation skills and being able to convey his concerns to the management assertively. Sharath also hit upon certifications and its associated challenges.

Sharath presented a good experience report in truest sense. He is one no nonsense guy when it comes to presenting. He was his usual self speaking truth to power!

Dangerous decision making - Assumption traps

Ashok T, Founder and CEO at Stag Software Private Limited talked about making decision based on meaningless assumptions. I was floored by the classic examples he provided to convey the message. At one point, he compared fungal cells versus cancerous cells in the body with defect density in the product. He asked ‘Is 33 diseases in a human body good enough to be healthy?’ with respect to metrics.

Ashok spoke in detail on the assumptions in test design, execution and assessment phases of testing and how decisions based on these assumptions were dangerous for the overall health of the product. He emphasized on the need for outcome/goal focused rather than activity focused results.

Benefits of applying Scripted & Exploratory approaches and Problems in Test Management

Selim Mia, a Test Manager came all the way from Bangladesh to attend BWST 2. He was the cynosure of all eyes at BWST 2. Selim started his presentation with how he used scripted and exploratory approaches in a complimentary way to test better. A lot of questions were thrown open to the audience to discuss. It turned out to be a little war of words with different people telling different things based on their own personal experiences. One of the participants said ‘Every scripted activity is exploratory in nature. Only freedom varies’. Selim asked key questions on test estimation, production environment, client specific issues and training challenges etc. He smartly figured out what were doing and comparing against what he does as a Test Manager himself.

Someone from the audience asked why the client did not do anything about certain problems to which Selim replied emphathetically "The client is blinded!" How true!

The Good, The Crap, The Plain Bull

Rahul Verma, Senior Technical QA Lead with a reputed MNC discussed the importance of critical thinking and evaluation for accepting/rejecting new ideas He talked how we testers victimize ourselves and project that the world around us is bad and ugly. He explained how what is good to us can be utter crap to others, ‘Your good can be crap or plain bull to others’ he said. ‘Tell your crap to yourself before others come and tell you’, he went on.

Another key thing was about Ideas. He openly announced how blindly we accept ideas without evaluating them. It’s like the sheep herd wherein we follow whichever sheep in front of us heads towards. We fail to evaluate out of blind trust or laziness. He said it’s ok to not have an opinion about something. It’s ok not to take sides when you are not sure about an idea.

All along Rahul’s session, I felt as if he had a hammer in his hand and kept on hitting on my head by sharing bitter facts about the way I am and the way I work. My head continues to ache! I need to change myself………Right Now!

Noun and Verb technique

Vipul Kocher, Founder and CEO at PureTesting presented Noun and Verb technique designed by Elizabeth Hendrickson. I had heard about this technique somewhere, but my lizard brain took over my humble goal of learning more about it. He talked about what this technique does, how it helps in coming up with test ideas for testing and also to deal with related biases while using this technique. Many participants had not heard of this technique and were interested in knowing more about it. Rahul Verma especially commented on how this technique is very helpful to him in reviewing requirement documents. Vipul added more by saying any technique should elicit more questions as it helps testers in testing the products better.

Yet another meeting ....Yet another talk !

Dr.Meeta Prakash, Project Manager at Infosys talked about crappy meetings and how valuable time at office goes down the drain. She classified meetings into many categories and went into details about how content discussed in meetings could be misunderstood or misinterpreted. She also emphasized on how paraphrasing helps in meetings. She briefed a bit about how meetings can be effective, how to learn to say no to wasteful meetings and learn the art of effective meetings.

Lessons Learned and Best Practices in Healthcare Imaging Platform Testing

Dr.Sukanta Bhatt presented a brand new viewpoint to Healthcare testing. He gave wonderful insight into day to day challenges in testing healthcare products and the traps in testing them. He gave great examples of how a missed bug can kill a person and how important it is to find every critical bug. Not to mention his hilarious style of quoting real life examples, he kept the participants in splits most of the time.

Sukanta elaborated on how UI design can be challenging for healthcare products. He emphasized on the importance of sociology and anthropology and their respective value systems. He also briefed about ‘Go to Gemba’ which means we need to get in touch with the real stakeholders to get products tested based on their needs.

Why only Bangalore?

The other day, Allmas mulled over the event saying 'You guys in Bangalore have all the fun'. Of course, we chose to have it. We created such forums for ourselves and it wasn't as hard as you may think.

We are hoping that there are some passionate people outside Bangalore to be able to create, foster & have consistent meetings of any kind. Learning is your responsibility and hence be responsible".

Want help in starting one of such groups, we shall be glad to help you help yourselves.


Token of Thanks

In the interest of time, I won’t go into the nitty gritties of each participant’s questions or the discussions that followed them. In short, it was one of the most useful workshops I have ever attended in testing so far. And yes, I mean it! The participants were the joyous lot who got a feeler of diverse topics on testing in one day. As Sukanta Bhatt summarised it "Years of Experience in hours"!

Pradeep Soundararajan's report can be read HERE

Thank You BWST 2,

Parimala Shankaraiah

Q-Patterns by Vipul Kocher

When I talked about Questioning skills a few months ago, I wasn't very clear on which tools to use to practice questioning [Of course, in addition to my brain]. Plenty Questions and Dumb Charades took me a step forward. I saw a downside to it. Some questions were lost, some were forgotten and others not important enough. This is where my Note-taking skill came in handy. As I made notes of different questions and grouped them under specific categories, I got many more which were interrelated or newer. How to manage this ocean of questions? How do I structure them well enough to solve the problem at hand? How many questions are good enough? This is when I remembered Q-Patterns that I had read about a few months ago.

Questioning Pattern (also known as Q-Pattern) is a set of interrelated QUESTIONS grouped together to:
         • Relate to some aspect of user or software requirements
         • Provide various alternatives to arrive at a solution

Vipul Kocher, Co-President of Pure Testing is the creator of Questioning Patterns. In his own words, "Q-Patterns is a great tool for communication of domain specific knowledge across people and continuous skill enhancement. It is also a tool for requirement elicitation and defining specifications".

Structure of a Q-Pattern

• Name of the Q-Pattern
• Intent/Explanation/Definition
• Classification
• Metadata
• Template Version
• Q-Pattern Version
• Author
• Author Contact information
• Keywords
• Questions on
• Usage
• User Interface
• Administration
• Performance
• Security
• Internationalization
• Localization
• Examples
• Associated Q-Patterns
• Specialization

Vipul’s Example of a Q-Pattern
Name
Password Management

Intent
The most general and common approach to authenticate a system or user is asking for a Password. Password authentication can be at different levels like user level, group level etc or at different stages like Operating System authentication, Application authentication etc.

Questions
If you are using Password authentication anywhere in your spec/design/code/test you may ask following questions:

Administration
1. Can administrator reset the password?
2. Can administrator's password be reset?
3. What happens If the administrator forgets his password (any default password is given or reinstallation would take place)?
4. Can administrator set the default password?
5. Can another administrator reset an administrator's password?
6. Can an administrator read the password of a user?

Usage
1. What's the maximum and minimum length of password?
2. Can we enter numbers in password?
3. Can blank password be used?
4. Where are passwords stored?
5. What is the default password (If any)?
6. Can one customize the default password?
7. Can Special characters (like #,$) and accented characters be used in password?
8. How is password change affected? Is original password required before change password is allowed?
9. Is Confirm password used?
10. Is `Save Password' facility there on the screen (so that user may not need to enter password every time she logs in)?

UI
1. Is password shown as stars (at the time of entering the password, at the time of changing or resetting the password etc.)?
2. How many stars are shown for a password
       a. When it is being entered?
       b. When it is to be changed? (Note: Do not show same number of stars as the number of characters.)

Security
1. How are passwords stored? Are they encrypted before storing? If yes what is the encryption algorithm used?
2. Whether the password is case sensitive or not?
3. Whether the password can be cut and pasted?
4. Can a previously used password be used again? If `Yes' then after how many changes?
5. Is there any expiry time for the password? What happens after the date if user does not change the password during that period?
6. Is there any policy to count the number of password validations in succession (e.g.. If user enters wrong password 4 times, then she is not able to enter password again in succession).
7. If application creates logs of all activities, then the logs of password are created or not?
8. If logs of password are being made then the password is stored in encrypted form or not?

Performance
1. Whether password is made up of single-byte characters (even if multi-byte character set is being used in the application).
2. How much time will it take to authenticate the user after the submission of password?
3. What is the maximum space required to store a password? Will all the passwords require same space irrespective of size?
4. If wrong password is given, how much time will it take to give the error message?
5. How many users can be authenticated at the same time?

Example
Various login screens and mechanisms (web based mail systems, console based login etc.)

Associated patterns
Access Rights, Error messages

Specialization
Say, login for any particular web based mail system.

Q-Patterns and Test Oracles
We find problems in software because somehow, the software doesn’t look quite right. How? Based on feelings, emotions, prior experience? with similar or different products? We build our knowledge base from our past knowledge and perceptions. Sometimes, our perceptions about the software could be wrong. Sometimes, how we desire the software should behave could be wrong. What to do next? Change the software OR the desire about software? OR change the perception about how software is used in general.

As I see it, Q-Patterns are based upon prior experiences and perceptions of people. It helps build a knowledge repository by asking appropriate questions. And this knowledge repository keeps growing as we learn more about the product every single day.

Q-Patterns and Testing Checklists
Once the Knowledge Repository (or the Question Bank) is ready, one can notice that answers to these questions transform into a Testing Checklist for that feature. Voila! I have interacted with few people who find it hard to shift from test cases to test checklists. I have faced this in the past myself. After using Q-Patterns for some time, I now see it as a tool to help me build my Testing checklist by answering the questions in my Q-Pattern.

Agreed, that it depends on the person's skills and talent at questioning. Questions may not make a robust list for a start. But, they can be evolved over time. One way to come up with more is to brainstorm questions with different teams and people. Another way is to get your questions reviewed by your peers or friends asking for feedback.

Q-Patterns and Test Coverage
The Questions section in the Q-Pattern template addresses what areas we are willing to address. The ones mentioned above like Administration, Usage, UI etc are just examples. We could add whatever suites the feature we have selected and storm ourselves with questions. Suppose, I am testing a call center flow of a CRM application, I would add Usability, Number of clicks to perform an operation and keyboard shortcuts as additional section [These in turn may/may not get covered as part of different Test Techniques if any]. There is no one Q-Pattern fits all solution. We need to come up with some basic patterns and build them over time. If we address all the features in the system using Q-Patterns and asking questions about each feature, there is a possibility to have covered at least important test techniques to test the software.

References
http://www.whatistesting.com/qpatterns.htm

Happy Questioning,
Parimala Shankaraiah

Serve your Stakeholder

Dr. Cem Kaner describes stakeholder as someone who has a vested interest in the success of the testing effort and/or in the success of the product. Stakeholders could be project managers, marketing managers, product managers, programmers, technical support representative, sales representatives, customers and many others in many different roles. Testing is done on behalf of the stakeholders. Here is a question for you. Have you ever asked who your stakeholder is before you start to test?

On a balmy Monday morning, I visited Weekend Testing site to read previous weekend's session reports. The battle of the URL shorteners lured me.

Mission
You are contracted by three stakeholders to evaluate URL shortening services - http://tinyurl.com, http://bit.ly, http://3.ly, http://is.gd, http://tr.im, http://stnx.at. The stakeholders are:
1. a heavy twitter user tweeting a lot of internet references over the day
2. a university student wanting to share stuff from his homework/courses over the internet with his fellow students
3. an online magazine publisher for referencing further readings on the internet

Experience Report
This time around, I did not jump right away to test and find bugs. This was partly because I did not know what information to provide and how. I explored all 6 URL shorteners and played around with features for a while. I was specifically looking at evaluating URL Shorteners on behalf of the stakeholders. Stakeholders were of 3 types – heavy twitter users, university student and an online magazine publisher. I went about with a small feature list of what I thought was important to the stakeholders. I chose URL Validation, Default Length, Auto-copy to clipboard, Proceed with URL shortening on same page, Custom Names & Validations and Preview. I identified just these as important features and ignored the others. This is where many of us commit mistakes [Remember, Assuming that we are the final stakeholders and claiming that all we say is right is dangerous].

Now that I had played with URL shorteners a while ago, I started exploring each feature and prepared an excel with details as to which shorteners support above features and which do not. In the end, I looked for the URL shorteners which supported most of the features above and concluded that 3.ly and Tr.im were the good ones.

You can read my summarized report HERE. You can also learn from few more reports at Weekend Testing EWT 04 session.

What went right?
1. Exploring URL shorteners one by one without being lost in finding bugs
2. Came up with ideas to test for each stakeholder requirement separately. I would say this was a good start
3. Came up with a feature list to compare the URL shorteners against each other and evaluate. This approach was good
4. Captured test results to the best of my knowledge and provided good enough information to stakeholders or so I thought.

What went wrong?
1. I did not use Google effectively. I could have googled about URL shorteners in general and fetched more information about other important features
2. I did not think deeply about the stakeholders categories. For e.g. what type of users are heavy twitter users – what are the important features that matter to them? What do online magazine publishers emphasize on while using URL shorteners? What features would be helpful to university students? As a result, my test coverage was very restricted and narrow. Rather, my test coverage was restricted and narrow, hence the result. Do you see the difference here?
3. I failed to summarize my findings with respect to each stakeholder. All I did was to prepare a generic report with my findings. I had started out with an intention of testing for each stakeholder differently and separately. Though the approach was good, I got lost somewhere and failed to identify many important features like Twitter integration, Shelf life of generated URLs and others.
4. Poor reporting yet again – one of my most common mistakes in uncommon situations. I did not present the report in a way that each stakeholder would be able to fish out information from. A generic report like this may not even be worth a glance. In short, it did not show anything useful for the stakeholders.
5. If only I had tried to ask each stakeholder what they wanted directly [assuming they would answer back for their own good], it would have been a lot more easier. In this case, asking questions meant I should have listed down what was more important to each stakeholder and tweaked my findings accordingly in the summarized report.
6. My conclusion that 3.ly and Tr.im were good was completely baseless. The conclusion varied for each stakeholder based on what was important to them which I hardly focused on.

Identify your stakeholders
We often ask our immediate bosses, colleagues and other team members about the stakeholders directly or indirectly. Some times, they don't know. Sometimes, they do. Irrespective of this, it is good to identify the targeted stakeholders for the products/applications being tested and come up with features that matter to them the most. After all, we need to find important bugs quickly contrary to finding all bugs which hardly matter to the stakeholders. Ask who the stakeholder is, what is the information they are looking for and what are the risks that they want to mitigate at any given point of time? (taken from Dr.Cem Kaner's article which escapes my memory right now).

Dr.Cem Kaner opines about understanding stakeholders in Weekend Testing session 20 as follows:

To test any product related to drug submission to FDA, SOME TESTER ON THE TEAM SHOULD mandatorily should have knowledge on the drug submission process. No one is responsible for my ignorance of quantitive trading systems but me. In the United States, over half of the stock trades are now driven by automated trading systems rather than by humans. If I want to understand how the market works, I have to understand the trading
system. If I want to test models of the market, I have to understand the range of tradings systems. If I want to test the models underlying a specific trading system (one of the things that distinguishes a high quality trading system from a low quality one is whether it makes money for the people who use it, yes? So assessing the quality of the system requires assessment of its probable value to users, which is often done in highly-detailed simulations)--If I want to understand these, I have to educate myself. If I am unwilling or unable to educate myself about these, I should test something else. If I am more generally unwilling or unable to educate myself about a product domain, its risks, and how to assess a product in that domain, I should give up on testing and do something easier that requires less learning.

Serve your stakeholder diligently,
Parimala Shankaraiah

P.S.
Ever since I created Testing Fiesta and Defects Fiesta sections on this blog, I have only dreamt about growing these 2 gadgets and hence accelerate my learning. My 7 day work weeks screwed it up and continue to do so for many more weeks. If at all, I do get time, I run back home to play with my 3 yo. If at all, my 3 yo sleeps, I go to sleep as well thinking it’s high time I take some rest. All lame excuses! I’ll start blogging regularly from now on. Keep visiting. Thank You.

Dear Readers - I owe it all to YOU

Curious Tester was born exactly 1 year ago on this day. I had created a blog page around February 2009 and did not know how to start and where to start. I was pondering over this for quite some time until I came across a blog post 5 Questions for Pradeep Soundararajan on Philk's blog. A few hours later, I got an email from Pradeep as follows:

Hi Parimala,
I found your blog with no posts. No matter how ever short it is, I would want you to consider posting your experiences as a software tester.

One of the important things to consider when you start blogging is - first do it for yourself and if others are reading it, fine.

Pradeep Soundararajan

At the time, Pradeep hardly knew me or so I thought. I was following his blog as a silent reader. I was literally in love with his blog posts. However, I did not know how he got to know about my blog – an empty blog, a blog with no posts on it.

Foray into Blogosphere
I can’t quite describe my experiences in last one year in a single post. I started blogging. I was quite a failure in writing, I must say. However, I wanted to try. I wanted to try because I didn’t want to regret about not trying. I started with a ‘1 post per month’ goal. I did not want to post theory from testing books. I did not want to copy someone. I did not know how to be authentic and original. As long as I liked a blog post, I posted it though it made me very nervous many a times. I even joked to myself 'Pari, nobody is going to read your blog anyway'. This went on for a few months and here I am in front of you.

Side Effects of blogging
Blogging is contagious. I attended Pradeep’s and Michael’s workshops, made it to STC 2009 conference, networked with many testers who were as passionate as me about testing, co-founded Weekend Testing with a group of friends, attended BBST foundations course, got an article published in print for the first time etc. This is what you can see from my blog. A lot happened behind the screens. I realized how poor I was in testing, how pathetic I was in technical knowledge and skills, how hopeless I was in many other skills related to testing (Lateral/Logical thinking, Investigation, Observation, Speaking, Note taking, and Presentation etc).

At times, it was painful to see that my passion for testing was not directly proportional to the quality of testing that I used to do. The good thing is I now know where I am failing (at least some of them). Another good thing is I can work on those areas. All along this journey, there was one person who made the greatest difference to me and my blog. You may know this person for sure. It's YOU!

Token of Thanks
I am really glad that YOU – My Dear Reader made a very
big difference in my journey of learning to be a better tester. Thank you very much
for reading my blog, supporting my work, commenting on my work, criticizing me
and helping me grow. It feels so great to know you care for me, my work and my
writing. Once Again, Thank you very much. I owe it all to YOU.

First Anniversary Gift
Trust me. Blogging is hard. Keeping oneself up to date is hard. Learning is hard. But then, what is easy in life? Take it from me - Nothing comes on a platter. You’ll have to work hard for whatever you want to be in life. You'll also have to work hard for whatever you don’t want to be in life. Think about it.

As a person who is facing many challenges in writing as a blogger and an aspiring writer hoping to write about testing, I am taking every opportunity to write better and express myself. I also want to help fellow colleagues like you to blog (if you are not blogging already). Here I am with a little gift for you – The Fieldstone Method.

If you are a tester cum aspiring blogger, feel free to reach out to me HERE. I am sure you have it in you to make it big in this world – in your own great way.


Happy International Women’s Day,
Thanking You,
Parimala Shankaraiah