ACT2LEAD is a leadership model for software testing that bundles eight principles as an acronym: Include everything, understand context, create transparency, connect two levels (automation and human), learning, promote test culture, adapt to risk and ensure diversity. It is aimed at all levels of the company, not just testers.
Key Takeaways
- Test culture does not develop by itself: Without someone actively bringing testing in at the leadership level and naming it over and over again, it gets stuck at the team level.
- The ACT2LEAD model summarizes eight principles, including context, transparency, learning, risk adaptation and diversity, which together enable an organization-wide testing practice.
- Automation and human testing are not mutually exclusive: Exploratory testing and creativity cannot be automated and remain essential.
- If you want to understand how software really works, you should ask the testers, because they are the only ones who have a complete overview of behavior, risks and actual functionality.
- CXO-level managers do not need to test themselves, but they need to know enough about testing to be able to actively mediate between business requirements and software development.
Leadership is missing in testing, not testing itself
The biggest deficit in software testing is not at team level, but above it. Teams usually test properly, they organize themselves, they deliver. What is missing is the leadership that anchors testing and quality throughout the company.
Kari Kakkonen describes a recurring pattern: “The higher up you go in a company, the less understanding you have of testing. At the top level, people know that testing is necessary. It is even demanded. But what testing means and how good quality is achieved remains unclear.
This leads to a simple thesis: the better someone understands testing, the better they can manage it. And the more he can expect good quality from his people and give them the space to deliver it.
Why autonomous teams alone are not enough
In a large company, it is not enough for each team to do its own testing. Autonomous teams are good, and Kari is an avowed advocate of them. The problem arises when each team does things differently and no one keeps track of all the software.
That’s why you need someone who is responsible for testing across team boundaries. This could be a Head of Testing. This role does not impose identical rules on all teams, but provides the bare essentials: a few general test policies that everyone follows.
Each team decides for itself what the specific implementation looks like. One way of doing this is through test communities in which people share their ideas with others who are interested in testing. What is meant is testing as an activity, not the tester as a person. Almost anyone can learn testing.
ACT2LEAD: a heuristic for test leadership
ACT2LEAD is an acronym that summarizes the most important elements of good test management in eight letters. The idea behind it is memorability: a short formula is easier to remember and implement than a thick guide. Each letter stands for a principle.
The following overview organizes the eight letters:
| letter | principle | core |
|---|---|---|
| A | Add | Think testing everywhere, not just in the code |
| C | Context | Testing depends on the context |
| T | Transparency | Making results visible instead of hiding them |
| 2 | Two (Automation + Human) | Automation and human together |
| L | Learning | Testing to learn and learning to test |
| E | Enable | Create a culture of quality |
| A | Adapt to risk | Align testing with risk |
| D | Diversity | Diversity in methods, people, approaches |
Add: Testing begins before the code
Testing doesn’t just take place when code is available. It starts with the budget for the software and the question of which provider you commission to develop it. This decision also includes the idea of testing.
Testing also extends beyond delivery. How do I run my software in production? How do I ensure that it actually works and how do I appraisal this? These questions are part of testing.
Context: Testing is never the same everywhere
Which tests make sense depends on the context. You need to understand the domain, the technology used, the team, the budget and the time pressure. Tests are selected accordingly, not according to a fixed scheme.
Transparency: don’t hide, make visible
Test work should be disclosed. Share test results, share errors found, address quality problems. Making quality visible increases the chance that everyone will pitch in.
Visibility does not mean flooding everyone with details. Key figures and defects are prepared for the respective audience, for example via dashboards that give a quick picture of quality.
Transparency is particularly important when several providers or suppliers are involved. It is then easy to draw boundaries and simply trust that the other party is testing its contractually agreed part. Instead of blindly trusting, it is important to make visible what is expected, what is delivered and what actually happens.
Two: Automation and people together
You need both automation and people. Even though the world is becoming more and more automated, from test automation to CI/CD pipelines, this is no substitute for real people.
Exploratory testing, creativity and new ideas come from people. The task of leadership is to find a way that suits your own situation and gives both their place.
Learning: testing in order to learn
You cannot know in advance what a piece of software really needs. You try it, and in the process you learn how it works and how you can improve your tests.
This dual movement is one of the strongest characteristics of the profession: testers understand the big picture. They think through software from many angles, in terms of risks, what it should do and what it actually does.
If you need to ask someone how this software works and what it’s all about, go to the tester. The tester has the big picture.
- Kari Kakkonen
Enable: Quality culture is a matter for the boss
The most important principle is E for Enable. Leadership creates the conditions under which good testing and good learning can take place. This includes talking about problems and learning from mistakes instead of assigning blame, on a daily basis.
The higher the level, the more important the repeated commitment becomes: testing is important, quality counts. No one expects a CEO to test practically. But he should talk about testing and quality and not delegate it to a single team.
Adapt to risk: more testing where the risk is high
Tests are adapted to risk. More testing in areas of high risk. This is the simple rule behind the second A.
Diversity: not the one best tool
Testing needs to be diverse, in every way. Different test methods, different approaches, different people, multiple vendors, multiple environments.
The frequent manager question about the one best option is misleading. There is no one best tool and no one approach for everything. Different perspectives complement each other, and only then can good quality be achieved.
Here is an example: If you stand in a cave with a flashlight and point it at one spot, you will see exactly that spot. He does not see the cave. It takes several angles to create the complete picture.
Why CTOs are worse at explaining testing than code
A common symptom clearly shows the deficit. If you ask a CTO what is tested in the company, the answer is often vague: probably test automation, a few reviews. That’s a start, but it’s not enough.
If you ask the same person what the developers or architects do, the answers will be more precise. They know that code is written, that version management is used, that there is Python somewhere and Java elsewhere. When it comes to testing, the answer remains vague.
This does not demonstrate unwillingness, but a lack of test knowledge at a higher level. And that is exactly what can be remedied.
How a manual for the CXO level is structured
The “Software Testing Leadership Handbook” written by Kari and his co-author Marko Rytkönen goes much deeper than the eight letters. In just under 300 pages, it bundles together everything managers need to know about testing.
The structure is based on questions rather than chapters. Those looking for answers often don’t know exactly what they need, but have a question. How do I make testing more diverse? How do I deal with test phases? How do I find testers? In this way, a busy manager finds the entry point via their specific concern, reads the summary and only delves into what concerns them.
How to go about testing was deliberately omitted. When writing, it was noticeable that parts became too technical and drifted towards testers. About half of the chapters were deleted because they did not fit the mindset and needs of the CXO level. Written for senior management, the book ultimately also works for test managers, testers and IT students who want to learn the basics.
