ACT2LEAD is a leadership model for software testing built around eight principles: Add testing to everything, Context-driven decisions, Transparency about quality, Two-sided testing (automation and human), Learning through testing, Enable a quality culture, Adapt to risks, and Diversity of approaches. The model argues that testing must be actively led at the organizational level, not left to individual teams alone.
Key Takeaways
- Testing leadership is missing at the senior level in most companies: management knows testing must happen but cannot explain what it actually involves, unlike their understanding of development or architecture.
- The ACT2LEAD model structures testing leadership into eight areas: add testing to everything, context, transparency, automation and humans, learning, enable quality culture, adapt to risks, and diversity.
- Enabling a quality culture (the E in ACT2LEAD) requires senior leaders to speak about testing and quality constantly, not delegate responsibility entirely to development teams.
- Large organizations need a dedicated testing leader, such as a head of testing, to set minimum standards across teams, because autonomous teams each handling their own testing in different ways is not sufficient at scale.
- Good testing requires diversity in techniques, people, approaches, and environments, because no single tool or method covers all the angles a complex software product demands.
Why software testing lacks leadership
Most companies manage testing at the team level but rarely lead it. Teams plan their work, run their tests, and organize themselves, and at a grassroots level that often works well. What is missing sits one floor up: someone who creates the conditions for good quality and builds a culture where strong testing can happen.
Kari Kakkonen has seen the same pattern repeat across his career. Climb high enough in an organization and you find people who know testing must happen but cannot say what it actually involves. They might write “you need to test” into a requirement, then leave it there, unexamined.
The gap shows up clearly when you compare questions. Ask a CTO what the developers do, and the answer is precise: they write code in Python here, C there, Java somewhere else, they handle the architecture. Ask the same person what the testers do, and the answer thins out to “I suppose they run some test automation and do some checks.” That vagueness is the symptom of missing testing knowledge.
The more you understand testing, the better you can lead it
Leadership in testing depends on understanding it. You do not need to know every technique in detail, but you need enough to be active in the relationship between running a business, commissioning software, and getting that software built and tested.
This is the core argument behind the ACT to LEAD model that Kari developed with co-author Marko Rytkönen. The name is a heuristic, eight letters, each standing for one principle. It is built to be remembered and implemented, not filed away. The point is to get testing onto the agenda across the whole company, not only inside testers’ daily routines.
A senior leader is not expected to run tests by hand. They are expected to talk about testing and quality, repeatedly, and to refuse to let it sink into being one team’s private responsibility.
What the ACT to LEAD model covers
ACT to LEAD spreads testing thinking across budgeting, vendor choice, production, and team culture, instead of confining it to the moment code arrives. Each letter names a working principle.
| Letter | Principle | What it means |
|---|---|---|
| A | Add testing to everything | Consider testing when you plan a budget, pick a supplier, and operate software in production, not only when code is ready to check. |
| C | Context | Testing differs by business, domain, technology, team, money, and time pressure. Choose your testing to fit the context. |
| T | Transparency | Make testing visible. Share what you do, what you find, and where quality is weak, so others can help. |
| 2 | Two: automation and humans | You need both. Automation and pipelines keep growing, and you still need human creativity and exploratory testing. |
| L | Learning | Test to learn how the software works, and learn to test better. Both directions matter. |
| E | Enable | Create the conditions where good testing can happen and a quality culture can hold. |
| A | Adapt to risks | Put more testing where the risk is higher. |
| D | Diversity | Use many techniques, approaches, people, suppliers, and environments. |
Add testing to everything, not just the code
Testing starts long before code exists. It belongs in the budget conversation, in the decision about which supplier or vendor builds your software, and in how you plan to operate the product once it runs in production.
Each of those moments carries a testing question. How do I make sure this works? How do I check it in production? How do I confirm it actually does what it should? Treating testing as a phase that begins when code lands misses most of where the thinking is needed.
Context decides what good testing looks like
Testing is not the same everywhere. The right approach depends on the business, the domain, the technology, the team, the budget, and whether you are in a hurry.
Context-driven testing means choosing your methods to match those conditions rather than applying one fixed playbook. There is no universal best technique waiting to be selected. What works in one setting can be wrong in another.
Why transparency beats trust between vendors
Transparency means doing testing visibly and sharing the information widely, instead of trusting silently that other parties do their part. When you find defects or hit quality problems, surfacing them gives everyone a chance to pitch in.
The risk grows when several stakeholders, vendors, or suppliers work together. Boundaries form easily. Each party does its piece, a contract defines who tests what, and the rest disappears behind “let’s just trust them on that.” Transparency replaces blind trust with visibility: what you require, what you get, and what is actually happening.
Visibility is not the same as flooding people with data. Dumping every metric and defect causes information overload and defeats the purpose. The work is to aggregate, to fit the information to its audience, and to build dashboards that make quality easy to read without hiding anything.
You always need automation and humans
Testing needs both automation and people, never one in place of the other. The pull toward automation is constant: more test automation, more delivery automation, more CI/CD pipelines. That is useful, and it is not enough.
Human testers bring exploratory work, creativity, and new ideas that automation does not generate. Your job is to fit both into your own context, because each covers what the other cannot.
Testers learn the software more deeply than anyone
If you need one person to explain how a piece of software works, ask the tester. Testers tend to be broad rather than narrow. They learn the whole product, where each part fits, how it should behave, and how it actually behaves.
That breadth comes from the work itself. A tester needs the full picture to do the job, having examined the software from many angles and against many risks. Learning runs in both directions: you test to learn the system, and you learn how to test it better as you go.
Enabling a quality culture is the leader’s real job
The most important principle is enabling: building the circumstances where good testing happens. Make testing well an expectation. Make it normal to talk about problems and failures, to learn from them, and not to blame people for them.
This is largely about repetition from the top. The higher you sit in a company, the more it matters that you keep naming testing and quality as things that count. A CEO will not be testing by hand, but a CEO can keep quality in the conversation rather than handing it down as a team’s lonely duty.
For many companies, this is a real cultural shift. The easy path is to say “we have some testers, they do what they do” and move on. Breaking that habit is the change worth making.
Adapt to risk and keep testing diverse
Base your testing on risk. High-risk areas get more focus and more testing. The principle is simple, and applying it keeps effort where it does the most good.
Diversity sits just behind enabling in importance. Use multiple techniques, multiple people, multiple approaches, multiple suppliers, multiple environments. Different angles support each other, and together they produce better quality.
If you would ask one person, how does this software work, what is this software all about, you actually should go to the tester, because the tester has the big picture.
Kari Kakkonen
A manager’s instinct is often to ask for the single best choice: the best tool, the best approach, automation for everything. Quality does not come from one angle. Think of a flashlight in a cave. Point it at one spot and you see that spot, not the cave. You need several perspectives to see the whole.
Who owns testing leadership in a large company
Large companies need a role responsible for testing, such as a head of testing. Too often the CTO is a former architect, developer, or business person, which is fine, but someone still has to make sure testing happens across the whole product.
Autonomous, self-organizing teams are valuable, and Kari backs them. Yet if every team handles its own testing in its own way, that is not enough at scale. The head of testing role is not about being “in charge” in a controlling sense. It is about making sure testing happens everywhere the software is built.
The practical tools are light. Set general testing guidelines that give minimums rather than dictating identical rules to every team: do at least this much, then find the ways that fit your team and context. Support that with testing communities where people share ideas. The word is testing, not testers, because testing is something anyone can take part in.
A leadership handbook built from questions
ACT to LEAD is laid out in full in the Software Testing Leadership Handbook, written as a set of questions rather than chapters to read front to back. The format matches how busy people actually search: you rarely know the exact answer you need, but you know your question. How do I make testing more diverse? How do I cope with testing terms? How do I recruit testers?
The book runs to almost 300 pages and goes well beyond the eight letters, which serve as the entry point. It was written with a CTO or CXO-level reader in mind, someone who can read a summary, then deep-dive into the one worry they have. It deliberately leaves out hands-on testing instruction. During writing, chapters that drifted toward technical, tester-level detail were cut, roughly half of them, to keep the focus on leadership thinking. What remained turned out to serve test managers, testers, and even IT students as well.
