ACT2LEAD is a model for test leadership that packs eight principles into one acronym: Add testing everywhere, understand the Context, create Transparency, combine Two sides (automation and people), keep Learning, Enable a culture of quality, Adapt to risk and ensure Diversity. It is written for every level of a company, not only for testers.
Key Takeaways
- A testing culture doesn’t grow on its own. Unless someone brings testing to the leadership level and keeps talking about it, it stays stuck at team level.
- The ACT2LEAD model sums up eight principles, among them context, transparency, learning, adapting to risk and diversity, which together make testing work across an organization.
- Automation and human testing don’t exclude each other. Exploratory testing and creativity can’t be automated, and teams will always need them.
- If you want to know how a piece of software really works, ask the testers. They are the ones with the full picture of its behavior, its risks and how it actually works.
- Executives at CxO level don’t have to test themselves, but they need to know enough about testing to mediate between business requirements and software development.
Test Leadership Is What’s Missing, Not Testing
The biggest gap in software testing isn’t at team level but above it. Teams usually test properly, organize themselves and deliver. What’s missing is test leadership: someone who anchors testing and quality across the whole company.
Kari Kakkonen sees the same pattern again and again. The higher you go in a company, the less people understand about testing. At the top, everyone knows testing has to happen. They even demand it. But what testing means and how good quality comes about stays vague.
That leads to a simple thesis: the better someone understands testing, the better they can lead it. And the more they can expect good quality from their people and give them room to deliver it.
Why Autonomous Teams Aren’t Enough on Their Own
In a large company, it isn’t enough for every team to handle its own testing. Autonomous teams are a good thing, and Kari is a firm supporter of them. The trouble starts when every team does things differently and nobody keeps an overview of the software as a whole.
So someone has to be responsible for testing across team boundaries. That can be a Head of Testing. The role doesn’t force identical rules on every team. It sets the minimum: a few general testing guidelines everyone can work from.
How that looks in practice, each team decides for itself. Test communities help here, where people share ideas with others who are interested in testing. That means testing as an activity, not the tester as a job title. Almost anyone can learn to test.
ACT2LEAD: A Heuristic for Test Leadership
ACT2LEAD is an acronym that fits the key elements of good test leadership into eight characters. The point is to make it memorable: a short formula is easier to remember and easier to apply than a thick handbook. Each character stands for one principle.
Here is how the eight characters break down:
| Letter | Principle | Core idea |
|---|---|---|
| A | Add | Think about testing everywhere, not only once there is code |
| C | Context | Testing depends on the context |
| T | Transparency | Make results visible instead of hiding them |
| 2 | Two (automation + human) | Automation and people working together |
| L | Learning | Test to learn, and learn to test |
| E | Enable | Create a culture for good quality |
| A | Adapt to risk | Align testing with risk |
| D | Diversity | Variety in methods, people and approaches |
Add: Testing Starts before the Code
Testing doesn’t only begin once there is code. It starts with the budget for a piece of software and with the choice of which vendor builds it. Testing belongs in that decision, too.
Testing also goes beyond delivery. How do I run my software in production? How do I make sure it actually works, and how do I check that? These questions are part of testing as well.
Context: Testing Is Never the Same Everywhere
Which tests make sense depends on the context. You need to understand the domain, the technology, the team, the budget and the time pressure. Tests are chosen accordingly, not by a fixed scheme.
Transparency: Show It, Don’t Hide It
Testing work should be out in the open. Share test results, share the bugs you found, raise quality problems. Making quality visible raises the chance that everyone pitches in.
Visibility doesn’t mean flooding everyone with details. Metrics and defects are prepared for each audience, for example through dashboards that give a quick picture of quality.
Transparency matters most when several vendors or suppliers are involved. It is easy to draw lines and simply trust that the other side tests its contractually agreed part. Instead of trusting blindly, make visible what is expected, what is delivered and what actually happens.
Two: Automation and People Together
You need both, automation and people. Even as more and more gets automated, from test automation to CI/CD pipelines, that doesn’t replace real people.
Exploratory testing, creativity and new ideas come from people. Leadership’s job is to find a way that fits the situation at hand and gives both their place.
Learning: Test to Learn
You can’t know in advance what a piece of software really needs. You try things, and along the way you learn how it works and how to improve your tests.
This two-way movement leads to one of the profession’s greatest strengths: testers understand the big picture. They think software through from many angles, in terms of risks, of what it should do and of how it actually behaves.
“If you need to ask someone how this software works and what it’s all about, go to the tester. The tester has the overview.”
(Kari Kakkonen)
Enable: A Culture of Quality Starts at the Top
The most important principle is E for Enable. Leadership creates the conditions in which people can test well and learn well. That includes talking about problems and learning from mistakes instead of assigning blame, every day.
The higher the level, the more the repeated commitment matters: testing is important, quality counts. Nobody expects a CEO to do hands-on testing. But they should talk about testing and quality and not hand them off to a single team.
Adapt to Risk: More Testing Where the Risk Is High
Testing follows risk. Areas with high risk get more testing. That is the simple rule behind the second A.
Diversity: There Is No Single Best Tool
Testing has to be diverse in every respect: different test methods, different approaches, different people, several vendors, several environments.
The manager’s favorite question about the one best option leads nowhere. There is no single best tool and no one approach for everything. Different perspectives complement each other, and good quality only comes from combining them.
Think of standing in a cave with a flashlight. Point it at one spot and you see exactly that spot. You don’t see the cave. Only several angles together give you the full picture.
Why CTOs Explain Testing Worse Than Code
One common symptom shows the gap clearly. Ask a CTO what gets tested in the company and you often get a vague answer: probably test automation, a few reviews. That’s a start, but it isn’t enough.
Ask the same person what the developers or architects do, and the answers get more precise. They know code is being written, version control is in use, there is Python here and Java there. When it comes to testing, the answer stays rough.
That doesn’t prove unwillingness. It shows a lack of testing knowledge at the top, and that is exactly what can be fixed.
A Handbook for Test Leadership at CxO Level
The “Software Testing Leadership Handbook”, written by Kari and his co-author Marko Rytkönen, goes much deeper than the eight characters. In close to 300 pages, it collects what leaders need to know about testing.
It is organized around questions rather than chapters. People looking for answers often don’t know exactly what they need, but they do have a question. How do I make testing more diverse? How do I handle test phases? How do I find testers? A busy executive starts from their specific concern, reads the summary and only goes deeper where it applies to them.
How to test was left out on purpose. During writing, some parts became too technical and drifted toward testers. About half of the chapters were cut because they didn’t fit the mindset and needs of the CxO level. Written for the executive floor, the book turns out to work for test managers, testers and IT students who want to learn the basics as well.
Frequently Asked Questions
What is the biggest shortcoming in software testing within companies?
It’s not at the team level, but above it. Teams usually test thoroughly, organize themselves, and deliver results. What’s missing is leadership that embeds testing and quality throughout the entire company. Kari Kakkonen describes a recurring pattern: The higher up you go in the hierarchy, the less understanding of testing you find. Testing is expected, but what testing actually means remains unclear.
Is a central role for testing necessary when teams work autonomously?
Yes, as soon as the company is large enough. Autonomous teams make sense, but if every team takes a different approach, no one maintains an overview of the entire software. A role such as Head of Testing doesn’t impose identical rules, but rather sets forth just a few general test policies. Each team determines the specific implementation on its own, for example through exchanges within testing communities.
What does the acronym ACT2LEAD stand for?
ACT2LEAD brings together eight principles of test leadership: Add (incorporate testing into every decision), Context (testing depends on context), Transparency (make results visible), Two (automation and people), Learning (testing to learn), Enable (creating a culture of quality), Adapt to risk (aligning tests with risk), and Diversity (diversity in methods, people, and approaches). The purpose of this short formula is memorability: it sticks in your mind better than a thick guidebook.
At what point in a project should testing be considered?
Well before the code is written. Testing begins with the software budget and the decision on which vendor to hire for development. Testing must be factored into these decisions as well. Likewise, testing does not end with delivery: How the software is operated in production and how its functionality is verified there are also part of the process.
Does test automation make human testers obsolete?
No. Both automation and people are needed, even though more and more processes, from test automation to CI/CD pipelines, are becoming automated. Exploratory testing, creativity, and new ideas come from people and cannot be automated. The manager’s task is to find a balance for their specific situation that gives both their due place.
Who should you ask if you want to understand how software really works?
The tester. They are the only ones with a complete overview because they analyze the software from many angles: in terms of risks, expected behavior, and actual behavior. This overview arises from the dual nature of testing: you test to learn how the software works, and in the process, you learn how to improve the tests.
Do CXO-level executives need to be able to test themselves?
No. No one expects a CEO to do hands-on testing. However, they should know enough about testing to actively mediate between business requirements and software development, and they should regularly address testing and quality rather than delegating them to a single team. The higher the level, the more this repeated commitment counts.
Is there a single “best” testing tool or the “right” test approach?
No, and managers’ frequent questions about the “best” option are misleading. What’s needed are different testing methods, different approaches, different people, multiple vendors, and multiple environments. Here’s an analogy: If you shine a flashlight on a single spot in a cave, you see only that spot, not the cave itself. Only by considering multiple perspectives can you see the complete picture.
