🤔Delicate Topics. I've managed to turn my passion into my profession - productivity and reliability in software teams. While the work is very fulfilling, there is also a degree of repetition in where to start with groups wanting to go faster/safer/happier.
I believe these new teams facing old challenges can help themselves immensely by starting foundational conversations before needing help to dig out of a productivity decline.
This is a three-part post. After 15 years and 50+ software teams, the top things I wish I had learned sooner and still apply today are:
Software testing - QC for speed, QA for scaling.
Going Serverless-first. It's easier to make simple things complex.
Engineering Culture - choosing the best improvements.
Part 1: Quality assurance or control?
Testing the software change has to be part of implementing the change. Manufacturing calls these in-process checks quality control. In construction, it’s just part of the job. Handing the work to someone else to test it kills flow and, over time, becomes increasingly ineffective as a control. Similarly, expecting a constrained pool of people to constantly regression test entire systems while scrutinising new changes leads to burnout, unstable releases and customer frustration.
These statements are nothing new. Test-driven development (TDD) is software's version of quality control and has been around (or rediscovered) since 2003. Youtube, Stackoverflow, and most software forums can explain its benefits and how to go about it. It's a game changer for both productivity and reliability.
And yet….in 2022, it's still common to see teams and individuals who are nowhere near ready to implement TDD. In my experience, what's holding them back is not the technologies and techniques but more subtle role expectations change barriers.
The general theme I see is teams confusing or conflating Quality Control with Quality Assurance. I learned the difference between controls and assurance in an early career in Electronics manufacturing, where controls were designed and evolved by a QA team working with engineers and then implemented by the machines building the products. The machine that builds the machine, as Elon puts it.
In software teams, ideally:
QC for speed. Controls (aka test automation) are best implemented and run along with the changes.
QA for scaling. QA teams improve the effectiveness of controls, focus on emerging risks and hazards, and support the teams to scale through coaching and pairing.
The unspoken worries 🤫
So what’s holding back the adoption of test automation and TDD? Here are the repeating situations the team and I have encountered over the years and some tactics to unlock them.
1.“If the engineers do the testing, what will the QA people do?”
Short answer - heaps of more valuable stuff. This concern can also trigger dedicated Assurance and Automation team members to worry that 'it's my job to check the quality'.
Quality is a lot broader than just testing. As in the Electronics factory, while an individual in the team, such as a QA, may be accountable for quality, the entire team is responsible, especially for testing. The QA skeptical, analytical mindset people are more effective in a coaching role with Engineers and focusing more at either end of the delivery process - design, precision release controls and operational health to feedback into planning and design.
In pursuit of agility and customer expectations, modern systems have increasingly harder to understand and test. We need QA skills more than ever to better prepare for and manage inevitable failures, disruptions and unexpected behaviours.
2."I shouldn't test my own work."
This Engineer/Developer attitude is often a mask for skills gaps, unclear role expectations or lack of domain knowledge, e.g. “I don't know how to test that I haven't broken anything”. Perhaps they lack automation experience, or there is no test harness in place, and they don't want the burden of creating it. Also, check for role expectations - are we employing code writers or Engineers who build and own services? Regardless of these barriers, the best person who made the change is the best to check it’s doing what’s intended. Ensuring it hasn’t broken anything else is a team (automation) effort.
3.“Well, no one else is writing tests in here, so why should I?”
The Broken windows situation. When working in large older systems with low or no test coverage, it's easy for individuals to continue the status quo. These systems normally lumber on until a point of crisis - e.g. a series of major incidents, that make the team realise they need to slow down to speed up. Often this necessitates a sponsored project or goal to implement the automation foundations of a test harness to support testing on all future work.
The hardest bit is starting. Consider getting the team to agree on the critical user flow(s) and getting some automation coverage of these areas first.
4.“We don't have [time/money] to test.”
Considering quality control automation as low-value or optional work is common in agency/outsourcing situations with tight profit margins or one-off implementation projects. This is understandable - to an extent. However, if the system is to be worked on repeatedly over months and years, implement the automation controls early. They will pay for themselves over time as changes continue, but the people making them come and go.
For the home teams and outsource partners alike, using opinionated reusable templates with testing built-in helps a lot here. Time savings on repeat work or similar work with new clients can recover the initial investment. These accelerators amplify delivery capacity in teams where Engineers have to move across multiple projects or have high staff turnover. Observing delivery and reliability metrics can help justify the quality investment if it is a stable team.
5. “You can’t put automation testing on this system.”
Sometimes this is valid. The very architecture or design of the system is indeed a barrier to test automation. Years of compensating with manual testing or low change activity have enabled unhelpful design patterns and system dependencies to grow.
Some modernisation or significant refactoring may be required. There is likely also an automation experience gap that has contributed. As with 2, starting with regression coverage of the most critical user flows will tease out the pressing architecture and dependency problems. For each one, the wider community has likely come up with workarounds and transition architectures that can be applied to unlock modernisation.
Getting help 🤝
Apparently, there are ~27 million software developers in the world! Regardless of the barriers, for teams or individuals struggling with the change to and adoption of test automation, others can help pass on their experience and expertise. We are an industry of problem solvers and naturally try to solve things ourselves (been there, done that), but why bother solving solved problems?
Changes like this can be sensitive to a team, so when looking for help, look for technical experience and empathy for the non-technical barriers.
Does any of this strike a cord?
Originally published on LinkedIn.
Comentarios