Blocking a Release - Happy or Sad ?

Test teams block a production release. You are the tester who found that bug.

Is it a good feeling to block the release? Or do you cry your lungs out for not getting out a release in time for your customers?

Do you get some sadistic happiness since your work blocked someone's release? Or do you feel sad that someone's work could not get out?

Do you feel happy that the entire org are finally appreciative of your work? Or do you feel bad for your development colleagues who slogged to meet this date and could not meet deadlines?

Do you feel happy that you did not deliver a half-baked product to your customers? Or do you feel bad that you could not have done it earlier?

Do you feel happy that your bosses praise you? Or do you feel bad for your dev counterpart who gets yelled at?

End of the day... blocking a release, results in  feelings... some happy, some sad!!! Yes, even a tester feels sad that a release could not get out in time.... (after  all, blocking a release means "no launch party", right? :)"

But when a launch or release happens in time? Life becomes happy for all... at least till the next launch :) !!!

A tester all life... 7 Questions and no answers!!!

Question 1 - If you ever say the words, "I want to be a tester all my life" to your management, what do you think would happen?

Question 2 - Would they be happy with your above decision because you have long term career focus?

Question 3 - Would they treat you as a visionary because you have a very clear idea of what you want to do in life?

Questions 4 & 5 - Or, would they term you a loser since you have no ambition to grow up the career chain? And advise you on becoming a test architect or manager?

And if you don't have a blog, you are not participative in newsgroups and online forums, you don't market yourself, you are "uncertified", you don't read blogs and magazines, you refuse to use test tools because you don't trust those tools...  and you are a tester for the last 12 years, and an expert one at that.....

Question 6 - Would your management recognise your potential?

Question 7 - Or are you branded as a resource who's not grown up the ladder and gets you replaced?

Well, as the title says, there are only questions... no answers. Only "test cases"... no "expected behavior". At least I don't have them. If you do, please share.....

Hello World Again!!! Getting rid of Procrastination...

hello world again!!! I'd disappeared for long. I don't think I've updated my blog since Last November. What was I doing? Where was I? Well, most of you know... but for those who don't , I've been here all along. I'd started writing for Testing circus since Jan and they've been kind enough to publish my writings as a regular feature. Other than that, let's just say that I've been trying to change the world. And succeeded in parts... and failed in parts.

Why did I not write? Because I was busy perfecting the art of procrastination. Every day, I told myself that I'd write "tomorrow"... "next week", "after a few days", etc. etc. etc... Having mastered the art of procrastination, i've decided to try and master "how to de-procrastinate". I decided to help myself by not reading a single page of those 1000+ self-help books that are available. Decided to fight the journey myself and came up with this idea ----- "When I see myself procrastinating, I won't feed myself till I complete whatever it was that I'd procrastinated".  And when I get rid of all my other bad habits, I think I'd have enough material to write a book about :)!!!

Does starving yourself until you de-procrastiate work? Well, it did for me... I wrote this blog post :) !!! Helped me with other things in life too...

Does it work for you? If it does, do let me know... then I can become a "de-procrastination guru of sorts", quit my job, travel the world offering advice on correcting yourself :)!!!

NOTE:- By the way, I never said "don't drink coffee"; just don't eat till you complete what you set out to do.... that's all!!!

Mis-adventures of the fake tester - Part 1...

In the past few months, I have been writing a series of articles for the testing circus. The testing circus have been kind enough to let them published in the column named "Fake Tester's Diary".

The 1st article was on the introduction to the fake tester and the process of induction. You can continue reading this article and much more in Jan's issue of Testing circus available at http://testingcircus.com/January2011.aspx

Brakes and Defect Prediction...

Brake prediction and defect prediction are related. Defect Prediction is defined by me as the ability to predict the number of defects that would occur in the next development cycle. How is Defect prediction possible? Read on for my thoughts.

I did the following exercise. My workplace is an hour’s drive from my home. I challenged myself to predict the number of times I’d brake on a day, while driving from home to office.

What I did was as follows:-

1) From Day 1 - Day 5, I calculated the number of brakes on each day to create a data repository.

2) From Day 6 - Day 15 onwards, I used the information gathered from the previous days to try and predict the number of times I braked every day. I also updated the data repository at the end of every day.

Top 7 of my observations in italized below with their corrosponding learning in Software testing in BOLD inline…

1) Every day, I applied the brake at least once on my way to work.

All of us can predict at least 1 defect in the system. (I guess that's the closest we can get to with predicting defects).

2) Though the traffic conditions and road crowd was same on all 15 days, my predictions were wrong. They had a variance of + and – 50%.

Number of lines of code cannot be used as a factor for predicting defects

3) Regardless of how many times I braked, I always reached office in  60-70 mins. Average time to reach destination was not hampered by the number of brakes.

Your project schedule will not be changed by your number of defects. Rather they are determined by your ability to detect and fix them in quick time.

4) Sometimes, when I braked, I had to remain braked for long periods of time, due to different reasons. Traffic, crowd, signals, etc. etc. etc.

Severity of defects can never be predicted at all

5) Mostly, I thought I’d hit the brakes at the same spots on the days.Wrong. More than 50% of the time, I hit the brakes at different locations.

