Leaving it late

I don't typically set goals, and don't share them. But next year is potentially a big one. For me personally, by the time MoTaCon rolls around, I'll have had my 60th birthday, and I'll celebrate by...

Architectural diagrams are visual maps, or blueprints, that show how a software system is put together. They highlight the key components, how they connect, and how information flows between them. You don’t necessarily need every tiny detail of the system. The value comes from seeing the structure clearly enough to understand the system, ask relevant questions, identify potential risks or gaps, and understand how changes and data might travel through the system. A helpful diagram makes the often invisible visible. It shows where the complexity lives, where bottlenecks might appear, and which parts of the system you’ll want to explore, test, or monitor more closely. A diagram can play an important role in understanding a system's testability. Whether the diagram is a simple sketch on a whiteboard in a meeting to help a discussion or decision, or a formal diagram in a tool, the goal is the same. A shared understanding of the system that supports teams making smarter quality and testing decisions.

Software architecture is the high-level shape, or blueprint, of a software system. Architectural decisions, existing circumstances, or context constraints lead to a set of decisions that define how the parts, or components, fit together, how they communicate, how data is used and flows, and how the system evolves, changes, and stays reliable over time. Architecture, most often viewed via architecture diagrams, gives us the big picture so we can make smart choices about design, testing, performance, security, and where the risks sit. You don’t need to know every detail to benefit from understanding architecture. Even reading and understanding a simple view of the main components, their responsibilities, and the data flows can help you ask better questions, spot gaps earlier, and plan testing that aligns with how the system actually works.

A/B testing is a controlled way to roll out a new software version to a subset of users so you can monitor real-world behaviour and limit its use while you gather valuable information about user interaction. Through this technique, you can learn which version of the software is more successful or more liked by users.Sometimes called an A/B release, it means you ship two versions of your product and route traffic so some people see the old version and some see the new one. Think of it as a staged rollout with built-in measurement, so you can stop or roll back quickly if the new version causes bugs or does unexpected harm. It is a broader experimentation method that compares variants to learn which performs better.A simple example of an A/B release:You want to change the checkout flow on an e-commerce site, but you are worried about payment failures. You release the new checkout to 10 per cent of live traffic while 90 per cent keep the old flow. You monitor payment success rates, error logs, and customer support tickets for that 10 per cent, and if problems arise, you halt the rollout and fix the issue before increasing exposure. This is an A/B release because the goal is a safe rollout and operational control, not a pure hypothesis test on conversion rates.Here are some practical tips when considering using A/B testing. Keep the metrics you watch simple and relevant to safety and user value. Automate rollback triggers for obvious failure modes, and treat the rollout as a learning loop where customer reports and small qualitative notes matter as much as conversion numbers. The two main uses are protecting customers and systems, such as in the e-commerce payment example.  And when you need a clear answer to a product hypothesis of what will work best. E.g a button that says 'buy now' and one that says 'special offer'.

This is the code-and-release side. It includes updates to features, bug fixes, configuration changes, infrastructure tweaks, deployments, and anything that alters how the product behaves. Managing these changes well means making risks visible, validating assumptions, testing early, and ensuring releases move through a predictable, safe path into production. In many places, this is done by tickets and committee discussions, informed by information and risk analysis. The greater the risk in industries like finance, medicine, and aviation, the more likely the process will be highly formal.When done well, it should be seen as a way to bring clarity and shared understanding, so teams can move faster with fewer surprises. If done poorly, it can be overly complicated, cause delays and frustration, and add costs. When we handle change intentionally and well, whether it’s how we work or what we ship, we build trust, reduce risk, and make quality a natural part of our delivery.

This is the people-and-process side. It covers shifts in team structure, new ways of working, changes in organisational priorities, and the introduction of new tools and practices. These changes affect how we think, communicate, and collaborate. Good environmental change management helps teams understand what’s happening, why it matters, and how it will affect their day-to-day work. It reduces friction, builds confidence, and gives everyone space to adapt.

Change Management is the structured way we help changes land safely and sensibly, rather than leaving teams to deal with surprises. It comes in two main flavours, and both matter if we want to build and deliver quality consistently.

