The title to this post tells what this post is all about. A common scenario as you grow up the perceived corporate ladder would be a need to attend a lot of meetings. Once you grow above the managerial level, plan to attend at least 4 hrs a day in non-productive meetings. And some of these meetings, you would have to attend even though you have no idea on what it is all about. And this post is about surviving such meetings.
Listed below are a few survival tips for such meetings – wherein you don’t have an idea on the topic being discussed.
1) The sandwich Blackberry method
A large sandwich and a blackberry can be your saviors. Walk into the meeting with a large sandwich and constantly, keep fiddling on your blackberry for the entire duration of the meeting. Walk out of the room every 10 minutes to attend to that very important phone call and keep walking back inside. You can be rest assured you won't be troubled by anyone for the duration of the meeting.
2) The copy-Paste method
Before the meeting, grab your team member who's attending it and ask him on what he's going to talk about. Ask him a few questions and ensure that you remember all his answers. Send him off on any errand to ensure that he doesn't attend the meeting. Now, re-state whatever he's told you and answer the same questions that you've asked him. Nobody would disturb you after you've made your point.
3) The Magic words
Remember these words - Bottom Line, Bird's eye view, Revisit, Thinking Hat, out of the box, Paradigm, Game Plan, win-win, Leverage, etc.
The trick is to pick 2 words from above and form a sentence, at any time during the meeting. Some examples I have are below:-
a) Guys, it's time to put on the thinking hats to think of a win-win proposal
b) Folks, let's come up with an out-of-the-box solution, which is pro-active and leverages our strengths.
c) The Bottom Line is that we need to revisit if we are doing things the right way. Take a step back to have a Bird's eye view of the solution.
You can try this exercise yourself and within a few practice tries, you'd become a master at it. You can create such statements from these words randomly and you'd sound like a veteran of senior management.
4) The Blame-it-on-others Method
Start off a conversation at the beginning of the meeting to talk about bad food in the canteen, rising fuel bills, lack of facilities in the company, bad candidates lined up by HR for interview, unrealistic client demands, etc...
5) Google will help you
If it's a meeting about a product evaluation, do a vigorous Google search 1 hr before the meeting. Scribble notes from all over the internet and present them as your viewpoint. Mostly, nobody would know and you can escape unscathed.
And my pick goes to the method described below... the best thing to do is....
6) Being honest
Yes. The last way is honesty. Stand up and tell everyone that you will be unable to provide any justice by your attendance, since you have no idea on what's being discussed. Tell everyone that you think you'd be better off doing something productive, than be a part of it and walk out. That's not something that happens very often, but I guess it's the most honest way.
If you can think of more such practices, I'd be happy to hear them and it would be great if you can post them in the comments section!!!
Well, what about those telephonic meetings that you need to dial in to attend??? Well, save that thought.... more on those another day!!!
Monday, August 16, 2010
Thursday, August 5, 2010
The Defect I Leaked
Earlier in life, in the late 90’s, I was hired to test a software application's installation. After the usual late hours, Development fights, etc., I certified that the product works fine and Okayed the release.
What Happened then?
Within 1 day of going live, the support team was flooded with a zillion calls saying that the application does not get installed. All the installations aborted with the error message - "INVALID OS". The products had to be re-called, the defect fixed and re-shipped.
Root Cause on Investigation
The installation software had logic to determine the version of the Client machine's OS. Both Dev & Test assumed the location of this entry in a particular location, while most of the live systems had this info stored in a different location in the registry. As a member of the test team, I did not do sufficient research before testing and missed out this important detail, which at that time seemed insignificant to me.
Who's to be blamed for the Fiasco?
3 People who were responsible --- I, Me & Myself.
Defect Leakage --- A 1st for me
It was the 1st defect I leaked which had very high business impact. The fault was mine, mine & mine. Like so many other people in the project, I assumed that the operating system version is stored at a particular location only. I assumed that it cannot be stored elsewhere and so, I DID NOT TEST FOR IT. BY ASSUMING, I LEAKED A DEFECT!!!
Till today, the bug haunts me every time I take up a testing assignment. It is the fact that I can still leak a defect makes me more determined to ensure that I don't leak defects at least now.
A Fake Software tester...
--- Never admits his fault to a defect that he's leaked
--- Always thinks someone else is to blame for a defect that he's leaked
--- forgets the leaked defect too soon in life and invariably, leaks many more
--- Tries to pass the root cause for defect leakage due to a different reason --- bad environment, bad specification, bad coding, time pressure, no requirements, etc. etc. etc....
In every interview of mine, I ask the test engineers who are applying for the job about any defect that they'd have leaked earlier. And to date, most of them have said that they have never leaked a defect in their entire life!!! This is coming from testers who have an experience of 6-10 years in the Software Testing Industry.
Do I see an entry here for the files of Ripley's believe it or not? (Personally speaking a tester who's never leaked a defect can be equated with a developer who has never had a single bug filed against his name).Unbelievable!!! Truly, Unbelievable!!!
The truth is that even experienced testers leak defects. And only we know about the defect that we leaked. And we have to ensure that we have to remember a leaked defect all the time to remind us that we are also vulnerable, so that we will at least try to avoid leaking defects in the future!!!
Fake Tester's Gyan (of course, the gyan giving is very important too)
1) Admit Blame --- Yes. Admit blame at least to yourself, if not to the entire world!!!
2) Shameful, it is not --- Though you might feel some shame in admitting a defect, trust me, it’s not. What’s actually shameful is NOT TO ADMIT IT TO EVEN YOU!!!
3) If I leaked defects, am I a failing tester? --- A common misconception is that you'd seem a failed tester to your peers if you admit it. You are not failing. You are the only one speaking the truth and you are sub-consciously scaling the success peak by your honest admissions.
4) It takes Guts. Do you have them? --- It takes guts to admit a defect you leaked. Am very sure that you do have a leaked defect. But do you have the guts to admit it?
If you are mentally strong enough to admit to a defect that you leaked, please feel free to share it on the Comment section below. If you are not bold enough to share it with the world, spend 10 mins in retrospection, admitting it to yourself!!! To own up to yourself about blaming self for a leaked defect makes you a better person; and a much better tester in the long run!!!
Happy Admissions, if you dare to admit!!!
Friday, July 9, 2010
To Trust, or Not to Trust - Part 1 of 7...
"To be or not to be --- That remains the question..." - started Hamlet in his soliloquy. But, what he did not know was that he was being watched by a few other people when he was delivering it.....
Similarly, a software tester also has to, over time, build credibility with other team members – Be it peers, or bosses, or bigger bosses, or sub-ordinates. Having said that, a tester should also know a list of people he can trust.
Trees have been felled in the go-green world on writing millions of zillions of articles on why the test teams need to build credibility with other team members. But, the question that’s posed here is -- Have the other teams built their credibility with the testers?
Need for the Question
Is there a need for the question posed above? Why does the test team need to know which other team have built their credibility with the test teams?
Well, to cut a long story short, let’s take a quick look and ask the tester the following questions, before he starts testing.
1) What’s your confidence level on the fact that there will not be scope creep?
2) What’s your confidence level on coverage of non-functional requirements?
3) How sure are you that the defect is fixed, when the developer checks-in code at 11 PM?
4) Do you believe that the Dev teams have completed the code review? Or are they under pressure from senior management to start testing at the earliest and have turned a blind eye to the code being reviewed?
5) A problem has occurred in production and you have been asked to call the support engineer. How confident are you that the production support engineer has given you all logs? How confident are you that he’d support you?
6) You have goofed up big time. How confident are you that, when you confide this in your boss, your boss won’t blow it out of proportion, but would correct you?
7) You have just conveyed the biggest risks to your project managers, whose objective is on-time delivery. How confident are you that they would have conveyed the risks to the clients?
And the answer is…
The answer to all would be a confidence %. Or confidence quotient. And that directly will be more, or less, depending on how much credibility that the concerned person has built with you over time.
For the software tester, life is tough, since people start noting him only at the fag end of the test chain. He is the last line of defense and has to handle all the pressure.
During this time, the tester will need to make decisions on who can and cannot be trusted. How is this decision made? Only on the basis of your relationship with the person and how they have reacted to a similar situation in the past. And that’s why you need to know who have built their credibility with you.
I will try and pen my thoughts on future posts, on what can potentially happen when there’s lack of trust between the tester and the peer. Will try to post them in another 7 or 8 short boring posts…..
Till then … to Trust, or not to trust... remains your question to be answered!!!
Similarly, a software tester also has to, over time, build credibility with other team members – Be it peers, or bosses, or bigger bosses, or sub-ordinates. Having said that, a tester should also know a list of people he can trust.
Trees have been felled in the go-green world on writing millions of zillions of articles on why the test teams need to build credibility with other team members. But, the question that’s posed here is -- Have the other teams built their credibility with the testers?
Need for the Question
Is there a need for the question posed above? Why does the test team need to know which other team have built their credibility with the test teams?
Well, to cut a long story short, let’s take a quick look and ask the tester the following questions, before he starts testing.
1) What’s your confidence level on the fact that there will not be scope creep?
2) What’s your confidence level on coverage of non-functional requirements?
3) How sure are you that the defect is fixed, when the developer checks-in code at 11 PM?
4) Do you believe that the Dev teams have completed the code review? Or are they under pressure from senior management to start testing at the earliest and have turned a blind eye to the code being reviewed?
5) A problem has occurred in production and you have been asked to call the support engineer. How confident are you that the production support engineer has given you all logs? How confident are you that he’d support you?
6) You have goofed up big time. How confident are you that, when you confide this in your boss, your boss won’t blow it out of proportion, but would correct you?
7) You have just conveyed the biggest risks to your project managers, whose objective is on-time delivery. How confident are you that they would have conveyed the risks to the clients?
And the answer is…
The answer to all would be a confidence %. Or confidence quotient. And that directly will be more, or less, depending on how much credibility that the concerned person has built with you over time.
For the software tester, life is tough, since people start noting him only at the fag end of the test chain. He is the last line of defense and has to handle all the pressure.
During this time, the tester will need to make decisions on who can and cannot be trusted. How is this decision made? Only on the basis of your relationship with the person and how they have reacted to a similar situation in the past. And that’s why you need to know who have built their credibility with you.
I will try and pen my thoughts on future posts, on what can potentially happen when there’s lack of trust between the tester and the peer. Will try to post them in another 7 or 8 short boring posts…..
Till then … to Trust, or not to trust... remains your question to be answered!!!
Wednesday, June 16, 2010
Software Testing and the "Hand of Clod"!!!
England Played USA on their first FIFA 2010 World Cup match and most of the world saw Rob Green's (England Goal Keeper) mistake that let the USA escape with a draw.
The next day, the entire world have started to blame Rob Green for his mistake, attributing the goal only to his mistake. People are contemplating firing him. We even have seen the "Hand of Clod" headline in many newspapers.
I am not trying to say that the England Goalkeeper is not at fault, but let's try to answer a few questions below...
1) Who let the possession of the ball to USA?
2) Where were the mid-fielders and why did they let the USA Offense inside?
3) Where were the defenders and why did they let the USA Offense so close?
4) Why could the defenders not intercept the shot to the goal?
5) Who was assigned to mark the scorer? Where was he when the scorer scored?
6) Who selected Rob Green to play in the match?
7) Who decided to buy the gloves that the Goalkeeper was wearing? Was it tested for circumstances wherein the ball meets the gloves when the gloves are wet? What were the test results and who tested it?
And so many many many more questions.....
If the answer is not "England Goalkeeper" for any of the above questions, then I don't think that it is right to blame him for the goal.
What is important is - a part of the blame is his; even more important is ONLY A PART OF THE BLAME IS HIS. The rest of the blame has to be owned by other members of England World Cup Soccer team.
Trying to draw a parallel between this and today's software tester, now think about a scenario wherein a tester would have leaked a very easy to detect showstopper defect.
Writer’s Irritating Personal Note:- My opinion is that all of us (the readers and writer of this post) have leaked defects in the past;but only a few honest testers would admit it. Whoever claims not, is a "fake tester"!!!!
Coming back to the story, the entire team blame the tester for leaking a very easy to detect showstopper defect.
Nobody questions the following which could have resulted in the defect...
1) Wrong Reqiurements sent by the Client --- We cannot question the client, can we?
2) Design problems which would have resulted in the defect
3) Lack of Unit Testing or Test Coverage
4) Waking hours of the tester before he detected the defect (What if he's been testing continuously for 12 hours and let the defect slip in the 13th hour of testing?)
5) Scope Creep in form of Change Requests
6) The boss who was breathing down the tester's neck when the tester was testing
and a million zillion other questions!!!
As part of "Most Convenient for all" Corrective action, the test team or tester gets fired and the world is happy!!!
Question yourself. Is that a corrective action or a "convenient" action?
My take on the incident
Now, I am not saying that Rob Green should not be blamed at all. He is definitely to be blamed. It was his job to stop a goal and he let in the goal.
But, what I am saying is that he is not the only person to be blamed. Likewise, the software tester is not an individual to be blamed when a defect is leaked.
Until and Unless the entire engineering team stands up and takes responsibility, such defect leaks will continue and recur sometime in the not so distant future!!! I think, that's what teamwork is all about... taking someone along with you when the going's not so good... If that does not happen, then i think we need another blog on "fake teams" ;) !!!
The Defects should start and stop with the entire team. If you are a part of the team, then the defect owner should be you, YOU and YOU!!!!! Until and unless you try to own a defect that you have come in contact with, defect leakage (and goal leakage) will continue!!!!!
The next day, the entire world have started to blame Rob Green for his mistake, attributing the goal only to his mistake. People are contemplating firing him. We even have seen the "Hand of Clod" headline in many newspapers.
I am not trying to say that the England Goalkeeper is not at fault, but let's try to answer a few questions below...
1) Who let the possession of the ball to USA?
2) Where were the mid-fielders and why did they let the USA Offense inside?
3) Where were the defenders and why did they let the USA Offense so close?
4) Why could the defenders not intercept the shot to the goal?
5) Who was assigned to mark the scorer? Where was he when the scorer scored?
6) Who selected Rob Green to play in the match?
7) Who decided to buy the gloves that the Goalkeeper was wearing? Was it tested for circumstances wherein the ball meets the gloves when the gloves are wet? What were the test results and who tested it?
And so many many many more questions.....
If the answer is not "England Goalkeeper" for any of the above questions, then I don't think that it is right to blame him for the goal.
What is important is - a part of the blame is his; even more important is ONLY A PART OF THE BLAME IS HIS. The rest of the blame has to be owned by other members of England World Cup Soccer team.
Trying to draw a parallel between this and today's software tester, now think about a scenario wherein a tester would have leaked a very easy to detect showstopper defect.
Writer’s Irritating Personal Note:- My opinion is that all of us (the readers and writer of this post) have leaked defects in the past;but only a few honest testers would admit it. Whoever claims not, is a "fake tester"!!!!
Coming back to the story, the entire team blame the tester for leaking a very easy to detect showstopper defect.
Nobody questions the following which could have resulted in the defect...
1) Wrong Reqiurements sent by the Client --- We cannot question the client, can we?
2) Design problems which would have resulted in the defect
3) Lack of Unit Testing or Test Coverage
4) Waking hours of the tester before he detected the defect (What if he's been testing continuously for 12 hours and let the defect slip in the 13th hour of testing?)
5) Scope Creep in form of Change Requests
6) The boss who was breathing down the tester's neck when the tester was testing
and a million zillion other questions!!!
As part of "Most Convenient for all" Corrective action, the test team or tester gets fired and the world is happy!!!
Question yourself. Is that a corrective action or a "convenient" action?
My take on the incident
Now, I am not saying that Rob Green should not be blamed at all. He is definitely to be blamed. It was his job to stop a goal and he let in the goal.
But, what I am saying is that he is not the only person to be blamed. Likewise, the software tester is not an individual to be blamed when a defect is leaked.
Until and Unless the entire engineering team stands up and takes responsibility, such defect leaks will continue and recur sometime in the not so distant future!!! I think, that's what teamwork is all about... taking someone along with you when the going's not so good... If that does not happen, then i think we need another blog on "fake teams" ;) !!!
The Defects should start and stop with the entire team. If you are a part of the team, then the defect owner should be you, YOU and YOU!!!!! Until and unless you try to own a defect that you have come in contact with, defect leakage (and goal leakage) will continue!!!!!
Saturday, June 12, 2010
All the Fake Numbers
Someone once said "Keep It Simple, Stupid"!!!. I'd say, "Keep it Simple". If not, it means "You're Stupid!!!".
Let's try to see a scene that we’d all encounter during the end of the test cycle.
The Cast
Test Representative - Test Lead, Test Manager, Senior Tester, whoever. I call the person as a test representative since that's what he/she is
Boss - Master of the Daylight hours of the test representative
Big Boss - Master of the Daylight hours of the boss of the boss of the test representative,
Bigger Boss - Senior Management , Project Sponsors, etc. etc. etc...
Peer - Close friend/Best Buddy/Pal of the test representative, who is stuck in another project or wants to spend time browsing, or a workaholic, 1 who stays late @ office...
Project Stage ---> 2 Weeks before shipping
Time - 7 PM - Day 1
Scene - The test representative has been asked to send a daily status report on testing status by his boss.
Mental State of Test Representative ---> Panic Stricken!!! He has not sent such a report earlier in his life!!! His boss has re-directed him to the archives of the company to find a similar report. His peers have responded to his "call of panic" by flooding his mail boxes with format of a 10,000 status reports, some from his email archives and some from his google search.
What does the Test Representative do? - With a little time, he looks at whatever metrics is available with him, whatever he knows, and plugs it into a test status report and sends it to the whole world.
Fast Forward to next day.
Time - Day 2, 10 AM
Venue - Big boss's email
Activity - Big boss has received an email in the choicest language from his bigger boss's. They indicate a worthless status report.
Time - Day 2, 10:14 AM
Venue - Office of Big Boss
Scene - Big boss faulting the boss for a hopeless report, says the magic word “Appraisal”!!!
Language – The choicest words :) !!!!!
Time – 11:04 AM
Venue - Boss's office
Scene - Boss shouting at the Test representative for a very bad status report. Boss also mentions the word "Appraisal"!!!
Language – The very same choicest words :)!!!
What now? – Today, the boss wants to send the Test Report himself.
Time – 2:08 PM
Venue - Browser of the Test Representative
Activity - Test Representative having opened 7 Windows in IE and doing a search on test status reports and Metrics management. Finds a lot of data that he incorporates into the current day's test report.
Time frame– From 6:11 PM – 9:56 PM
Activity – 582 e-mails between the boss and the test representative on improving the report quality
Time - 10:02 PM in the evening
Venue - Boss's mail-box
Activity - Having reviewed the test report multiple times, and after so many updates between him and the test representative, the boss opens the current day's test status report and hits the "Send" button!!!
Boss’s Mental State - Relieved.
Time - 10:03 PM in the evening
Venue – Bigger boss’s mail-box
Activity - Opening the test status report sent by the boss and reads it.
Mental State – More Confusion!!! Is this what I said? Yes, he is confused. He is seeing so many details in the report, and he is confused on what to make of it.
Time - 10:46 PM
Venue - Hospital
Hospital? Yes, the bigger boss has been admitted for head injury. Witness seem to indicate that he has banged his head against a wall. His laptop has the latest status report open!!!
Time – Next day morning…
Venue – Bigger boss’s office
People - A bandaged bigger boss, the big boss and the test representative.
Activity – Well, I really don’t want to go into that… This blog is about fake software testing and I think we need to come back to our subject of software testing!!!
And the truth is--- Among all of the above people, there is definitely at least "1 fake software tester"!!!
What none of the above cast realized ---> The answer to Why, Why and Why. What questions does the status report, sent on an every day basis towards the end of the release cycle, try to indicate?
What these people should realize ---> The only 2 questions that people want to be answered from the test status report are ...--- How soon can we release? What is the health of the current build?
That's all, I believe, should the test status report try to indicate. It's very important for the test team to project these numbers so that all other stakeholders understand project health and ability to meet release dates.
Take a look at some of the metrics on test status reports that you can find defect reports - Time taken to test, no. of defects in all builds in the last year, Review count of test cases reworked on (from the previous generation), review time for test cases, Various delays that happenned in the project, Root Cause Analysis, Defect injected rate, Life-history of the entire project, Defect Removal Rate, Remaining defects rate, etc. etc. etc...
As in the story above, the boss and the bigger boss try to project a lot of information in these reports – The poor test team representative spends hours and hours of time in trying to get the above metrics into the report. Though each data point is valid at some stage, their usefulness is defined by the way it is useful to the project in the current stage. With very little time to ship the application, these numbers become useless.
Neither do these indicate the current health, nor do they indicate how soon can you ship the product.
Having said that, what do you think I say should be in the report?
1) Number of Open S1-P1/S2-P2 defects & time taken to resolve/re-test them - You will need to work very closely with the development team to predict these numbers.
2) No. of blocked test cases and the business priority of these blocked test cases - You will need to work very closely with Business/Dev team to say these numbers.
3) Ratio of no. of passed test cases to no. of total test cases - This is something that you should be able to say. Also indicate business priority of the passed test cases.
4) Sometimes people want to see a list of issues. Please feel free to include a list of open defects, but what will add value is an estimate on the time to fix/re-test these defects as well.
5) List of existing issues/blockers – Add to this list, details of who owns it and the ETA.
These not only tell you a status of the current health of the build, but also give you a view on how soon you can ship. That's all you need!!!
Of course, it would be very easy for all of you to tell me trillions of other metrics that you need...but then, if you subscribe to the thought of a trillion metrics in your daily test status reports, then you'd fall into the category of the fake software testers!!!
Happy Reporting!!!
Let's try to see a scene that we’d all encounter during the end of the test cycle.
The Cast
Test Representative - Test Lead, Test Manager, Senior Tester, whoever. I call the person as a test representative since that's what he/she is
Boss - Master of the Daylight hours of the test representative
Big Boss - Master of the Daylight hours of the boss of the boss of the test representative,
Bigger Boss - Senior Management , Project Sponsors, etc. etc. etc...
Peer - Close friend/Best Buddy/Pal of the test representative, who is stuck in another project or wants to spend time browsing, or a workaholic, 1 who stays late @ office...
Project Stage ---> 2 Weeks before shipping
Time - 7 PM - Day 1
Scene - The test representative has been asked to send a daily status report on testing status by his boss.
Mental State of Test Representative ---> Panic Stricken!!! He has not sent such a report earlier in his life!!! His boss has re-directed him to the archives of the company to find a similar report. His peers have responded to his "call of panic" by flooding his mail boxes with format of a 10,000 status reports, some from his email archives and some from his google search.
What does the Test Representative do? - With a little time, he looks at whatever metrics is available with him, whatever he knows, and plugs it into a test status report and sends it to the whole world.
Fast Forward to next day.
Time - Day 2, 10 AM
Venue - Big boss's email
Activity - Big boss has received an email in the choicest language from his bigger boss's. They indicate a worthless status report.
Time - Day 2, 10:14 AM
Venue - Office of Big Boss
Scene - Big boss faulting the boss for a hopeless report, says the magic word “Appraisal”!!!
Language – The choicest words :) !!!!!
Time – 11:04 AM
Venue - Boss's office
Scene - Boss shouting at the Test representative for a very bad status report. Boss also mentions the word "Appraisal"!!!
Language – The very same choicest words :)!!!
What now? – Today, the boss wants to send the Test Report himself.
Time – 2:08 PM
Venue - Browser of the Test Representative
Activity - Test Representative having opened 7 Windows in IE and doing a search on test status reports and Metrics management. Finds a lot of data that he incorporates into the current day's test report.
Time frame– From 6:11 PM – 9:56 PM
Activity – 582 e-mails between the boss and the test representative on improving the report quality
Time - 10:02 PM in the evening
Venue - Boss's mail-box
Activity - Having reviewed the test report multiple times, and after so many updates between him and the test representative, the boss opens the current day's test status report and hits the "Send" button!!!
Boss’s Mental State - Relieved.
Time - 10:03 PM in the evening
Venue – Bigger boss’s mail-box
Activity - Opening the test status report sent by the boss and reads it.
Mental State – More Confusion!!! Is this what I said? Yes, he is confused. He is seeing so many details in the report, and he is confused on what to make of it.
Time - 10:46 PM
Venue - Hospital
Hospital? Yes, the bigger boss has been admitted for head injury. Witness seem to indicate that he has banged his head against a wall. His laptop has the latest status report open!!!
Time – Next day morning…
Venue – Bigger boss’s office
People - A bandaged bigger boss, the big boss and the test representative.
Activity – Well, I really don’t want to go into that… This blog is about fake software testing and I think we need to come back to our subject of software testing!!!
And the truth is--- Among all of the above people, there is definitely at least "1 fake software tester"!!!
What none of the above cast realized ---> The answer to Why, Why and Why. What questions does the status report, sent on an every day basis towards the end of the release cycle, try to indicate?
What these people should realize ---> The only 2 questions that people want to be answered from the test status report are ...--- How soon can we release? What is the health of the current build?
That's all, I believe, should the test status report try to indicate. It's very important for the test team to project these numbers so that all other stakeholders understand project health and ability to meet release dates.
Take a look at some of the metrics on test status reports that you can find defect reports - Time taken to test, no. of defects in all builds in the last year, Review count of test cases reworked on (from the previous generation), review time for test cases, Various delays that happenned in the project, Root Cause Analysis, Defect injected rate, Life-history of the entire project, Defect Removal Rate, Remaining defects rate, etc. etc. etc...
As in the story above, the boss and the bigger boss try to project a lot of information in these reports – The poor test team representative spends hours and hours of time in trying to get the above metrics into the report. Though each data point is valid at some stage, their usefulness is defined by the way it is useful to the project in the current stage. With very little time to ship the application, these numbers become useless.
Neither do these indicate the current health, nor do they indicate how soon can you ship the product.
Having said that, what do you think I say should be in the report?
1) Number of Open S1-P1/S2-P2 defects & time taken to resolve/re-test them - You will need to work very closely with the development team to predict these numbers.
2) No. of blocked test cases and the business priority of these blocked test cases - You will need to work very closely with Business/Dev team to say these numbers.
3) Ratio of no. of passed test cases to no. of total test cases - This is something that you should be able to say. Also indicate business priority of the passed test cases.
4) Sometimes people want to see a list of issues. Please feel free to include a list of open defects, but what will add value is an estimate on the time to fix/re-test these defects as well.
5) List of existing issues/blockers – Add to this list, details of who owns it and the ETA.
These not only tell you a status of the current health of the build, but also give you a view on how soon you can ship. That's all you need!!!
Of course, it would be very easy for all of you to tell me trillions of other metrics that you need...but then, if you subscribe to the thought of a trillion metrics in your daily test status reports, then you'd fall into the category of the fake software testers!!!
Happy Reporting!!!
Friday, June 4, 2010
Pressure --- It's all yours!!!!!
Pressure... --- It is a very familiar term by now. All of us have said that we are pressurized at the work place. All of us say that we feel pressurized due to deliverables, dates, schedules, still-open-must-fix defects, etc. etc. etc.
Expected Behavior Under Pressure --- That you remain unaffected!!!
Actual Behavior --- Unknown... each individual behaves differently under different situations!!!
Well, let's take a look at the following few scenes that you can come across in every day life.....
Scene 1
The Time ---> A lazy weekend when you have hours to spare
The Assignment ---> You are browsing a book website to buy the latest offering from Jeffery Archer.
The Scene ---> You encounter a JavaScript error message. You take a look at the error message, choose the relevant option and keep browsing. Out of your personal interest in testing, you sometimes take notes on what the error message was, but you keep browsing the website.
Scene 2 ---
The time ---> 11.30 AM... Day 3 of your first job in your new company.
The Assignment ---> Test the client's application. The application is a website that sells books.
The scene ---> you want to prove yourself to everyone in the new world. While you are testing the book website, you come across a JavaScript error. When you test the page, you work on an all-nerves-alert mode; make notes of the JavaScript error. Of course, with the new job, you feel a bit of the nerves, but you tell yourself that it's nothing that you cannot handle.
Scene 3
The time ---> 11.30 AM... 1 Day before shipping
The Assignment ---> Test the client's application that sells books.
The Scene ---> You have been asked to provide the sign-off by the day's evening. You start testing. Every 1 hour, you get calls from your bosses asking for updates on testing. You are still explaining test progress in a phone to your bigger bosses, when you encounter the same JavaScript error.
Next steps --> you report it to the world and while the defect is being fixed and deployed, you heave a sigh of relief and go out for a cup of coffee. (I don't smoke and so, I don't have a reference to smoking over here :)!!!
Scene 4
The time ---> 11.30 AM ... 8 hours before shipping
The assignment --> testing the client's web application that sells books.
Your Client ---> Wants to ship the product 24 hours before his competitor. Keeps calling the CEO telling him that the success of the project would mean more revenue. He wants a defect free product & the product has undergone a 1000 last-minute CRs.
Your company's CEO ---> feels that by releasing in time, the company would make a million dollars more in the financial.
Your manager ---> feels that he'd get a promotion if the defect-free product ships on time.
The Scene ---> With 8 hours to launch, a build arrives for the test team and you are asked to test the booking website. Your manager makes it very clear to you that a slip-up can cost you your job in the company. Your CEO keeps asking you for what's happening. You come across the JavaScript error. But, you feel the tension while you test since you feel a 100 pairs of eyes watching you test.
The common factors and the differences from the above listed...
The Common Factors
1) The product is the same
2) The defect is the same
3) The tested product is the same
4) The Stakeholders are the same
The Difference...
The Degree of Pressure...
Where does this Pressure stem from? My thoughts listed...
Fear.... Of failing... and of succeeding.......
1) Of Failing???
Most of our managers, talk about the consequences of failure. And this thought plants itself deep-rooted in our minds. Even CEOs let talk of the wide-spread belief (yes, may people believe this still!!!) that the tester is wholly responsible for finding a defect. In the name of "sending across the right message", managers have fired testers who have been in the project for a long time, due to minimal defect leakage... Plus, add the burden that a defect leakage would also mean that all those long hours and personal sacrifices for the current project becomes wasted..... With more and more eyes watching you, fear climbs to a much higher altitude and increases in magnitude... Over time, this fear breeds into nervousness.
2) Of Succeeding???
Can someone have a fear of succeeding??? Yes.... When a project is going to end, the mind goes on visit to a few places --- 1 place is called the future, where the mind starts to thank the people who congratulate you..... While the other part of the mind has a fear of stumbling at the last hurdle.
Result ---> The tester is unable to have a rational thought, unable to make a decision on a defect and tends to think that every defect found is severe. A case of where the individual falls down due to the fear of succeeding...
3) Pressure initiated by external agencies
I don't know about you, but I have had sleepless nights prior to a very critical release. When a product goes live, there may be a zillion items that can go wrong. The importance of the occasion of the release, and the so-called expectations can do a lot of damage to the untrained mind.
How do you respond to Pressure?
Every individual have different ways of responding to pressure. Some step up, while others break down. You will have to know how you work under pressure.
And, you will have to inform your bosses as to how you work under pressure. Good Managers (and I say good managers), get the work completed by exerting the "right amount of pressure"!!!
Having said that, how do you handle pressure?
If you google, then you would get a million answers (except this blog since this ain't listed in google). But, there's only 1 person who knows it... And that 1 person is YOU. Think about how you would work under pressure and be prepared for all possible items. Be prepared to handle pressure... so when it is delivered at your door-step, you'd know how to handle it.
Some Gyan on Handling Pressure?
What do I do?
Well, I don't know how you'd handle it, but what I do is... When I come across a pressure situation, I make a conscious decision to walk away from there. By completely moving away, it offers me enough time to ensure that the steam is let off.
Controlling the mind
Some people believe in controlling the mind. Mind-Control exercises to help them focus on the current situation at hand.
A team member's role in reducing pressure...
Confiding in team members and taking their help. Works fine for a few...Some people are able to handle pressure independently and some are able to handle it as a team.
Becoming a Detached soul...
This works fine for me. Getting mentally and emotionally detached saves you from getting drained out. Once you are completely detached from the situation, from the product hype, from the expectations, you can stay in the present without letting the pressure get to you.
Fake Testers gyan
And I like giving Gyan :)!!! And please do remember, even if you don't come across this situation in your current job, it's highly likely that you'd come across this situation sometime in the near future. So, in addition to increasing your testing skills, please spare a thought, spare a moment as to how you would be handling pressure.
And use every situation to practice how you would work under pressure... It will help you to handle pressure in the upcoming days.
That's just 1 stop in your journey towards better testing...Other stops to come in later posts!!!
Expected Behavior Under Pressure --- That you remain unaffected!!!
Actual Behavior --- Unknown... each individual behaves differently under different situations!!!
Well, let's take a look at the following few scenes that you can come across in every day life.....
Scene 1
The Time ---> A lazy weekend when you have hours to spare
The Assignment ---> You are browsing a book website to buy the latest offering from Jeffery Archer.
The Scene ---> You encounter a JavaScript error message. You take a look at the error message, choose the relevant option and keep browsing. Out of your personal interest in testing, you sometimes take notes on what the error message was, but you keep browsing the website.
Scene 2 ---
The time ---> 11.30 AM... Day 3 of your first job in your new company.
The Assignment ---> Test the client's application. The application is a website that sells books.
The scene ---> you want to prove yourself to everyone in the new world. While you are testing the book website, you come across a JavaScript error. When you test the page, you work on an all-nerves-alert mode; make notes of the JavaScript error. Of course, with the new job, you feel a bit of the nerves, but you tell yourself that it's nothing that you cannot handle.
Scene 3
The time ---> 11.30 AM... 1 Day before shipping
The Assignment ---> Test the client's application that sells books.
The Scene ---> You have been asked to provide the sign-off by the day's evening. You start testing. Every 1 hour, you get calls from your bosses asking for updates on testing. You are still explaining test progress in a phone to your bigger bosses, when you encounter the same JavaScript error.
Next steps --> you report it to the world and while the defect is being fixed and deployed, you heave a sigh of relief and go out for a cup of coffee. (I don't smoke and so, I don't have a reference to smoking over here :)!!!
Scene 4
The time ---> 11.30 AM ... 8 hours before shipping
The assignment --> testing the client's web application that sells books.
Your Client ---> Wants to ship the product 24 hours before his competitor. Keeps calling the CEO telling him that the success of the project would mean more revenue. He wants a defect free product & the product has undergone a 1000 last-minute CRs.
Your company's CEO ---> feels that by releasing in time, the company would make a million dollars more in the financial.
Your manager ---> feels that he'd get a promotion if the defect-free product ships on time.
The Scene ---> With 8 hours to launch, a build arrives for the test team and you are asked to test the booking website. Your manager makes it very clear to you that a slip-up can cost you your job in the company. Your CEO keeps asking you for what's happening. You come across the JavaScript error. But, you feel the tension while you test since you feel a 100 pairs of eyes watching you test.
The common factors and the differences from the above listed...
The Common Factors
1) The product is the same
2) The defect is the same
3) The tested product is the same
4) The Stakeholders are the same
The Difference...
The Degree of Pressure...
Where does this Pressure stem from? My thoughts listed...
Fear.... Of failing... and of succeeding.......
1) Of Failing???
Most of our managers, talk about the consequences of failure. And this thought plants itself deep-rooted in our minds. Even CEOs let talk of the wide-spread belief (yes, may people believe this still!!!) that the tester is wholly responsible for finding a defect. In the name of "sending across the right message", managers have fired testers who have been in the project for a long time, due to minimal defect leakage... Plus, add the burden that a defect leakage would also mean that all those long hours and personal sacrifices for the current project becomes wasted..... With more and more eyes watching you, fear climbs to a much higher altitude and increases in magnitude... Over time, this fear breeds into nervousness.
2) Of Succeeding???
Can someone have a fear of succeeding??? Yes.... When a project is going to end, the mind goes on visit to a few places --- 1 place is called the future, where the mind starts to thank the people who congratulate you..... While the other part of the mind has a fear of stumbling at the last hurdle.
Result ---> The tester is unable to have a rational thought, unable to make a decision on a defect and tends to think that every defect found is severe. A case of where the individual falls down due to the fear of succeeding...
3) Pressure initiated by external agencies
I don't know about you, but I have had sleepless nights prior to a very critical release. When a product goes live, there may be a zillion items that can go wrong. The importance of the occasion of the release, and the so-called expectations can do a lot of damage to the untrained mind.
How do you respond to Pressure?
Every individual have different ways of responding to pressure. Some step up, while others break down. You will have to know how you work under pressure.
And, you will have to inform your bosses as to how you work under pressure. Good Managers (and I say good managers), get the work completed by exerting the "right amount of pressure"!!!
Having said that, how do you handle pressure?
If you google, then you would get a million answers (except this blog since this ain't listed in google). But, there's only 1 person who knows it... And that 1 person is YOU. Think about how you would work under pressure and be prepared for all possible items. Be prepared to handle pressure... so when it is delivered at your door-step, you'd know how to handle it.
Some Gyan on Handling Pressure?
What do I do?
Well, I don't know how you'd handle it, but what I do is... When I come across a pressure situation, I make a conscious decision to walk away from there. By completely moving away, it offers me enough time to ensure that the steam is let off.
Controlling the mind
Some people believe in controlling the mind. Mind-Control exercises to help them focus on the current situation at hand.
A team member's role in reducing pressure...
Confiding in team members and taking their help. Works fine for a few...Some people are able to handle pressure independently and some are able to handle it as a team.
Becoming a Detached soul...
This works fine for me. Getting mentally and emotionally detached saves you from getting drained out. Once you are completely detached from the situation, from the product hype, from the expectations, you can stay in the present without letting the pressure get to you.
Fake Testers gyan
And I like giving Gyan :)!!! And please do remember, even if you don't come across this situation in your current job, it's highly likely that you'd come across this situation sometime in the near future. So, in addition to increasing your testing skills, please spare a thought, spare a moment as to how you would be handling pressure.
And use every situation to practice how you would work under pressure... It will help you to handle pressure in the upcoming days.
That's just 1 stop in your journey towards better testing...Other stops to come in later posts!!!
Friday, April 9, 2010
Re-writing Status Reports...
"A Test Execution Status Report a day keeps all the Stakeholders at bay" :)!!!!! - Very true. When your project enters the test execution phase, please keep sending every day status reports on progress, issues faced, blockers, etc. and all stakeholders would be pleased... at least, most of the time!!!
Now, some time or the other, all of us have written status reports... “Management Teams are known for asking Delivery teams periodic updates on status, status on progress and a progress on the update :) “!!! But, have we ever given a thought to RE-Writing Status Reports? What happens when you re-write a status report? The first report that we write would be a direct outpour of data in its current form. It’s only when you try to re-write it and tweak it, that you’d be able to create more visibility to what needs to be seen and ensure that the right information is present at the right place.
Few Important factors, which people keep forgetting, while writing a status report, oops… while “Re-writing” a status report ... -- Quantitative, Concise, Accuracy, Font Usage, Priorities, Risks with business impact!!!!! There might be a Zillion more, but I feel that these are 6 main “Forgotten Factors” while "re-writing" a status report.
Here is a list of common problems that I have seen in Status Reports:-
1) Forgotten Big Picture -- Forgetting the "Big Picture". Sometimes, we tend to forget the big picture and concentrate on talking about trivial issues, which may not form a part of the bigger picture.
2) It becomes an Essay instead of a Report -- Some Status Reports might run for a few pages. How many of us even try to scroll down a daily status report?
3) Hidden Critical Information -- Some reports may have the most important piece of information hidden somewhere in the middle, or in a corner. Nobody would end up seeing this, whereas, this needs to be the first information that’s seen.
4) 2 Hour Status Report -- I have seen some people spend at least 1-2 hrs every day trying to consolidate a status report. If you do this, then something somewhere’s potentially wrong.
5) Copy Pasting -- A common habit of the fake tester is to copy-paste the information from some text and circulate it. A true tester comprehends what's being sent before sending the report. A fake tester copies and pastes information without understanding what the information’s all about.
Having given the "gyan" of what's important while writing, oops.... re-writing, these daily status reports, let's try to see as to why they are important.
Why Quantitative?
Always say it with numbers. Compare the statements -- "Worked on Logout Test Cases", "Execution of 50% Logout Related Test cases. Unable to execute 20% due to show-stoppers. Pending 30%". Having a number in every statement in a report gives a very quantitative understanding of what's been accomplished.
Why Concise?
Most people do not spend more than 30 seconds on status reports. Most of them don't even scroll down. So, please use the top most part of the report to talk about Main issues, blockers, concerns, risks, etc. – Items that need immediate resolution.
Why Accurate?
Your status reports have to be accurate enough to reflect current status. People would not be interested in the status as of the day's morning or afternoon.
In the long run, you might end-up losing your credibility if your reports are not accurate.
Font Usage --- What for?
Fonts are available to be used. Use RED for Blockers, Green for Concerns, etc. With a different color, issues get highlighted more easily and are more readable.
Do-next Priorities ---- In a status report?
Yes. Assuming you have identified 3 blockers and 5 defects, ensure that you put the name of the person who needs to look into it against each one of them. It would ensure everybody would know who is looking into a potential issue and ask him for status, accordingly. If it is a group, please find out who would be replying to you on this, and include their name in the report.
Risks in a daily status report?
Yes. If there are some defects, which can result in a business risk, please highlight it accordingly. It always pays to highlight the business risk so that the right person would look into it at the right time.
Project Risks and a Business Risk are different things. Please understand the difference while highlighting them.
After you write and re-write your status reports, do a quick check as to whether the reports are Quantitative, Concise, Accurate, Usage of Fonts, Do-next Priorities mentioned and Risks explained clearly.
Other than the above, there are other factors such as System Health Check, Severe defects, Priority fixes required, Work completed in the current day and plan for the next day, etc. etc. etc., but, these would be a part of many status reports. I tried to talk about the above since those are very crucial factors, which can be easily missed…. Project Pressure does so many funny things… so does the late night cab that you have booked which keeps honking while you try to send this report in a hurry and catch the cab!!!
Try this if you want to… Write a Status report… And use the above checklist to re-write it --- See the difference… Keep doing it till they become a habit with you… Happy Re-writing :) !!!
Now, some time or the other, all of us have written status reports... “Management Teams are known for asking Delivery teams periodic updates on status, status on progress and a progress on the update :) “!!! But, have we ever given a thought to RE-Writing Status Reports? What happens when you re-write a status report? The first report that we write would be a direct outpour of data in its current form. It’s only when you try to re-write it and tweak it, that you’d be able to create more visibility to what needs to be seen and ensure that the right information is present at the right place.
Few Important factors, which people keep forgetting, while writing a status report, oops… while “Re-writing” a status report ... -- Quantitative, Concise, Accuracy, Font Usage, Priorities, Risks with business impact!!!!! There might be a Zillion more, but I feel that these are 6 main “Forgotten Factors” while "re-writing" a status report.
Here is a list of common problems that I have seen in Status Reports:-
1) Forgotten Big Picture -- Forgetting the "Big Picture". Sometimes, we tend to forget the big picture and concentrate on talking about trivial issues, which may not form a part of the bigger picture.
2) It becomes an Essay instead of a Report -- Some Status Reports might run for a few pages. How many of us even try to scroll down a daily status report?
3) Hidden Critical Information -- Some reports may have the most important piece of information hidden somewhere in the middle, or in a corner. Nobody would end up seeing this, whereas, this needs to be the first information that’s seen.
4) 2 Hour Status Report -- I have seen some people spend at least 1-2 hrs every day trying to consolidate a status report. If you do this, then something somewhere’s potentially wrong.
5) Copy Pasting -- A common habit of the fake tester is to copy-paste the information from some text and circulate it. A true tester comprehends what's being sent before sending the report. A fake tester copies and pastes information without understanding what the information’s all about.
Having given the "gyan" of what's important while writing, oops.... re-writing, these daily status reports, let's try to see as to why they are important.
Why Quantitative?
Always say it with numbers. Compare the statements -- "Worked on Logout Test Cases", "Execution of 50% Logout Related Test cases. Unable to execute 20% due to show-stoppers. Pending 30%". Having a number in every statement in a report gives a very quantitative understanding of what's been accomplished.
Why Concise?
Most people do not spend more than 30 seconds on status reports. Most of them don't even scroll down. So, please use the top most part of the report to talk about Main issues, blockers, concerns, risks, etc. – Items that need immediate resolution.
Why Accurate?
Your status reports have to be accurate enough to reflect current status. People would not be interested in the status as of the day's morning or afternoon.
In the long run, you might end-up losing your credibility if your reports are not accurate.
Font Usage --- What for?
Fonts are available to be used. Use RED for Blockers, Green for Concerns, etc. With a different color, issues get highlighted more easily and are more readable.
Do-next Priorities ---- In a status report?
Yes. Assuming you have identified 3 blockers and 5 defects, ensure that you put the name of the person who needs to look into it against each one of them. It would ensure everybody would know who is looking into a potential issue and ask him for status, accordingly. If it is a group, please find out who would be replying to you on this, and include their name in the report.
Risks in a daily status report?
Yes. If there are some defects, which can result in a business risk, please highlight it accordingly. It always pays to highlight the business risk so that the right person would look into it at the right time.
Project Risks and a Business Risk are different things. Please understand the difference while highlighting them.
After you write and re-write your status reports, do a quick check as to whether the reports are Quantitative, Concise, Accurate, Usage of Fonts, Do-next Priorities mentioned and Risks explained clearly.
Other than the above, there are other factors such as System Health Check, Severe defects, Priority fixes required, Work completed in the current day and plan for the next day, etc. etc. etc., but, these would be a part of many status reports. I tried to talk about the above since those are very crucial factors, which can be easily missed…. Project Pressure does so many funny things… so does the late night cab that you have booked which keeps honking while you try to send this report in a hurry and catch the cab!!!
Try this if you want to… Write a Status report… And use the above checklist to re-write it --- See the difference… Keep doing it till they become a habit with you… Happy Re-writing :) !!!
Subscribe to:
Posts (Atom)