Going lean on your testing approach
When teams are looking to transform, optimize, or cut costs in testing, where do they first look? More often than not, they follow the advice given...
Design Complex Systems, Create Visual Models, Collaborate on Requirements, Eradicate Bugs and Deliver Quality!
Product Overview | Solutions |
Success Stories | Integrations |
Book a Demo | Release Notes |
Free Trial | Brochure |
Pricing |
Our innovative solutions help you deliver quality software earlier, and at less cost!
AI Accelerated Quality Scalable AI accelerated test creation for improved quality and faster software delivery.
Test Case Design Generate the smallest set of test cases needed to test complex systems.
Data Subsetting & Cloning Extract the smallest data sets needed for referential integrity and coverage.
API Test Automation Make complex API testing simple, using a visual approach to generate rigorous API tests.
Synthetic Data Generation Generate complete and compliant synthetic data on-demand for every scenario.
Data Allocation Automatically find and make data for every possible test, testing continuously and in parallel.
Requirements Modelling Model complex systems and requirements as complete flowcharts in-sprint.
Data Masking Identify and mask sensitive information across databases and files.
Legacy TDM Replacement Move to a modern test data solution with cutting-edge capabilities.
See how we empower customer success, watch our latest webinars, read our newest eBooks and more.
Events Join the Curiosity team in person or virtually at our upcoming events and conferences.
Blog Discover software quality trends and thought leadership brought to you by the Curiosity team.
Help & Support Find a solution, request expert support and contact Curiosity.
Success Stories Learn how our customers found success with Curiosity's Modeller and Enterprise Test Data.
Documentation Get started with the Curiosity Platform, discover our learning portal and find solutions.
Integrations Explore Modeller's wide range of connections and integrations.
Curiosity are your partners for designing and building complex systems in short sprints!
Meet Our Team Meet our team of world leading experts in software quality and test data.
Our History Explore Curiosity's long history of creating market-defining solutions and success.
Our Mission Discover how we aim to revolutionize the quality and speed of software delivery.
Our Partners Learn about our partners and how we can help you solve your software delivery challenges.
Careers Join our growing team of industry veterans, experts, innovators and specialists.
Press Releases Read the latest Curiosity news and company updates.
Success Stories Learn how our customers found success with Curiosity's Modeller and Enterprise Test Data.
Blog Discover software quality trends and thought leadership brought to you by the Curiosity team.
Contact Us Get in touch with a Curiosity expert or leave us a message.
4 min read
Rich Jordan 23 May 2023 10:00:00 BST
You’re working hard to transform your ways of working, with a range of different goals. Common aims of digital transformations include:
Whatever your desired outcome, there’s one common problem that most (everybody really) ignores. Yet, overlooking this problem ultimately means that the initiative will fail, become delayed, cost too much, or generally become severely hampered going forwards.
This perennial (and perennially ignored) problem is “accidental complexity". This includes the accidental complexity already inherent in the way you make changes today, or the accidental complexity that you’ll introduce in future because of how you’ll choose to make change tomorrow.
“ While essential complexity is inherent and unavoidable, accidental complexity is caused by the chosen approach to solve the problem.”
Hugo Sereno Ferreira, "Incomplete by Design: Thoughts on Agile Architectures" (Agile Portugal: 2010).
Organisations rarely have the opportunity to start fresh when it comes to IT systems. Any agile transformation - which is fundamentally a move to small, iterative, emergent change - is completed within brown-field architectures. These inevitably have accidental complexity built-in.
This article sets out different symptoms of accidental complexity, discussing how they derail your transformation initiatives. My previous blog then offers inspiration for how you can solve this accidental complexity.
Because interfaces aren’t particularly well understood or documented, organisations are forced back to creating tests that focus on the user interface. This over-focus on UI testing is inefficient and costly, while undermining our ability to test early and iteratively. It further tends to low overall coverage, exposing systems to bugs.
Because the understanding of our system is at the e2e user flow level, we have a multiplying explosion of business logic:
This “combinatorial explosion” is complex beyond human comprehension, and is impossible to test against within a reasonable timeframe. In this scenario, the only way to achieve a valuable outcome in testing is to apply a risk-based approach. Yet, this is rarely recognised, or risk is based on an SMEs opinion of what is “enough” testing.
This combinatorial explosion multiplies complexity in your testing, but also in your ability to understand your systems. The problem simply becomes too big to understand. We are all taught to break problem down into smaller parts, but this seems to allude many test approaches.
The large volume of tests needed to traverse the multiple systems in e2e journeys proliferates the demand for test data. Test data becomes embroiled in complexity, not just because the data required for the test isn’t well understood, but also because of the systems of record for which these data items reside.
These systems are themselves under constant change, during which accidental complexity is playing its part. The systems are often poorly understood and poorly documented. Provisioning data for testing in turn isn’t the transactional request you thought it was. It risks massive complexity, massive labour, errors and bottlenecks:
The snowball of complexity continues to grow: Because I need e2e tests, I need e2e environments.
Testing and development in turn needs numerous channels, middleware and systems of record. Often these will be legacy (mainframe) systems that you can’t build overnight. In fact, organisations have often lost the ability and knowledge to build these systems from the ground up. As a consequence, our only choice left is to use the finite number of fully integrated e2e environments available in the organisation.
Yet, even one of these environments will cost millions in infrastructure alone, and the same multiple times over in resources to maintain. And that’s not the only problem. Organisation have many teams making change and they all need to test e2e. Teams queue for environments, creating a huge bottleneck that drains the organisation’s change budget.
A separation between what is being tested and how the system actually works will inevitably occur if you don’t have effective means to refactor what you are testing in line with what is being tested. Very rarely will you see a team talk about how they refactor test assets, because most don’t do it. This not only leads to test bloat, but creates outdated and invalid tests, and misalignment in what your test efforts cover.
The problems discussed so far are much more systemic than testing. Accidental complexity additionally stems from organisations and their structures. Challenges include:
The 3 ways of DevOps talk to Flow, Feedback and Experimentation/Learning. Flow talks to “Never allowing local optimization to create global degradation”. This should cause teams to rethink the way in which they approach change, but it rarely seems to [1].
This quote indicates the need for collaboration across teams. Such collaboration is blocked by the “pizza box sized team”, who carry on working in a silo, chuck their work over the fence, and find problems during large end-to-end integration testing events. Whilst a team can work in a silo as much as they can, they inevitably need to integrate the system they are working on with the rest of the organisation.
This choice of approach might have been taken as the path of least resistance to get started. It might even have been taken in the name of experimentation, or a “start-up” initiative within a larger organisation. Whatever the rational, it likely did not consider the accidental complexity such an approach creates or contributes to within the wider organisation.
You might see testing as the barometer of an organisation’s maturity when making change. If systems are testable, change is understood and observable. If quality and risk is discussed, you have a healthy eco-system. If all of this seems too hard, you will unfortunately continue down the increasing spiral of complexity.
“Culture eats strategy for breakfast”
Peter Drucker
Whilst no doubt you will recognise many of the points raised in this article, the biggest challenge isn’t knowing how to change, but rather wanting to change.
Many organisations work to a certain drumbeat. The innovators go off and get the latest tech, not yet realising they are just building the same problems with a flashier tool. Then you have the laggards who are stuck in a way of working from yester-year. They will say “we did agile before it was agile” and yearn to go back to a time when there was even less documentation and even less change or version control.
Each have some good practices, but both create more accidental complexity and optimise locally, not globally across the organisation. So how will you face into your organisations accidental complexity?
“Accidental complexity is when something can be scaled down or made less complex, not lose any value, and likely add value because it's been simplified.”
Kristi Pelzel, “Design Theory: Accidental and Essential Complexity” (Medium: 2022)
You can read Rich’s previous article, "Going Lean on Your Testing Approach", where he talks about how you might face into accidental complexity in your organisation, starting with getting your test approach right.
References
[1] Gene Kim, “The Three Ways: The Principles Underpinning DevOps” by Gene Kim (IT Revolution: 2012).
When teams are looking to transform, optimize, or cut costs in testing, where do they first look? More often than not, they follow the advice given...
Test Automation is vital to any organisation wanting to adopt Agile or DevOps, or simply wanting to deliver IT change faster.
It's a new year, and many of us in IT and testing are reflecting on how we can improve our processes and strategies. As we set our 2024 quality...
Using Function Point Analysis and model-based testing to objectively measure services. A perpetual challenge in managing software testing projects is...
IT change remains a persistent struggle for most organisations today. Software teams are aware of the need to move faster and be more agile; yet,...
“We mustn’t use live data for testing”. This is the reason why most organizations start to look at superficial solutions to certain challenges that...
In the dynamic, interconnected world of software development, clarity is key. Yet, requirements engineering - the process of defining, documenting,...
In many large organizations, software quality is primarily viewed as the responsibility of the testing team. When bugs slip through to production, or...
Welcome to part 2/5 of 5 Reasons to Model During QA! Part one of this series discussed how formal modelling enables “shift left” QA. It discussed how...