We testers generally follow (even when we wouldn’t want to) a custom of making assumptions about the product under test. We are smart enough to reckon things by ourselves (Our rich oracles maybe, or maybe not?), so anything which is unfamiliar to us has similarity to something else and we end up assuming. Incomplete knowledge plus the mirage of ‘I know how things work?’ leads to assumptions and false assumptions lead to the incorrect approaches of testing which in turn leads to situations where what looks like a bug is actually a requirement or vice versa.
Making shots in the dark about the product without complete information can lead us to serious problems (You ask ‘like..?’ You know that already, don’t you?). A tester should be aligned to the client’s thought process & should know what things the client wants to be implemented.
We are expected to be confident about the bug we raise or the improvement we recommend. So is a tester allowed to get confused when with the dev & the product team? Obviously No.
A story:
Last week I went to a cafe which is quite famous for its authentic flavor of Italian pasta, it’s a famous eatery for foreign tourists. To my over-enthusiasm (and hunger) – what happened next was very saddening. The pasta served to me was unsavory and bland. I blamed the cafe for serving tasteless Pasta and thought that their quality is unpromising (and probably inconsistent). Coming back home I realized that it is not the cafe rather my taste buds, which are customized to the desi (Indian) style of Pasta. This is a classic case of assumptions, where what I assumed was a bug was, in fact, the expected behavior. My assumptions were wrong as their requirement was Pasta’s original authenticity & not my desi expectation.
We have to understand that a product’s behavior depends on the requirements, not on our assumptions. While testing a Banking app for one of the projects, ‘Customer ID’ fragment was missing in the app. I thought it’s a new requirement as we were already maintaining a different unique ID for each customer and so I did not raise that issue whereas it was later found to be a critical bug. Why didn’t I cross-check with the dev team about the fragment being missing? Maybe because I assumed that the app is anyhow working fine without that fragment too.
Questioning and understanding all the product requirements should be done with utmost care. We should be clear enough to distinct between the requirement and the assumption. We should always highlight to our client, the set of assumptions we made while testing. We can even include it in our Daily Reporting. Sometimes assumptions help us in stepping into a user’s shoe and find recommendations.
An assumption of a user can sometimes be a recommendation for the product and so it becomes very important to note our assumptions and convey them to the customer, this helps both ways, If it’s a wrong assumption – it gets cleared, If it’s a right assumption but not included in the app yet – it becomes a recommendation.
Written By: Himansha Tyagi | Exploratory Tester
