Flow as a testing activity
Flow is a state of mind. A psychological condition of being fully immersed in a feeling of involvement. It’s commonly referred to as “On a roll”, “to be on fire”, “Getting your groove on” and my favorite “Going beast mode”.
There’s a lot to read about this concept and most of it is very interesting to us testers. However, treat it as a heuristic, as we should most concepts. While a lot of principles about the idea apply to testing, some don’t match. I will explain on this further on.
I simulate this mindset by going into seclusion for an hour or two, connect my earphones and turn on a good Pink Floyd album. This conjures up a feeling of well-being for me and gives me the opportunity to have a 100% focus on the system before me, no sidetracks to anything else than the product. (sidetracks inside the system are highly recommended!)
It is possible to go in to great detail, create wonderful test ideas, analyze specific functions and test extremely efficient.
Doing this kind of testing usually gets great results. If you don’t experience the returns you would expect, you need a different approach. Go talk to a developer and get some needed insight for example.
While being wired in you can easily forget to stop. There are a few indicators on when to stop your testing session.
- The feeling of diminishing returns
- You don’t get surprised anymore
- Your timing is done
- Other features require your time and energy more
- …
Pitfalls of Flow
“The hallmark of flow is a feeling of spontaneous joy, even rapture, while performing a task although flow is also described (below) as a deep focus on nothing but the activity – not even oneself or one’s emotions.”
Pasted from <http://en.wikipedia.org/wiki/Flow_(psychology)>
Emotions, feelings, self-awareness are very needed aspects while testing. Keep these constantly in mind while being in a state of flow. Do not lose these out of sight for you might miss important signals if you do.
Conditions to achieve flow:
– Goals are clear
– Feedback is immediate
– A balance between opportunity and capacity
Pasted from <http://en.wikipedia.org/wiki/Flow_(psychology)#Music>
These conditions are not necessary to achieve a testing flow. You might want to learn about the product, catch bugs, gather test ideas or much more or everything at once. Feedback doesn’t need to be immediate, but generally is.
When testing a completely new system the opportunity is always overwhelmingly larger than capacity. The tester diminishes this feeling of being overwhelmed by using heuristics such as equivalence partitioning, but still, the options are infinite.
Flow as an aspect of Project Management
Probing the product in a state of flow is one way of going about testing. I see this concept in a different way as well.
Remembering the project management triangle used in many PM methodologies I found that Flow has a place in the
triangle.
As a tester your time should be apparent. You have X time to test the product.
Cost should be kept to a minimum. Testers are quite frequently seen as a cost or a necessary evil. It is our responsibility to show this misconception to be wrong.
Scope, however, is a fickle thing for any tester. Sure, you could start testing your requirements. Create a test case or a couple for every requirement in the list and flag off passed/failed. While this is by no means a complete testing strategy, it has been the nominator for way too many projects. As any tester knows: for every non-trivial system ,the testing possibilities are infinite.
A professional tester makes intelligent and skillful decisions to decide scope.
Some of these decisions can be made before starting the actual testing. But most are made while feeling out the project, product and while gathering information about what’s at hand. It is influenced by how you experience the process of “testing the waters”. What you see in the project, how you are responded to by your peers, by management, what you have learned about the product, how it is documented, how responsive the developers are,…
So, when have we covered enough scope? Here’s where I think Flow is an important indicator.
It has been described as “the feeling of diminishing returns” or “the piñata heuristic”.
In short, “you stop hitting it if there aren’t coming enough bugs out of it anymore”.
Have you completed your scope? No? Do your Testing sessions give you enough return on investment? No? Can you bring yourself to go into the flow state with the product? No?
To me, that’s an indicator to go test something else, your work here is done…
For the moment.
Isle of IT 