As a QA from the very beginning of one’s career it’s very common to hear in training sessions, meetups, conferences or daily stand-ups the infamous “Think like a user” / “Test as a user would do” concepts which usually connect to a series of pitfalls finishing up in poorly designed test cases, test coverage and, finally, wild surprises in the live product. Although, obviously, it is important to do so, QA professionals should definitely go way beyond that, and here’s why.
Abstracting the user
If you walk down the corridors of your company, you’ll probably notice at least a bunch of people talking about some mythical creatures: the users, describing whom they are based on the abstracted results of statistical, analytical or philosophical methodologies, from very different perspectives on the matter. One thing is clear: there’s still steps to be made to fully understand or predict the user and their exact (future) behavior.
Everything we know about the user remains just a subjective abstraction made using limited information at a certain point of time.
Andrei Alexandr. Danilov
As a QA, understanding this is critical because you’ll often find it together with defensive phrasing such as “The user won’t do that” / “This is an edge case”. The beauty is the coupling effect that the combination has: once the subjective abstraction of the user is torn down into pieces by the user itself in production, the edge case metamorphs into a high priority defect urging a hotfix release.
Abstracting the product
During the Software Delivery Lifecycle we also tend to over simplify our product to something I like to call a reflection of our product, in order to make the increments look simpler, cheaper and faster. Although this is expected, in combination with the pitfalls of abstracting the users, we can find ourselves swimming in similar problems. While preparing for tests or executing them, it is critical to understand and explain to stakeholders the following:
- Products evolve to satisfy new needs, so should our understanding about what we are building and how it is built. Great software of Big Tech has evolved from solving one particular need, to many. The way we do testing should reflect what can, and what can’t be done using our software, so Product Managers can set realistic expectations for future iterations of it.
- Products should be built to scale. While testing an API for example, one might argue that certain flows might not possible via the UI, which I label “The product is not used this way”, which might be valid in the present. What if your product iterates and will be used that way – allowing the integration of anyone with that particular API?
- Products can be multi-purpose. As QAs, we shouldn’t stick just to the reflection of the product, as defects can arrive from user flows not taken into account.
Where QA comes in
Either if we do the testing ourselves, or we coach development teams to do it, we should:
- Not be afraid to take forbidden paths: learn, explore the product and it’s increment and jot down any encountered error. Happy Paths usually work, and it’s not what we’re after.
- Give Product Owners and Product Managers visibility on the findings and the state of the software behind their product (what it can do, what it cannot, can it scale, etc), and consequently empower them to understand what kind of quality do they require for it
- Think as many users, not just as one. We’ll find much more.
- Challenge and go beyond the assumptions. They are called as such for a reason.
While it is important to take into account the abstraction of the user and the simplified product reflection, not going beyond that prevents us to add value to the environment we work in, which is the basis for any Quality Assurance activity.