Teaching software testing at university means combining practical lab work with just enough theory to make the practice meaningful. Courses built around test automation tools like Selenium, API testing with Postman, and performance testing engage students faster than test plans alone. Complexity increases gradually, AI tools are permitted but examined critically, and real failure cases from industry give students a concrete reason to care about software quality.
Key Takeaways
- Introducing test automation and performance testing before test plans keeps students engaged because they experience what testing does before learning what it is called.
- Students using AI tools like ChatGPT to write automation code is not a problem to block but a skill to develop: the course responds by raising exercise complexity to match the faster pace.
- Codeless test tools are not truly codeless, because complex scenarios still require custom code, which means knowing how to write and evaluate code remains a core skill for testers.
- Graduated difficulty in lab exercises, where early tasks are easy enough to score points immediately, builds motivation that carries students through harder stages later in the course.
- Assigning students to research real software failures and present them to classmates, rather than to the lecturer, creates healthy peer competition and makes the cost of poor quality concrete.
Why teach automation and performance testing before test plans
Test plans make little sense to someone who has never seen a system break. That is the reasoning behind a software testing course at Vilnius University, where Dmitrij Nikolajev rebuilt the curriculum around hands-on work first and theory second.
When Dmitrij took over the course, it leaned heavily on written artifacts. Students were asked to produce test cases and test plans on paper. He saw a mismatch. Asking a junior to write a test plan produces little of value, because a test plan is shaped by context the student does not yet have.
The fix was to invert the usual order. Instead of starting with documents, the course starts with tools and tasks. Students meet the concept of a test case by being handed one and told to automate it. The definition follows the doing, not the other way around.
This matters for the audience. Roughly one third to one half of these third-year students already hold IT jobs, some as testers, most heading toward developer or engineering roles. A purely theoretical course would lose them. Practical work that mirrors real situations keeps them engaged and gives them something they can use the next day.
The course is built in three practical blocks
The five-month course rests on three areas of hands-on work: automation, performance testing, and API testing, with a limited touch of security testing on top.
Automation comes first. Students write scripts against provided test cases and are pushed into less obvious situations, including setting up orchestration. The complexity is deliberately above a beginner’s comfort zone, so they grow into it rather than coast.
Performance testing comes next, and it carries a clear message: breaking things is not enough. Students plan the work. They build operational profiles, set up monitoring, and look for the weakest links in a system. The point is not chaos but evidence about where a system fails under load.
API testing forms the third block, focused on REST APIs and the frameworks around them. Security testing rounds it out in a smaller dose, using a deliberately vulnerable practice project so students can probe weaknesses in a safe setting.
Here is how the three blocks map to what students actually produce:
| Block | Focus | What students do |
|---|---|---|
| Automation | Test cases in action | Write automation scripts, set up orchestration |
| Performance | Behavior under load | Build operational profiles, monitor, find weak links |
| API testing | REST and frameworks | Test REST APIs, work with common frameworks |
| Security (limited) | Known vulnerabilities | Practice on a deliberately vulnerable project |
Reward the small wins to keep students moving
Motivation in a technical course can be engineered the same way you train behavior: reward good actions early and often. Dmitrij draws this directly from his experience in dog obedience training, where positive reinforcement drives progress.
The course applies it through gradually rising difficulty. The first lab exercises are easy to score on, so students earn points quickly and feel the payoff. Each later session builds on the last and gets harder. Some students stop short of the highest score, but the early wins pull most of them forward.
The same instinct shapes the lectures. A room of 21-year-olds loses focus after about an hour of a 90-minute slot. You can see it in their eyes. So Dmitrij interrupts with puzzles, sometimes on a slide, sometimes physical, to reset attention before continuing.
Theory still has its place, but it is paired with practice so students see why it exists. As the practical work unfolds, the underlying concepts are explained in context, which makes them stick better than a standalone lecture would.
How to teach testing when students lean on ChatGPT
Banning AI tools is the wrong move. The better choice is to let students use them, insist they understand the output, and raise the difficulty so the tools become a help rather than a shortcut to a finished grade.
The shift was visible across three years of teaching. The first group, just after COVID, had no public AI tools and progressed at search-engine speed. The next year, with ChatGPT widely available, students moved through exercises noticeably faster. Some simply copied and pasted.
Dmitrij’s response was not to fight the new reality but to adjust to it. He encourages students to use these tools, with one condition: do not copy blindly, check what the code actually does. Knowing how to use the tool is itself a skill worth learning.
When the tools made students faster, the course made the exercises harder. Increasing complexity to match what students can now produce keeps the workload meaningful. A few students still choose not to use AI on purpose, and that choice is respected too.
Generative AI blurs the line between code and codeless
The distinction between codeless tools and code-based automation is collapsing, and students see it clearly. One student observation from the course captures the point sharply.
Many codeless tools are user-friendly until a complex step appears. At that moment the tool offers a button to write custom code, sometimes JavaScript, sometimes via an AI assistant. So the codeless tool is not really codeless.
Dmitrij’s students, most of them coders, turned this into a question worth keeping:
We have a codeless tool that isn’t really codeless, because to solve complex situations, we still need to write code. Isn’t it the same thing if I’m writing the code using Selenium, Cypress, Playwright? I can use ChatGPT and it writes the code for me, so that’s also codeless. — Dmitrij Nikolajev
Generative AI turned the tables. You no longer have to be a strong coder to produce automation code, though top-level automation work still rewards real coding skill. The value shifts toward judging what the generated code does, which is why learning to code still matters: you cannot evaluate output you do not understand.
Why software failures are the best argument for testing
Stories of expensive, dangerous failures do more to convince students that testing matters than any list of principles. The course leans on this directly.
It opens by grounding the ISTQB principles of testing in real examples, drawn from nearly 20 years in IT and software testing. Abstract principles land harder when attached to something that actually went wrong.
Students extend this themselves. They can earn an exam point by researching and presenting reports in groups, with topics rated by complexity. Popular options include the biggest failures in software history, aircraft and space flight software faults, and financial-sector incidents, including cases from Lithuania.
The research goes into the technical cause, not just the headline. A floating-point error or a unit conversion between US and European systems can send a rocket sideways. Tracing a disaster back to that level of detail makes the case for testing concrete.
There is a social engine behind it too. Dmitrij tells students the presentations are for their classmates, not for him. That framing sparks a healthy competition where each team tries to outdo the last, and it produces insights the lecturer learns from as well, on topics like self-healing automation and codeless versus code-based approaches.
The tools students learn, and the freedom they keep
The course standardizes on a small set of widely used tools while leaving room for student choice. Postman handles API testing, alongside Google services for the typical environment.
For browser automation, the course recommends Selenium WebDriver, a deliberate choice of a long-established and still popular tool. The teaching team’s own background sits in that stack, which means they can help more when students hit unusual problems.
Students are not forced into it. They can work with Selenium and Java, or move to .NET, Python, or Ruby, and some do. They pick their own IDE, whether Visual Studio, IntelliJ, or the free Eclipse. The guidance points toward the team’s preferred stack for support reasons, but the flexibility stays with the student.