A matrix organisation is a company structure where people belong to more than one part of the organisation at the same time. Typically, a functional group (engineering, design, testing, data, etc.) and a product, programme, or project team. Instead of a single hierarchy, the organisation is arranged as a grid or “matrix,” allowing skills to move to where they’re most needed.Matrix organisations usually use matrix management to coordinate this dual structure. It’s designed to help companies stay adaptable when dealing with complex products, multiple regions, or rapid scaling. You’ll find matrix structures in large, multi-disciplinary organisations, or where collaboration across teams and specialisms is essential. Some organisations have used and discarded this method due to slower decision-making, role and priority ambiguity, and even power struggles.Working in a matrix organisation means navigating shared ownership, competing priorities, and sometimes conflicting feedback. But when it works well, it gives people a strong home for their professional development while keeping cross-functional teams empowered to deliver real outcomes. When it doesn't work well... watch out.

Matrix management is a way of organising people so they report to more than one leader at the same time. Instead of having a single, straight-line manager, you might have one manager responsible for your professional skills (like testing or design) and another responsible for the product or project you’re currently working on. It’s a structure built for flexibility. Teams can form, reform, and adapt as priorities shift.Matrix management is commonly used inside matrix organisations, where work cuts across functional boundaries. You’ll see this approach in companies that need to balance specialist expertise with fast-moving delivery. Think of big global tech firms, where an engineer might sit in a central discipline group but spend most of their time embedded in a product team.For testers and quality engineers, matrix management usually means having two voices guiding your work. One focused on how you grow your craft, and one focused on what you deliver with your team. Success comes from clarity, communication, and not being afraid to surface tensions when priorities pull in different directions. The challenge is creating an environment safe enough for that to happen, or else divided or conflicting priorities, communication breakdowns, and cognitive overload, amongst other things, can cause major problems.

Ethical testing is about doing the right thing while testing software, not just checking that it works. It focuses on how test activities affect people, their data, and society, especially when software is used at scale. It asks questions like who could be harmed, whose data is being used, and whether the system behaves fairly and responsibly in real life.At a practical level, ethical testing requires careful handling of data. PII or Personally Identifiable Information data should be anonymised where possible, not copied around environments “just for convenience”. Synthetic data is often a better choice for testing, as long as it reflects the parameters and boundaries of real users, as it allows teams to explore edge cases and risks without exposing real people’s information. Clear data retention policies also matter. Test data should not live forever. It should align with regulations such as GDPR and standards like ISO 27001, so teams know what data they hold, why they hold it, and when it should be removed.As software increasingly shapes everyday life, ethical testing goes beyond simple compliance. It represents a commitment to societal responsibility and to building systems that help rather than exploit. Modern testers and Quality Engineers need to be familiar with ethical frameworks such as IEEE 7000 and emerging regulations like the European Union Artificial Intelligence Act, and be able to turn those principles into concrete test activities. Ethical testing is about making values visible in the work, and ensuring quality includes the impact software has on real people.

Personally identifiable information (PII) is data that can be used to find or identify a real person. Either when used on its own or combined with other details. This includes the really obvious things, like names, email addresses, phone numbers, and national identification numbers. But also the more obscure ones, such as someone's IP addresses, their location, identifiers for their devices, or even account IDs if they can be linked back to an individual.From a software quality and testing perspective, PII matters because it changes what we test, the environments we create, and could influence our processes. Using real PII in test systems inherently increases risk, even when the intent is good. Data leaks, misuse, or accidental exposure often happen in non-production systems where controls are weaker. Treating test environments as “safe” is a common mistake that could lead to serious issues later.Good practice is to avoid using real PII wherever possible. Randomising or making parts anonymous are good options. Masking, or using made-up or machine-generated data, allows teams to test behaviour and edge cases without putting people at risk. Clear retention policies also matter. If there is no good reason to keep the data, it should not be there.Understanding what counts as PII helps testers and Quality Engineers ask better questions. What data are we collecting? Why do we need it? Where does it flow? Who can see it? PII is not just a legal concern. It is a quality concern, because quality includes trust, safety, and how responsibly software handles the people behind the data.