by Andro Cobarrubias –
A scorpion and a frog meet on the bank of a stream and
the scorpion asks the frog to carry him across on its back. The
frog asks, “How do I know you won’t sting me?” The scorpion
says, “Because if I do, I will die too.”
The frog is satisfied, and they set out, but in midstream,
the scorpion stings the frog. The frog feels the onset of
paralysis and starts to sink, knowing they both will drown,
but has just enough time to gasp “Why?”
Replies the scorpion: “It’s my nature…”
Fable of the Scorpion and the Frog
Are your QA teams doing mostly manual testing? Are your QA teams doing zero or minimal unstructured UI automation?
First off let me be clear. Testing itself is not going away. Not by a longshot.
With the emergence of Agile and the rising adoption of DevOps, the traditional, assembly line way of testing is disappearing. Soon to be gone are the days when testers just derive test cases from requirements, manually execute tests, and then report defects and status. There will be pockets of this culture persisting – especially for organizations who by choice or due to specific circumstances cannot change fast enough.
Not simple by any means. It’s neither a matter of just flipping a switch nor buying a suite of tools.
There is no “silver bullet”.
To continue denying the inevitability of the need to change will eventually result in a QA organization’s irrelevance. A paradigm shift of this magnitude necessitates commitments from all levels – from management to staff. Even if the status quo allows the team to get by and deliver, this culture is not sustainable and will eventually crack as the pressure to deliver speed@quality increases exponentially.
Budget, laissez faire development approach, organizational dysfunction, infrastructure bureaucracy – there can be a myriad of issues that are beyond the QA organization’s control. It is unrealistic to believe all or even one can be eliminated quickly. At the very least, these blockers must be worked around or controlled to a degree that DevOps minimum requirements can be implemented:
If a situation is so toxic that the only way to even get started is to take theoretically unsound shortcuts and thus do a half-baked implementation, forget it.
If there is no other option but to plow through it – taking the fatalistic view of hoping for the best, forget it.
Neither approach will simply fix an already exacerbated and onerous situation.
In order to achieve acceptable speed@quality, the QA team’s skills need to be retooled. Let’s focus on full stack test automation – from automation component testing to automated UI testing. The increased frequency of test execution mandates Test Automation – it is impossible to have economies of scale without it. (Manual testing will still be needed for certain test types such as Usability testing – just not as a much).
Test Case Design skills will always be a must. Usage and application of testing techniques such as Risk-based testing, Equivalence Class Partitioning, and Pairwise testing just “shift left” (i.e. happen earlier in the development lifecycle).
Organizations must invest in developing this skill set and the current team must be willing to be taught. If not, then they need to be reassigned or replaced – brutal and cold as that may sound.
Decentralization – assigning specific testing resources to specific Development areas – is the trend and in the context of Agile and DevOps makes sense.
However, such a move must be supported by an independent lean QA organization – not the heavily staffed Testing Centers of Excellence (TCOEs) that had previously been the go-to structure. It may be 1 person or 5 and depends on how large an organization is required to accomplish:
The degree of control the QA organization has depends on how far along the company is on its DevOps journey. For a relatively immature organization or for those that may have regressed due to a failed attempt at Agile, a helping hand is definitely needed.
I’m not a fan of the big bang, “shove it down people’s throat” approach. This is too risky with little margin for error and a narrow window for rolling back. Choose a low risk yet high profile enough project to act as the “guinea pig”. Strictly monitor and adjust as needed. Better to make the mistakes on this small scale. Only once the operational aspects have stabilized and the level of risk is reduced to an acceptable level can planning be started on a wide scale rollout.
“Change or Die” – That’s the main title of Alan Deustchman’s insightful book on change. Can’t be any clearer than that.
QA organizations must change or risk being made obsolete and supplanted.
Don’t. Be. The Scorpion