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
16 April, 2010
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
13 April, 2010
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.
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
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
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
30 March, 2010
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:
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.
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.
06 March, 2010
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:
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!
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
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
03 March, 2010
30 Minute Challenge
A few weeks ago, my colleague Ajay Balamurugadas and I went books shopping together. Jerry Weinberg’s books were on the top of my list. I wanted to buy Wienberg on Writing while Ajay had 3 choices: The Black Swan and a couple other books related to Perl. What happens when two thirsty intellectuals go book hunting? We had every reason to buy books spanning Psychology, Management, Philosophy, Computer Science, Problem Solving, Writing and many more. Luckily, Weinberg on Writing was available. Ajay got The Black Swan.
While I was getting a glimpse of Perfect Software … , Ajay asked the storekeeper for Introduction to General Systems thinking. After some initial search, the storekeeper replied politely, “Sir, our inventory shows that one last copy is available. However, it appears to be misplaced. If you come back at a later time, we can get one from the warehouse for you”. Ajay nodded his head disappointedly. I was wondering if he would really buy so many books. I already carried 5 books for both of us though we planned to buy just 2. The sumptuous lunch party at my mom’s place was calling me home!
Conversation between us
Ajay: Are you game for a 30 minute challenge?
Pari: What?
Ajay: Let’s hunt down Introduction to General Systems thinking on our own. Let’s see if we’ll find it
Pari: OK. I’ll search the Management section. You start off from the Mathematics section (the other end of the floor). If we complete these sections, we can start looking in neighboring sections.
[This is the usual me jumping off without any preparation or strategy - Trap Gods must be happy]
Ajay: We don’t know how the book looks like. That might help us find the book faster. Let me google for the cover page of the book.
[Smart move by Ajay. This guy always springs new surprises. You'll know the reason behind it as you read on]
Pari: That is a very good idea.
Ajay: This is the cover page. It’s Red in color and if placed vertically in the book stand the side might look like this which is also in red color tilting his cell phone as though the image would tilt: D.
Pari: This is a good start for us.
Ajay: Ok. I’ll see you with the book!
Pari: Wow! Bye.
I headed to the Management section which was at the other end of that floor farther away from the Mathematics section. I chose to start my search from Management section for 2 reasons: 1) Weinberg on Writing and Perfect Software.. came from that section. I had seen the storekeeper picking them from there. So I knew there was a high possibility of finding Introduction to General Systems thinking there. 2) I thought that if I don’t find the book in the management section, I can move on to neighboring Computer Science and Investments sections while Ajay could move on to Philosophy and Psychology sections if he didn’t find the book in the Mathematics section. You may ask ‘Jerry’s book in Mathematics section?’ Well, if the book has been misplaced, then it could be in any of these sections. As a matter of factly, it could be on any of the other 3 floors of the bookstore as well. Whoa! My head rolled as I thought about the coverage for this mission.
My Strategy
Ajay’s idea of looking at the book cover was a good start. I started looking for a red book. There were so many reds. I looked at Weinberg on Writing and Perfect Software.. which I already had. I remembered that some of Jerry Weinberg’s books are mostly from Dorset House. Dorset House logo is a ‘DH’ with an inverted V over the letters DH. Now, I assumed that Introduction to General Systems thinking was from Dorset House (If I were in front of the computer, I would have googled to confirm this).
I used the following strategy: First level – look for a red book. Second level - look for Dorset House logo. Third level – check if it’s written by Jerry. Fourth level – Check if it’s Introduction to General Systems thinking. Fifth level – Success. Except the first level, every other level is an elimination level. If my findings don’t match my expectations at any level, I'll find the next red book and re-apply this strategy.
Many dread Red. Though I did not assume anything about red colored books, I was astonished to see a huge number of books in red. Each time I saw a red book, I moved on to the second level looking for the logo. If DH logo was absent, I backtracked to the first level looking for the next red book. Again, remember there are different flavors of red. I wondered if the picture we saw on the cell phone was red. It could have been maroon or magenta or any other color as well displayed dimly. So I looked not just for red books, but also maroon, magenta and others which appeared close to red color.
As I completed my search in one bookstand, I observed that most bookstands had enough space to put in an extra row of books I.e., one row of books are in the front directly visible to the onlookers. There was another row hidden behind this row. Maybe, the storekeepers stored multiple copies of books displayed in the front. Maybe, some of those books were not displayed in the front at all and hence escaped the onlookers. This could be one way in which Introduction to General Systems thinking escaped the storekeeper’s eyes.
I had two options to redesign my strategy: 1) Continue searching the front row alone 2) Search both front and back rows. In the interest of time, I chose option 1. The plan was to move to option 2 if option 1 did not help me find the book. I searched in the management section and did not find any book. Instead of switching to option 2, I moved on to the next section. I said to myself, “Let me use option 1 for other sections as well. If I don’t find the book, I’ll switch over to option 2”. I looked into a couple other sections. Ajay had moved to the computer science section already though he started from the other end of the floor. I was stunned “This guy is so fast. How could he do that?”. I stood and watched him for a while if I could get any clues to optimize my search [pair testing?]. He was not only looking at the front row, but also at the back row in each bookstand. And yet quicker than me. He had picked a few more books too.
Ajay’s Strategy
What I saw here was Ajay used option 2. He searched not only the first row, but also the back rows. He simply removed a few books in the front row and peeped into the back row if there were any red books. I was amazed to see how quick he was in spite of looking for many more books. He was not just looking for Introduction to General Systems thinking, but also was open to finding other books of interest. As he ended the search in his section where he agreed to search, he started searching in my section. ‘What? Doesn’t he believe me as I just finished searching?’, I asked myself. ‘If he finds the book in my section which I missed, then there is a lesson for me to learn’ I thought and moved to psychology section where I thought there was a possibility to find the book. I gave up at the end of 20 minutes to read the first chapter of Perfect Software … while Ajay stuck to it for the entire 30 minutes.
Let’s understand Ajay’s strategy in his own words:
“The feeling of happiness when I’d get the book and smile fully look at the storekeeper encouraged me. Once the mission was decided, there was no looking back. There was no use wasting time on things not under my control. Instead, I focused on the thought: ‘The book I’d touch now could be the book I am looking for’. I ran my fingers on each book to skim the words on the title. Quick Reading I learnt at School by Dr. Raj Bapna’s Memory Techniques accelerated my search. My prior experience of helping a library teacher in arranging books helps me fish out the book quickly. Having close to 700 books at home helped. Basically, I’m used to such book hunting exercises and hence the speed. I scanned the books for the words ‘Introduction’, ‘Thinking’, ‘General’ and any title which occupied considerable space in terms of words. Though I was aware that the book was RED in color, I had the belief that the entire list can be covered easily in 30 minutes even if you select each and every book”
Did we find the book?
No. What we learned is how common this challenge is to the daily challenges we face as testers. When we get a new build for testing, We:
1. Hit the Tests right away. No planning. No preparation. No strategy. Just jump at it. This is so bad an idea given that it hardly gives a chance to our thought process.
2. Assume many things without questioning anything or anyone – We don’t ask for more information. We think that it is the programmer’s responsibility to share. How would they know what you want to know?
3. Don't Observe enough. Red is Red. But, What is red to you may not be red to your friend. It’s about perception. My 3 yo thinks all her teeth are yellow. Being a good observant helps. Observe from your eyes. Observe from the other testers eyes. Observe by thinking about the big picture.
4. Fear Multi-Storied problem. One key issue in our search was that the bookstore had several floors and given 2 people and 30 minutes, it was hard to cover all the floors. Suppose, we had found the book in 2nd floor itself, what is the guarantee that there was no book in the other floors. There could be a possibility of finding a few more misplaced books which even the inventory [read as automation] missed. Maybe. Maybe not. You never know. Now equate this book for a bug and re-read point #4. There you go. Repeat after me..... "A bug can hide wherever it wants to"
5. Don't Brainstorm. If Ajay and I brainstormed about the strategy before setting out on our own, we could have devised better ways of looking for the book. Pairing helps and speeds up testing as well. 2 pairs of eyes observe many different things at the same time.
6. Don't Share Knowledge. From Ajay's description of his experience, it is quite clear that he had prior experience of handling similar situations and dealing with them. Talking it out with him would have definitely helped us strategize this challenge better.
What I suggest above are methods that we used. These methods are fallible. When these methods work, we call it ‘Luck’. Well, it really isn’t about luck. It’s about using the right strategy. It's about how effectively we use our prior experiences and knowledge to the challenge at hand.
At the end of 30 minutes, Ajay continued to look for more books while I signed off from the bookstore. It was a day of astonishing revelation to me. It also reinforces my belief in team work and diversity of the team members when it comes to solving problems collectively.
I feel apologetic for lengthy posts at times keeping my readers' time in mind. However, some posts appear so incomplete without being lengthy. This prevents me from chopping off any content in the review phase. This is one such post which I didn't want to miss sharing with you.
Addendum on 6th March 2010
I quoted the name of the book as Perfect Illusions instead of Perfect Software. The complete name of the book is Perfect Software And Other Illusions about Testing. This is now corrected. Thanks to Fiona Charles for correcting me.
Happy Problem Solving,
Parimala Shankaraiah
While I was getting a glimpse of Perfect Software … , Ajay asked the storekeeper for Introduction to General Systems thinking. After some initial search, the storekeeper replied politely, “Sir, our inventory shows that one last copy is available. However, it appears to be misplaced. If you come back at a later time, we can get one from the warehouse for you”. Ajay nodded his head disappointedly. I was wondering if he would really buy so many books. I already carried 5 books for both of us though we planned to buy just 2. The sumptuous lunch party at my mom’s place was calling me home!
Conversation between us
Ajay: Are you game for a 30 minute challenge?
Pari: What?
Ajay: Let’s hunt down Introduction to General Systems thinking on our own. Let’s see if we’ll find it
Pari: OK. I’ll search the Management section. You start off from the Mathematics section (the other end of the floor). If we complete these sections, we can start looking in neighboring sections.
[This is the usual me jumping off without any preparation or strategy - Trap Gods must be happy]
Ajay: We don’t know how the book looks like. That might help us find the book faster. Let me google for the cover page of the book.
[Smart move by Ajay. This guy always springs new surprises. You'll know the reason behind it as you read on]
Pari: That is a very good idea.
Ajay: This is the cover page. It’s Red in color and if placed vertically in the book stand the side might look like this which is also in red color tilting his cell phone as though the image would tilt: D.
Pari: This is a good start for us.
Ajay: Ok. I’ll see you with the book!
Pari: Wow! Bye.
I headed to the Management section which was at the other end of that floor farther away from the Mathematics section. I chose to start my search from Management section for 2 reasons: 1) Weinberg on Writing and Perfect Software.. came from that section. I had seen the storekeeper picking them from there. So I knew there was a high possibility of finding Introduction to General Systems thinking there. 2) I thought that if I don’t find the book in the management section, I can move on to neighboring Computer Science and Investments sections while Ajay could move on to Philosophy and Psychology sections if he didn’t find the book in the Mathematics section. You may ask ‘Jerry’s book in Mathematics section?’ Well, if the book has been misplaced, then it could be in any of these sections. As a matter of factly, it could be on any of the other 3 floors of the bookstore as well. Whoa! My head rolled as I thought about the coverage for this mission.
My Strategy
Ajay’s idea of looking at the book cover was a good start. I started looking for a red book. There were so many reds. I looked at Weinberg on Writing and Perfect Software.. which I already had. I remembered that some of Jerry Weinberg’s books are mostly from Dorset House. Dorset House logo is a ‘DH’ with an inverted V over the letters DH. Now, I assumed that Introduction to General Systems thinking was from Dorset House (If I were in front of the computer, I would have googled to confirm this).
I used the following strategy: First level – look for a red book. Second level - look for Dorset House logo. Third level – check if it’s written by Jerry. Fourth level – Check if it’s Introduction to General Systems thinking. Fifth level – Success. Except the first level, every other level is an elimination level. If my findings don’t match my expectations at any level, I'll find the next red book and re-apply this strategy.
Many dread Red. Though I did not assume anything about red colored books, I was astonished to see a huge number of books in red. Each time I saw a red book, I moved on to the second level looking for the logo. If DH logo was absent, I backtracked to the first level looking for the next red book. Again, remember there are different flavors of red. I wondered if the picture we saw on the cell phone was red. It could have been maroon or magenta or any other color as well displayed dimly. So I looked not just for red books, but also maroon, magenta and others which appeared close to red color.
As I completed my search in one bookstand, I observed that most bookstands had enough space to put in an extra row of books I.e., one row of books are in the front directly visible to the onlookers. There was another row hidden behind this row. Maybe, the storekeepers stored multiple copies of books displayed in the front. Maybe, some of those books were not displayed in the front at all and hence escaped the onlookers. This could be one way in which Introduction to General Systems thinking escaped the storekeeper’s eyes.
I had two options to redesign my strategy: 1) Continue searching the front row alone 2) Search both front and back rows. In the interest of time, I chose option 1. The plan was to move to option 2 if option 1 did not help me find the book. I searched in the management section and did not find any book. Instead of switching to option 2, I moved on to the next section. I said to myself, “Let me use option 1 for other sections as well. If I don’t find the book, I’ll switch over to option 2”. I looked into a couple other sections. Ajay had moved to the computer science section already though he started from the other end of the floor. I was stunned “This guy is so fast. How could he do that?”. I stood and watched him for a while if I could get any clues to optimize my search [pair testing?]. He was not only looking at the front row, but also at the back row in each bookstand. And yet quicker than me. He had picked a few more books too.
Ajay’s Strategy
What I saw here was Ajay used option 2. He searched not only the first row, but also the back rows. He simply removed a few books in the front row and peeped into the back row if there were any red books. I was amazed to see how quick he was in spite of looking for many more books. He was not just looking for Introduction to General Systems thinking, but also was open to finding other books of interest. As he ended the search in his section where he agreed to search, he started searching in my section. ‘What? Doesn’t he believe me as I just finished searching?’, I asked myself. ‘If he finds the book in my section which I missed, then there is a lesson for me to learn’ I thought and moved to psychology section where I thought there was a possibility to find the book. I gave up at the end of 20 minutes to read the first chapter of Perfect Software … while Ajay stuck to it for the entire 30 minutes.
Let’s understand Ajay’s strategy in his own words:
“The feeling of happiness when I’d get the book and smile fully look at the storekeeper encouraged me. Once the mission was decided, there was no looking back. There was no use wasting time on things not under my control. Instead, I focused on the thought: ‘The book I’d touch now could be the book I am looking for’. I ran my fingers on each book to skim the words on the title. Quick Reading I learnt at School by Dr. Raj Bapna’s Memory Techniques accelerated my search. My prior experience of helping a library teacher in arranging books helps me fish out the book quickly. Having close to 700 books at home helped. Basically, I’m used to such book hunting exercises and hence the speed. I scanned the books for the words ‘Introduction’, ‘Thinking’, ‘General’ and any title which occupied considerable space in terms of words. Though I was aware that the book was RED in color, I had the belief that the entire list can be covered easily in 30 minutes even if you select each and every book”
Did we find the book?
No. What we learned is how common this challenge is to the daily challenges we face as testers. When we get a new build for testing, We:
1. Hit the Tests right away. No planning. No preparation. No strategy. Just jump at it. This is so bad an idea given that it hardly gives a chance to our thought process.
2. Assume many things without questioning anything or anyone – We don’t ask for more information. We think that it is the programmer’s responsibility to share. How would they know what you want to know?
3. Don't Observe enough. Red is Red. But, What is red to you may not be red to your friend. It’s about perception. My 3 yo thinks all her teeth are yellow. Being a good observant helps. Observe from your eyes. Observe from the other testers eyes. Observe by thinking about the big picture.
4. Fear Multi-Storied problem. One key issue in our search was that the bookstore had several floors and given 2 people and 30 minutes, it was hard to cover all the floors. Suppose, we had found the book in 2nd floor itself, what is the guarantee that there was no book in the other floors. There could be a possibility of finding a few more misplaced books which even the inventory [read as automation] missed. Maybe. Maybe not. You never know. Now equate this book for a bug and re-read point #4. There you go. Repeat after me..... "A bug can hide wherever it wants to"
5. Don't Brainstorm. If Ajay and I brainstormed about the strategy before setting out on our own, we could have devised better ways of looking for the book. Pairing helps and speeds up testing as well. 2 pairs of eyes observe many different things at the same time.
6. Don't Share Knowledge. From Ajay's description of his experience, it is quite clear that he had prior experience of handling similar situations and dealing with them. Talking it out with him would have definitely helped us strategize this challenge better.
What I suggest above are methods that we used. These methods are fallible. When these methods work, we call it ‘Luck’. Well, it really isn’t about luck. It’s about using the right strategy. It's about how effectively we use our prior experiences and knowledge to the challenge at hand.
At the end of 30 minutes, Ajay continued to look for more books while I signed off from the bookstore. It was a day of astonishing revelation to me. It also reinforces my belief in team work and diversity of the team members when it comes to solving problems collectively.
I feel apologetic for lengthy posts at times keeping my readers' time in mind. However, some posts appear so incomplete without being lengthy. This prevents me from chopping off any content in the review phase. This is one such post which I didn't want to miss sharing with you.
Addendum on 6th March 2010
I quoted the name of the book as Perfect Illusions instead of Perfect Software. The complete name of the book is Perfect Software And Other Illusions about Testing. This is now corrected. Thanks to Fiona Charles for correcting me.
Happy Problem Solving,
Parimala Shankaraiah
Subscribe to:
Posts (Atom)