In this article I outline why I believe it should not be mandatory for all code changes to go through QA before they are merged to a master branch and released.

1. Signing off on Quality
In this article I outline why I believe it should not be mandatory for all code changes to go
through QA before they are merged to a master branch and released.
First we have to outline some assumptions that form the foundation for this discussion.
● Everyone in the team cares about the quality of the product, and takes personal
accountability and responsibility for their own work
● Everyone in the team has sufficient skill/ability to know what they don’t know [1]
● Everyone in the team wants the team to be as efficient as possible, and support each
other to achieve that
So why shouldn’t QA sign off on every code change, to ensure that we have the best quality we
can have, and as few bugs as possible slip through?
● If QA is signing off on every code change, that takes time that they could spend on
something else - the alternative cost can be significant
○ This can be solved by staffing up with more testers, but as we will see it is not
efficient, so it is not an advisable course of action
● We create unnecessary delays/increased lead times in three different scenarios
○ When there is no need for a tester to look at the change
○ When QA becomes a bottleneck and code changes have to wait for the sign off
○ If the QA sign off causes developers to not perform basic testing of their own
code change at all because they rely on testers to do it for them, then code
changes may unnecessarily ping pong between developer and tester
● If testers sign off on every code change, there is a risk that this moves ownership of the
quality of the code changes from the team, to testers specifically
○ If a bug is found in the live product it is the tester’s fault for not finding it during
sign off, and the rest of the team is not accountable/responsible for it
So if we don’t want QA to sign off on every code change - what does the process look like, and
how do we ensure high quality in our releases?
1. A developer makes a code change and follows whatever process is in place with regards
to unit tests, static testing, code reviews etc.
2. The developer then (or before parts of step 1) does basic (or simple/clear [2]) tests (or
checks [3]) if necessary/possible
3. If the developer feels confident enough that their code change is of high quality, then it is
merged to master
4. If the developer feels that the code change is complex [2], doesn’t have the right test

2. tools or test knowledge, or feels uncertain for any other reason, the developer asks a QA
specialist for support
5. The QA specialist does an analysis and performs necessary additional testing on the
code change on the development branch and provides the results in a visible and
transparent way to the developer
6. The developer can then decide if they want to merge to master branch, or if other actions
are necessary
So who is accountable/responsible for what in this setup?
● The developer is accountable/responsible for that their work, the code change, meets
defined standards
● The QA specialist is accountable/responsible for that their work, the tests performed,
meets defined standards
● The team as an entity is accountable/responsible for the overall quality of the product
But what happens if every code change is complex, or every code change requires specific
testing tools or test knowledge? Then a QA specialist will be involved in every code change. In
this specific case, from the outside, the process would be almost identical to if QA signed off on
every code change, but accountability and responsibility would still be different, and every
involvement from the QA specialist would be deliberate, and not an unnecessary step.
The main point here is that the developer needs to be able to assess complexity and risk with
their code changes, and when to involve QA or not.
● You need to be able to assess with some degree of certainty when there is no, or almost
no, risk or complexity
○ In which case you merge without QA involvement
● You need to be able to assess when there is significant risk or complexity
○ In which case you involve QA
If you cannot make these assessments, then QA will need to be involved in every code change,
but as mentioned above, it will be deliberate, and accountability and responsibility is clear.
Even when QA is involved with every code change, they are not signing off on the quality of
those code changes, but they do take accountability and responsibility for their work, and their
involvement is deliberate and meaningful.
Johan Hoberg

3. References
[1] Dunning-Kruger Effect
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
[2] Cynefin Framework
https://en.wikipedia.org/wiki/Cynefin_framework
[3] Testing and Checking Redefined
https://www.satisfice.com/blog/archives/856