The tester’s role in software quality is about combining technical knowledge, critical thinking, and communication skills, while adapting to changing tools. Over roughly 25 years, the tools shifted from early test automation to model-based testing to AI, but the underlying need remains: testers provide the theory, architecture decisions, and judgment that tools cannot replace. AI assists; it does not substitute.
Key Takeaways
- Testers who use AI will replace those who do not, but AI itself will not replace testers, because testing theory, architecture decisions, and infrastructure thinking still require human expertise.
- The tester role has always demanded learning new tools every decade, from computer-aided test generation to model-based testing to AI, so the ability to learn matters more than mastery of any single tool.
- Communication skill is a core tester competency because delivering bad news about a defect requires framing it as a quality finding, not a personal failure or an attack on the team.
- A common vocabulary, not any single certification path, is the primary value ISTQB brought to software testing by aligning testers from different industries around shared terms and concepts.
- Critical thinking is the one skill AI cannot supply to a tester, and it remains the foundation on which every tool, technique, and automation approach depends.
The tester sits between development and testing, not opposite it
The divide between testers and developers has narrowed over the last 25 years, and the people who bridged that gap early were ahead of their time. Tibor Csöndes came into testing through a research background, building a test automation tool inside a telco environment. That position put him in the middle of two camps that used to see each other as separate.
He never fully felt the old contradiction between testers and developers, because his work connected to both sides. The tool he helped build sat in testing, but it touched development directly. Being the glue between the two parts was the work.
The idea of testers and developers working as one team is common talk today. Tibor was acting on it more than two decades ago, when the default was to keep the roles apart. Progress has been real, even if it is not yet true everywhere.
Why telco automated testing before other industries did
Telecommunications moved to automated testing earlier than most fields because the work demanded it. Twenty-five to thirty years ago, telco had well-defined protocol descriptions, and those precise specifications made automation the obvious choice rather than manual checking.
You can do a lot manually, but a clearly specified protocol is a strong case for letting machines run the tests. That clarity is what pushed automation into telco ahead of the curve.
This also shaped how a tester learned the craft. In a closed, protocol-driven industry, automation was not a luxury skill added later. It was part of the job from the start.
Three waves of test generation: CATG, model-based testing, AI
The promise of generating tests automatically has come around three times in one career, each time under a different name. The first wave, roughly 25 years ago, was called CATG, computer-aided test generation. It faded.
About ten years later, model-based testing arrived. It brought new tools and real learning, but it did not deliver what people expected. The theory behind the tools was too complex to push into industry, and large organizations struggled to adopt it.
AI is the third wave, and its advantage is reach. More testers can use it, it is easier to pick up, and it is more understandable than the model-based tools that came before.
| Wave | Rough timing | Why it stalled or spread |
|---|---|---|
| CATG (computer-aided test generation) | ~25 years ago | Came and went |
| Model-based testing | ~15 years ago | Tools and theory too complex to scale into large organizations |
| AI-assisted testing | Now | Wider use, easier to learn, more understandable |
The pattern across all three waves is the same. The tool gets better, but the tester still has to stand behind it.
AI will not take the tester’s job, but a tester using AI might
The honest line on AI and testing careers is direct: AI will not replace testers, but testers who use AI will outcompete testers who don’t. The threat is not the technology. It is standing still while others learn to work with it.
AI lowers the barrier that older tools raised. Instead of clicking through complex modeling tools, you can feed in requirements, reflect them with the AI, and build a model more easily than before. The work of understanding gets faster.
The thinking does not go away. Critical thinking stays central to the job, and you have to bring it to every task. AI may not actually know testing theory. You are the one who knows the architecture, what you want to achieve, and how to build the testing infrastructure.
So the division of labor is clear. The theory comes from the tester. The AI assists, writes scripts, helps finish the work. It helps, it does not replace.
What testers should learn now, split into technical and people skills
The most useful way to plan your learning is to separate the technical track from the people track. Tibor frames this as a people manager who gets the question often: what should I learn?
On the technical side, start with the basics. The foundation comes first, then knowledge of your industry, because where you work shapes what testing means. Learn automation, because automation keeps coming, and learn AI, because it can assist in nearly every case. If you work in a non-automated area, that is exactly where to push.
On the people side, communication carries real weight. A tester often delivers bad news, and you have to know how to do it well.
The bad news does not mean that you are the bad guy. Maybe you are the good guy who can find a real bug, which can destroy your company or your product later. — Tibor Csöndes
Personal skills and critical thinking round out the non-technical track. Testers tend to think in a similar way, which is why they recognize each other quickly: the habit of asking how to find bugs, applied to everything in life.
The ability to learn matters more than any single tool
The skill that outlasts every tool is the ability to learn a new one. Nobody knows what testing will look like in five, ten, or fifteen years. New languages, new tools, new techniques will arrive, and the only reliable defense is staying open.
Soft skills hold steady across this churn. Communication and critical thinking were needed before AI and are needed more now. The tools change every year, the way they always have, and you adapt to them the way you always have.
This is why learning has to be continuous rather than a one-time certification. The Hungarian Testing Board and ISTQB both treat ongoing improvement as the norm, not an extra.
A current example is an AI-based tool tied to ISTQB practical testing. You learn inside the tool, the AI corrects you as you go, and when you feel ready you take the exam in the same place. The AI helps you learn faster and more efficiently, but the tester, the critical thinking, and the open mind sit behind it.
ISTQB’s biggest contribution is a common language
The single most valuable thing standardization gave testing is a shared vocabulary. When Tibor started, there were separate groups: testers, developers, different industries, all doing some form of testing without common terms. The ISTQB standard gave them one language.
Today everyone knows what a test strategy is and what a test manager does. That shared meaning is the main thing, more than any individual syllabus.
The standard keeps moving. ISTQB now offers specialist modules, so you can go deep in the direction closest to your work. People also come into it from very different industries, which is part of the value.
Tibor came from telco, a closed field with its own acronyms and a theory built on telecommunication protocols, shaped by bodies like ETSI. Joining ISTQB revealed how much of it matched what others did. The words and acronyms differed, but the underlying ideas were the same.
Community is the real engine, not just the conference
Testing knowledge grows fastest through community, and the structure around HUSTEF treats community as the point rather than a side effect. More than ten people from the Hungarian Testing Board staff the booths and run the conference, and the same spirit shows up in the ISTQB working groups.
The board contributes across many working groups and reviews. A large share of reviews comes from it, and that output comes from a country of fewer than ten million people. A small nation can still build one of the strongest communities in the field.
The membership path is built to pull people in gradually. The first level is open to anyone who wants to belong to the community.
- Community: Open to anyone. You get added to the mailing list and receive requests for projects, translations, or reviews.
- Step-by-step involvement: Through those tasks, you learn and grow more active.
- Full member: Over time, you can become a full member of the board.
The plan reaches beyond the conference too. A testing hackathon, a “testathon,” is being discussed as a way to draw in people who would not otherwise attend a conference or join a standardization group, but who would happily build test automation through the night because it is fun.
A small country aiming to be everywhere testing happens
The long-term ambition is straightforward: when someone in Hungary says software testing, the answer should be the Hungarian Testing Board. The vision for the next five to ten years is to be present wherever testing is.
HUSTEF is the public face of that ambition. Tibor places it among the top three conferences in Europe, and the goal is to keep going and grow more international rather than rest on that standing.
If you want in, there are two clear moves. International testers can submit to the HUSTEF call for papers and attend. Anyone in the region can join the Hungarian Testing Board at the open community level and find their way deeper from there.
