Same tester, writing same test automation - yet the impact this tester makes on quality is entirely different. Sound like potential for framing the test automation investment in a way that gives up relevant parts of its value. So let me explain.
A colleague has been offered three different client projects, and in all three she will work on test automation. This made it clear: the choice where the client(s) place her make a difference on the results the client will experience out of test automation.
The three options are:
-
Same team with developers
-
Testing services team
-
Client side team
Imagine you had full control over the choice of where you place your new pair of hands on testing / test automation, what is the impact of the setup? The bottom line:
If you are close to fixes, your testing does not just verify - it also impacts what flows forward in the overall efforts.
In the same team with developers:
- For timely feedback, timely fixes! Likelyhood of timely feedback is up by knowing exactly what change is going on right now.
- Significant impact on quality: Fast fixing, test results guide development, quality improves continuously (making testing also easier)
In the testing services team:
- The handoff frequency is by design, but often attention of tester is split to multiple teams
- Fixes find their way to the next iterations
- Medium impact on quality: Fixes with delay, test results with delay, slower improvement
In the client team:
- Fixes made separately, and some feedback delayed to change framing for users and automation efficiency
- Inclined to prioritize for later, future
- Requires client reaction to improve quality, protects the knowledge client expects to have
For years, I have been pitching this:
When you invest in quality, push the investment into automation directly where the system is being built (or broken). On client side, ask for ability to run this test automation.