Getting into quality engineering: Bookend development
Getting into quality engineering: Bookend development
Moving into quality engineering means being more involved with development and engineering practices; something that can be very overwhelming and daunting to get started with. So where do we start as testers moving into this space? By bookending development (coding) and being a part of the start and finish of things.
Before coding: Driving what we want
We can drive quality engineering, before any development happens, through defining good Acceptance Criteria and a test plan for the work to be done. With a focus on quality engineering, teams will look to test as close to the code as possible, which usually means A FOCUS ON CONFIRMATORY SCRIPTED TESTS (CHECKING). This means we can help our team with what test coverage can look like through early risk analysis and defining ACs that cover more than just the happy path. These ACs can then be turned into close to the code tests with the confidence that more than just the happy path has been followed.
Using Acceptance Criteria to define your tests forms the basis of good engineering practices such as outside-in TDD.
We can also help teams to identify a test plan of what additional things will be covered (and how) before development starts. This could include integrations, end to end workflows and non-functional considerations that should be taken account of. Setting an expectation and plan for what and how testing will happen for a piece of work will help drive development efforts to include them from an engineering perspective.
After Coding: Code reviews
Once development has taken place, another way that we (as testers) can move into quality engineering is to support code reviews. The best way to start these is to PAIR WITH THE DEVELOPER TO WALK YOU THROUGH THE CODE asking them to talk through the logic of the code and what tests have been written. From there you can start to see if there are any gaps in coverage that you can recommend has a test added (perhaps a negative or an edge case).
This has the double benefit of both getting you familiar with code and how it looks, whilst also coaching the developer on testing practices for identifying possible test cases. Over time (when you’re more comfortable with code from pairing) you might start making reviews yourself and making comments and suggestions for the tests and their coverage.
By having well written Acceptance Criteria and a test plan defined (see above) we can use these to guide the support we provide in reviews by asking “how did we achieve and test for THIS?” It may be that additional test ideas come up as you look through the code together, make sure to be pragmatic and not advocate for testing everything.
What about during coding?
It’s very valid to want to engage and be a part of the development as it happens, possibly through pairing or ensembling. I usually recommend that it only really makes sense to do that if your team is practicing TDD and therefore wants ideas for tests as they’re developing. If they’re not using TDD then there’s a risk of becoming just additional noise and your collaboration and inputs failing.
One exception to this might be rubber ducking to help someone think through some logic for a tricky implementation. Being available to just talk the problem through, reframe and potentially ask some questions is a good way to support quality engineering practices.
Both of these are more mature practices for development, so might not be the best place to get started however.
When introducing yourself (and your team) to quality engineering; don’t be overwhelmed by trying to do it all. Focus on the value you can bring both before and after coding happens to provide clarity, context and a review of what’s being built.
