During my last few years as a test manager at Alcatel-Lucent, I decided to try a slightly different approach to the development of test ideas.
Before this experiment my testers would be given a feature to test and they would start by reading the functional specification (user stories if you are in an agile environment). They would develop a list of potential test ideas based on the specification document and THEN add any other ideas they could think of.
I found that when I reviewed their list of test ideas that I would often think of fairly creative test ideas that were missing from their list. Now, I would like to think that the root cause of my creativity was my highly endorsed “general awesomeness” (see my LinkedIn profile for all endorsement bombings I have received) but I am not that self-confident. I thought I would try an experiment. The experiment went very well and it changed how my team approached new testing situations.
When my team was first presented with a new feature I would allow them time to explore the feature and develop test ideas BEFORE I let them look at the functional specifications. I tried this as an experiment on one feature and I found that the creativity shown by the team was noticeably higher than when they had started with the functional specifications. I have labelled this “Functional Specification Blinders”. By reading the information in the functional specification I have found that it becomes very difficult to be able to think of testing ideas that are not included in the functional spec document. I think the reason behind this goes back to how we were exposed to learning as children. We are asked to think of explanations of how something might work (or react or behave, etc.) and then we are told how it works by a teacher (or other “expert”). Once we are told “the truth” we are expected to accept that and move on with our new knowledge. The problem with this approach is that often “the truth” is wrong or at least incomplete or misleading. I have found that the same phenomena happens when thinking about how software might be tested (or used or implemented). By allowing my team to use their creativity before reading the functional spec they have the freedom to think of test ideas that are more creative, unusual and potentially more powerful. In one class I was teaching of Rapid Software Testing, during an exercise on creating models, the students were asked to think of how to factor an object (identify all the dimensions of it) or in other words try to identify a thorough list of anything that we might want to test. One student discovered a published standard for the object before he had tried to think of any dimensions on his own. For the remainder of the exercise (roughly 5-10 minutes) he was completely incapable of thinking of ANY dimension that was not mentioned in the standard. I was pleased that he was able to show me a bit more proof in my “Functional Specification Blinders” theory.
So, if you have the freedom to investigate your feature in whatever method you choose, then I encourage you to start with other methods of learning about the feature than reading the specifications. You can any of the methods from this incomplete list:
- Play with the feature. If the feature is available (in any form) then interact with it.
- Talk to the product owner/product manager
- Talk to marketing
- Talk to customers
- Talk to the developers (or their manager)
- Talk to customer support
- Read marketing materials, claims, web sites, etc.
- Investigate competitor’s products
- Have discussions with other testers
- Talk with the architects/designers
By exploring some of these venues BEFORE reading the specifications then you can allow your creativity to blossom. The specification will still be there, waiting for you, once you have tried thinking for yourself.
Recent Comments