As I mentioned in my last post, the morning tutorial that I went to was by Vipul Kocher, co-founder of Puretesting and President of the Indian Testing Board, who spoke about ”Q-Patterns”. I went to that tutorial because I had heard the term Q-Patterns before, but didn’t know what it actually meant. Since Vipul is the creator of the term, I thought I would go and hear about it “from the horse’s mouth”, so to speak.
I usually tell myself that if I come away from a conference having learnt one new thing, then it was a successful conference. If I come away having learnt one new thing per day, then it was a really excellent conference.
Well, I must admit that I wasn’t expecting to get my 2-days’ worth of new stuff at the first tutorial, but I did.
In this case, the reuse is of Test Cases. Q-patterns provide:
- A means to communicate experience
- Aid in writing test cases
- A mechanism for test case reuse
- Aid in reviewing specifications and design
How do Q-patterns work?
Q-patterns are a method of questioning the scenario. They are a set of interrelated questions, grouped together, that relate to some aspect of user or software requirements, and provide various alternatives to arrive at a solution.
Basically, if you can ask a set of questions about a particular topic in context X, you can reuse these questions for the same topic in context Y.
Let’s use an example: A combo box.
This small element of software has a number of attributes that are irrespective of the application that the combo box is used in. If a test engineer knows what types of questions to ask about a combo box in one application (in order to get a full understanding of how it works), s/he can reuse those questions with respect to a combo box in another application.
What sort of questions can you ask about a combo box?
Usage: Data Source:
- is the combo-box populated with values by default?
- what are the default values?
- where does the combo-box get its values from?
- what happens if the data source fails?
Usage: Data addition/deletion/modification
- How are new values added? Deleted?
- Can values be modified? How?
- Where are newly added values displayed? Beginning, end or based on some type of sort?
- Is it a single or multi select? If multiple, how is the select done?
- Is the combo box wide enough to display the widest element? If not, is scrolling possible?
- How is selection displayed?
- Does the box drop down to reveal all entries? Or only some? How do you scroll vertically?
- Can the box drop down and selections be made by using the keyboard? the mouse?
- Does the box accept and display etended ASCII characters?
- Does the box accept and display multi-byte characters?
- Does the box accept right-to-left scripts (e.g. Hebrew, Arabic)?
etc. etc. etc.
You get the picture.
These are a set of generic questions that need to have answers for any implementation of a combo box, and as such, they are reusable, and can be identified as part of the “Combo-box” Q-pattern.
Exploratory Testing and Q-Patterns
According to Vipul, one testing technique that can benefit in particular from Q-patterns is exploratory testing.
How come? Exploratory testing is based on a tester’s experience. Using Q-patterns allows a tester to overcome the following challenges:
- exploratory testing is an individual’s exercise
- difficulty to pass on the knowledge gained
- depends on the individual’s skills
- exploratory testing involves designing tests and executing them at the same time
- q-patterns can be created as you go along
- q-patterns list various ways that things could work, and suggests various alternatives
Some of the Problems with Q-Patterns
There are a number of problems with Q-patterns. For example, you can easily end up with a huge set of questions (some of which may not be terribly useful) for a minute widget in the software. The chances are that for a large complex system, the list of questions will be unweildy, and there may be many duplicate questions in various Q-patterns.
Another possible issue is – who is going to write all these Q-patterns? It’s all very well to identify a lot of generic bits and pieces, but is it worth writing the Q-patterns for them? A bit like reusable design and code – the first person designing or developing with reuse in mind doesn’t actually benefit (and it’s often more complicated to have reuse in mind from scratch), it’s those who reuse the design, code or tests who benefit.
Vipul would like to have different companies work together to prepare a repository of Q-patterns, for all to reuse. Sort of like a “QWikipedia” (DebiZ – I just coined that term!), but that just raises more issues: where would this repository reside? And what about each company’s IP?
And last, but by no means least, how does one ensure that test engineers working with Q-patterns don’t fall into the trap of stilted thinking?
I could go on quite a bit longer, but I don’t intend to explain a 4-hour tutorial in a sinlge blog post!
Suffice to say that I came out of the tutorial with an understanding of Q-patterns, and some of their strengths and weaknesses.
If you have any thoughts about Q-patterns, as I’ve explained them, I’d be interested to hear your comments.
If you enjoyed this post, please consider subscribing to my RSS Feed, to keep up with all future updates, like the 2nd new thing I learnt from Vipul during this tutorial …