There are so many different IT projects out there – that assuming every IT project is about source code is quite a blind spot. Projects that deal with commercial standard systems or outsourced software might have source code underneath – but many teams does not have access to the source. Additionally, many legacy systems from the 90’es and older does not have the same automation capabilities as we have now.
Not all software projects are about consumer facing native apps and websites. While they are numerous there’s still plenty of systems out there for internal and business-to-business use. While the trends from CI/CD are picking up for B2B and internal systems, things doesn’t move so fast.
State of Testing 2020 : Systems, Technologies, Development and Testing Models
So when someone talks highly of Testability, Observability and building code-based test automation – or even as I talk about the benefits of RPA – there are some underlying assumptions. Assumptions of a specific code-base, assumptions of an architecture, assumptions of the test team…
To many (testing) people the terms: Observability, Testability, Modern Testing Principles and the learnings from the Accelerate book – are visions or goals, at best. They are great goals to strive for – again, it’s the learning, not the lesson. Even the Spotify model once highly hyped is not considered an idealistic model from back in time.
I appreciate that the authors of “Accelerate” has but this up-front, that their research and examples are based on: “multiple examples of applying these practices within mainframe environments, traditional packaged software application delivery teams, and product teams“.
I wish other practices and models would do the same – I’ll try my part.