Defect Predictions becomes a highly mis-guiding factor. It also gives you the false notion that the total number of defects will not exceed a given number. It may be proved false after the application is launched.

6) On 2 days a week at least, I had to take a different path to work. My algorithm to predict defects went haywire on those days.

During the path, teams need to display a lot of agility. Many a time, you have to take a different direction to reach your goal. Your defect prevention algorithm, may not factor in for these change of direction

7) And False Alarms!!! Sometimes, I expected an obstruction and hit the brake, but it turned out to be a false alarm.

You cannot predict false alarms. Sometimes, you might spend a few hours on a trivial or "Difficult To reproduce" defect.

Well, I certainly was not accurate on predicting defects or my brakes, but at least learnt enough information I thought is worth a blog post :)!!!

And last, the fake tester's gyan

1) Dont bother about the future. Worry about the present.

2) Ask yourself the question --- If you had 5 mins at your disposal, would you try to test the product, or use the time to predict the total no. of defects the next development cycle would throw up?

3) And lastly, when we are saying that it's not possible to fully test a product, how can you predict the number of defects in the future?


If the number of defects varies by 50%, then how do you estimate work for dev teams during testing? Well, more on that another day!!!

Re-defined Definitions...

Someone said annualy 1 billion dollars is spent on Software Testing. I believe more than half of that goes into fake testing :)!!!

Following are some Software Testing Definitions. Please take a minute to read and enrich your knowledge.

Sandbox testing - Software Testing when we have received the build, but the Dev teams have not yet completed coding some of the functionality

Waterbox testing - Software Testing that happens when test team get the build, but for some features, the design is not yet completed

Gasbox testing - Software Testing when the test team receive a build, but the dev team have not yet started coding.

Casual testing - Software Testing on Fridays when the test team is dressed in casuals. The casual attitude to testing results in what's called as "Casual Defects".

Formal testing - Software Testing that happens on Mondays when the test team is fully dressed in formals. This testing type results in "Formal Defects".

Gamma testing - Software testing that happens after alpha testing and beta testing.

Lateral Testing - Software Testing done by a team member who does not belong to your team, but to a different team.

Serial Testing - Software Testing done by testers in serial. Teams test only 1 functionality at a time.

Parallel Testing - Software Testing done by testers in parallel. All functionalities are tested simultaneously.

And by now, if you have started thinking that the above definitions are true, then what's also true is that YOU ARE A FAKE TESTER LIKE ME!!!

Honestly, a year back, I really did think that stuff as above was true. What I did not realize was as follows.

Definitions... are man-made. They are created for the convenience of the author. As a reader, it would be good if you can spend time trying to understand the concept presented by the writer and the intent of the author. It would be much beneficial for you to understand the concept, rather than try to mug the definition and become a subscriber to definitions.

Fake Tester's Gyan

Stop being a believer of Definitions.

Start being a believer of Concepts.

It's about time, you stop believing definitions and start believing concepts!!!

Interviews – Stop thinking aloud. Start thinking, Channelize your thoughts and Reply…

In the past few years, I have done quite a number of testing interviews. Some of the questions that I've asked are:-

"How do you test a pen?”, “How do you test a mobile?”, “How do you test a remote controller?", "How do you test a random number generator?", "How do you test an application that generates the fibonacci series?" etc.

When I asked them "How do you plan your testing for a website selling mobile phones, interacting with 3 suppliers?", none of them paused to think. The answer came immediately like below.

“I'd plan for sanity testing. Will plan for testing the site against XYZ interfaces. L&P Testing needs to be a part of the test plan. I'll have daily stand-ups. I will talk about cost and variances to think about estimation. I'll have a risk plan for managing risks proactively. I will do a requirements-traceability-matrix..."... and he'd go on and on and on.

After talking to many candidates, it struck me that most of them, when answering the above questions, did not pause to think; or ask for time to think. Though it seemed that they were answering the question, they were only "thinking out their thoughts aloud".

Thinking a bit more, I guess the best way to answer such questions, in an interview would be in the following 4 steps:

STEP 1:- Think.
Ponder about the question for a minute and think about the answers and various possibilities for the next couple of mins and speak up when you are prepared to answer. If you want more time, please ask the interviewer for time.

STEP 2:- Channelize your thoughts.
Think about the solution and channelize your thoughts to ensure that your answer is structured correctly, or how you want it to be structured. A structured answer, will definitely earn you a lot of brownie points with your future employer. If you want, write down short points on paper before you start talking about the answer

STEP 3:- Prioritize the reply and speak it out accordingly.
Go ahead and speak up and start answering the question. If required, refer to the short points while you answer. If you need more time to think, please ask for more time.

STEP 4:- Invite him for discussion on your reply
Ask if the interviewer has any questions or invite him to discuss the finer points of your answer. Try to give logical reasons for your decisions for prioritizing.

FST Gyan section -
If you are being interviewed, then
Start ---> Asking for time, if you think you need time.
Stop ---> thinking out your thoughts aloud. Interviews are not a forum to think aloud. Secondly, interviewers will definitely be impressed if you ask them for time to think.

If you are the interviewer, then
Start ---> Asking the candidate to think and reply.
Stop ---> asking questions when the candidate immediately answers to your questions. Most probably, he's not answering the question, but "thinking out aloud"!!!

And yes, as always, have a happy interview!!!