Thursday, 11 September 2014

Exploratory Testing And Test Coverage

Test coverage while exploratory testing needn't be limited to one or more of the below factors:
-Test ideas matching the requirements
-Test ideas matching a tester’s skills
Let us explore the other options to provide test coverage when:
-The requirements are not yet available or are incomplete, which usually is the case in an agile way of working with frequent changes being made to the product.
-There is not yet a certain way to map the requirements with the test ideas generated.
-When a tester does not know, if the test coverage provided is enough / sufficient to the ask of the product owner / business.
Many may differ by the mention of enough / sufficient coverage by ruling out with an answer that the test cases match the requirements. In such a case, have you as a tester ever been questioned: “Why was this not tested?” And what was your answer?
The answer, “I have provided test coverage as per the requirements gathered” help you get away from answering further questions related to test coverage?
If not, proceed.
Tester’s skills and test ideas, I would like to think are directly related.
Should a tester, stop providing test coverage at this? No.
When I was at the Selenium Conference, Pradeep Soundararajan spoke to me about providing test coverage when exploratory testing and he provided another insight to my learning.
-Having a list of ideas to refer from can help test those ideas in areas in which a tester may not be proficient at.
-Having this list prepared / modelled prior to the beginning of testing is essential and can help match the test coverage with the test requirements.
Having said this, who will prepare / provide / decide the relevance of test ideas – Everyone in the team. Because as we all know and now need to put it into action “Quality is everyone’s responsibility”. Not just an individual’s.
Next time you are encountered with the question : Why was this not tested?
Gather sufficient evidence and answer the below questions:
-If the requirement was raised to include a particular functionality?
-If the same functionality was/is built into the code?
-If test coverage was provided as part of testing this functionality?
-If the test ideas were reviewed?
Was it tested and Why was it not tested? is definitely not the first question in this series as we now notice.
How else can one benefit from testing beyond one’s own skills and by not stopping at matching the test ideas with the test requirements?
I have tried to answer this question below:
I am currently working on building the mind map factory at my work place.
Mindmap factory houses mindmaps, set of test ideas to refer from when testing.
This helped open up more opportunities to learn. And how? This exercise helped me identify areas in which I am proficient and the areas in which I needed to work upon.
There was a concentration of ideas in certain areas and there was less in certain other areas.
I got in touch with other learners in areas that I needed to improve upon.
We got to pair test and in turn add to our learning. How often do we do this?
It is essential to spare time for learning as we work which can only boost our and the product’s performance. Weekend test environment is yet another place where we can learn from many.
I am an expert, do I need to pair test?
Yes, an expert / guru could be adding to other’s learning and can learn a thing or two from many others.
I witnessed this recently when I was a participant at CAST conference, the testing guru’s pairing up with other fellow learners and co-presenting or getting their work / presentation reviewed and asking for feedback post a presentation are a few examples of how we can learn from everyone.
When the community itself is accepting of learning, why as a company / firm be away from such a culture? Embrace learning from others, learning with others and participating in a product’s development as a team.
I stress upon the fact which I also emphasized at the Selenium Conference held in Bangalore from September 5th – 6th.  ‘Stop asking for permissions to do things(work/learn) which are in your ability to do’. Take decisions about your learning without the influence of others. Stop at nothing.
Conclusion:
We testers need not limit our test ideas to requirements or an individual tester’s skills.
Originally published here: TestBrewer

No comments: