Skip to main content

Search...

Will AI replace the test engineer?

From carpenter to agile engineering coach: How a career change and a book about system testing sparked an entire career in testing.

9 min read
Cover for Will AI replace the test engineer?

The transition from craftsman to software tester is successful if you consciously use existing strengths such as accuracy and quality awareness and acquire new knowledge in parallel with your work. The ISTQB Foundation Level provides the technical basis for this. AI tools such as ChatGPT do not replace testers, but take over routine tasks, provided you actively learn how to use them.

Key Takeaways

  • Those who do not deal with AI will be replaced, those who use it will not: Rudolf Groetz uses ChatGPT on a daily basis, but warns that results should always be critically reviewed and adapted.
  • The ISTQB Foundation Level provides the tools for agile testing: concepts such as equivalence partitions and decision tables also help with test design in Scrum teams.
  • Automated routine activities such as the manual checking of Excel lists will be taken over by AI, while complex quality assessments of requirements coverage will remain a human task.
  • Rudolf Groetz founded the Testbusters community in Vienna six years ago, which now has around 1,500 members and connects testers from all over the world in remote meetups.
  • The New Voices format gives people without stage experience a protected space for their first presentation, because entry to traditional conferences is blocked by high requirements for titles and abstracts.

From carpenter to tester: why lateral entry in IT works

A completed trade does not exclude an IT career, it can even support it. Rudolf Groetz is a trained carpenter, with a journeyman’s certificate, before becoming an operator, Cobol developer, database administrator, system administrator and finally software tester.

The change began with a television program around 1985, which asked: Will we still need craftsmen in the future if machines take over everything? Groetz applied the question to his own profession and decided to learn something else before robots replaced carpenters.

He started parallel to his full-time job. From seven to five at the workbench, then from 7 to 10 p.m. IT courses at the Wifi, tasks in the evening until sometimes three in the morning, then back at the workbench the next morning. His first course was called “Computer Basics”, where he learned bits, bytes, MS-DOS, Supercalc and Turbo Pascal.

The lesson learned: a career change into IT is possible even without a traditional course of study if you are prepared to study hard and in parallel. The craft does not necessarily disappear. Groetz still runs a workshop in his own home and builds pallet furniture, which he takes apart, planes and reassembles.

How can you recognize the “tester gene”?

A flair for testing is evident even before someone has the title of tester. Groetz noticed it during a consulting assignment: He was asked to write training materials for a piece of software, looked at the program for 50 minutes and then declared that it was unusable in its current state. The developer was stunned that he hadn’t found the errors himself.

Groetz describes this feeling in concrete terms: “He sees immediately if a point is missing somewhere. He knows when he looks that nothing will happen at a certain point when he clicks. He recognizes a dead link or a missing image before others come across it.

He traces the root to his origins. His father comes from Berlin, where precision and punctuality were part of everyday life. Groetz calls himself, half tongue-in-cheek, a “Prussian quality official”. Anyone with this kind of flair has a foundation on which to build testing expertise.

Why certification has its place despite criticism

ISTQB certification is controversial, but its foundation of knowledge is useful. Groetz knows both sides: He has worked on ISTQB syllabuses and exam questions for the Austrian Testing Board and has taken his own path through Foundation Level, Technical Test Analyst, Functional Test Analyst to Test Manager, much of it self-taught via syllabus and self-study.

His argument has nothing to do with the paper. It’s about the knowledge behind it. Anyone who designs tests will make faster progress if they know what equivalence partitions are. Anyone who breaks down business rules works more cleanly with a decision table.

Just as every child learns to read and write, every tester should have this foundation level. Rudolf Groetz

He himself mentions one exception: Anyone who has been in the profession for 30 years knows these basics anyway. For beginners, on the other hand, Foundation Level knowledge is the common language, especially in an agile environment.

AI does not replace testers, but routine

Artificial intelligence will change the job description, but it will not do away with testers. Groetz sees the change at a clear boundary: AI replaces activities that are standardized. Checking Excel lists for validity, transferring columns to other columns, repetitive processing. Tasks like these will become narrow.

The core business of testing remains. Even if a language model generates code for a Cypress test case on demand, it still needs someone to write the prompt. And someone is needed to check whether the result fits together and whether all requirements have been implemented.

Groetz is very clear about who will be affected: “People who are not involved with AI will be replaced. Those who are involved will remain in the game. It is interesting to note his assessment that the pressure is more likely to hit the developers than the testers.

How AI actually helps in everyday testing

AI is a tool for preparatory work, not a finished result. Groetz uses it regularly: for examples in training courses, for test planning, for agile test schedules. When he designs a new training course, he first spends half an hour talking to the language model and has an agenda put together.

In the end, the raw result is never one-to-one. It has to be refined and adapted, some statements are simply not correct. Anyone who accepts the AI output without checking it and sells it as good is acting negligently.

Groetz honestly names one open flank: the testing of the AI itself. He has the impression that some answers have not been tested at all. He considers the approach of regulating AI more strictly and steering it within sensible boundaries to be authorized.

He summarizes the principle behind it in one sentence: work smarter, not harder.

Communities are created when someone fills the gap

If the community doesn’t provide anything, you have to build it yourself. This is exactly what Groetz did six years ago with a test automation meetup in Vienna, which now has around 1,500 members. The event series is called Testbusters Night.

A second meetup was added around two years ago. A test automation group in Kiev was lying idle and the members asked Groetz to take it over and give it new impetus. He opened up the focus from pure test automation to topics related to engineering.

The format changed from face-to-face to remote with coronavirus. The effect: easier to organize and more reach. Today, the network extends to testers in Peru and Australia. The topics follow the demand of the members, currently AI, autonomous testing, model-based test automation, synthetic test data and the testing of Lambda functions in Amazon.

New Voices: first stage for newcomers

Conferences require titles, abstracts and often a trial talk, which keeps newcomers away. Groetz has experienced this problem himself and has built an answer with the “New Voices” format: People who have never stood on a stage before are given the opportunity for their first talk, whether physical or virtual.

An example from his own community shows how well this works in a network. A young man from Vienna asked a speaker at a conference in Holland for advice on how he could get started. The answer: In Vienna there is Rudi Groetz, who offers exactly that, give him a call. His first presentation will be about how he brought AI into his company.

Learning works better with people than with a syllabus

Effective training focuses on the learner, not the curriculum. At Raiffeisenbank International, Groetz works as an agile engineering coach and has introduced the “Agile Learning Guides” format for this purpose. Instead of working through the syllabus, the person learns what they need by learning by doing, accompanied by a guide.

The background is a recurring phrase. Many people come and say they want to learn test automation, but don’t know where to start. This is exactly where mentoring, guiding or coaching comes in.

Traditional multi-day training courses often fail in practice. Managers need the person in the team, three days’ absence in a row is not an option. Around 90 percent of the courses are therefore e-learning, which is well received according to Groetz.

The Testbusters Learning Lab arose from the same observation. At schools such as BFI and Fortitude Vienna, students are mainly taught development, C and C++, agile methods, while testing is neglected. Several students asked Groetz where they could learn testing skills, as many job advertisements require them. The lab started with four people and a first learning sprint, evaluated according to the Inspect and Adapt principle.

How to stay on the ball as a tester

Curiosity plus daily routine beats one-off major campaigns. Groetz takes ten minutes over coffee every morning to check his streams: Is there anything new, is there anything on the topic that he should look at? He follows up on what’s interesting, and leaves what’s not.

This filtering often results in more than just learning. It often leads to an idea for a presentation and the question of who from the community could speak on a topic.

For beginners, the advice can be summarized in two points:

  • Build up Foundation level knowledge, not for the sake of the certificate, but to be confident in the basic concepts.
  • Stay up to date and be curious, with a fixed, small daily routine instead of infrequent training sessions.

Groetz specifically mentions current fields that deserve this curiosity: automated testing as well as low-code and no-code approaches and the question of how to bring them into play in a meaningful way.

Share this page

Related Posts