How to Test Before Code is Written
You might have heard of “shift left” when it comes to testing.
You might have heard of the numerous virtues of testing early because it’s much cheaper to find a bug early in the SDLC compared to just before you go live.
But exactly how do you do that? What may this process look like?
Here I share a few concrete, practical ideas on how to contribute as a tester, before code is written:
Get Invited to Those Meetings
You can’t contribute to the discussions you are not part of. Depending on your work context, this can be easier said than done.
If you have colleagues who have benefitted from having testers involved in discussions early, you’re probably already invited to these meetings.
But if you work with people who only see testing as something that is done later in the process, you’ll need to take action here.
Tell people you want to be part of feature discussions as you have some ideas that would help the team.
If you get push back in the forms of “oh you don’t need to be there” or “it’s only for developers” or even my favourite “it’s too technical for you”, then say you would like the invite anyway - you can always skip meetings where you feel you won’t provide any value.
When Reviewing Requirements Take Time to Process Your Thoughts
Ideally, you shouldn’t be shown a requirements document, or series of user stories in a meeting, without first being given access to it so you can first digest and reflect.
If you get a meeting invite where you’re asked to have a discussion around a requirements document, ask for access to it first. This gives you the opportunity to go through in it your own time, highlight areas that are unclear etc.
Repeatedly Clarify Understanding
In my experience, problems don’t just come from a lack of requirements or bugs being written that directly contradict the expected behaviour, but they come from different interpretations.
You can have (what one believes is) a clear requirement - but it can be interpreted multiple ways.
Therefore where things seem to be ambiguous, ask questions about what exactly they mean by X.
For example: A logged-in member cannot create events, unless they have the authority.
I would then ask:
- What do we mean by authority?
- What other user types do we have aside from “member”?
- What else can do we with events? Can logged-in members edit or cancel events for example?
Use Examples to Get on the Same Page
An effective way to ensure you and others are on the same page is to use examples. Often, people don’t even realise they have different understandings of what a requirement means or how a feature should be implemented.
Using examples helps you bridge the gap.
For example: A logged-in member cannot create events, unlessthey have the authority. I would then walk everyone through a few scenarios (examples) of how this requirement could be implemented and then ask people to interrupt me if I have misunderstood anything.
Think About Consistency
I think one of the most useful heuristics at this stage are the consistency heuristics by Michael Bolton.
In this blog post, I shared my most used test heuristics that can be applied here.
An important thing to watch out for here is consistency within the documentation and existing areas of the system.
The inconsistencies may not be blaringly obvious - again clarify understanding.
Ask About Testability
It saves everyone a lot of time if you ask “how can we test this as early as possible?” early in the process.
It pays off to think about testability early.