Teaching quality assurance at university works best when quality thinking isn’t a stand-alone required course but a thread running through every semester: measuring resources, understanding test techniques, building sustainability into architecture decisions. Students who learn early to measure performance and question their choice of protocols take that toolkit with them into industry.
Key Takeaways
- At Bremerhaven University of Applied Sciences, quality assurance isn’t taught as a separate subject but runs through all semesters, so it becomes part of how students work every day.
- Most students only see the value of testing and quality assurance during their internship semester, when they hit real problems in a company and get assigned test automation work.
- Sustainability is built into the structure: instead of buying new lab computers every five years, the university runs refurbished servers, minimal Docker resources and open source tools, so students learn to work within tight limits.
- Solid programming basics remain indispensable, because only people who master the fundamentals can judge AI-generated results and build on them.
- When two lecturers with different perspectives, quality assurance and programming, discuss and even argue in front of the class, students learn that technical decisions are trade-offs, not a fixed right or wrong.
Quality Assurance Belongs in the Culture of a Degree Program, Not in One Lecture
Teach quality assurance as an isolated subject, and you give away most of its impact. Karin Vosseberg, a professor at Bremerhaven University of Applied Sciences, weaves quality into teaching from the first semester all the way to the final project.
The reasoning is simple. Quality should become an everyday tool for students, not a chore at the end of development. If it only shows up as a method you apply afterward, it stays what many students already think it is: an annoying extra task.
In the software engineering program at Karin’s university, three lecturers work closely together and push the topic as a team. That combined effort is what keeps quality from depending on how one individual lecturer happens to feel on a given day. In the pure programming courses, it is less firmly wired in.
Why Students Find Quality Assurance Unexciting
Students want to build new things, not check them. That is exactly the teaching challenge. AI is the hot topic right now, and quality assurance looks dated next to it.
Demand is growing anyway, because students see in companies that this work is needed. While they are still studying, though, hardly anyone sees the appeal. That usually changes later.
The turning point is often the internship semester. Students regularly end up in a quality assurance role there, because the job requires analyzing systems and looking inside them. That experience then turns into concrete thesis topics, many of them on test automation.
Karin tells of graduates who now work in quality assurance and wonder in hindsight why the topic didn’t interest them back then. The enthusiasm comes with practice, not with the lecture.
How Test Techniques Make Software Better From the Start
The key shift in perspective: test techniques aren’t only there to sign off finished software. If you know them, you build better software in the first place.
Equivalence partitioning and decision trees are good examples. They are useful for test design, but they also expose typical sources of errors that developers can avoid right from the start.
Karin builds this bridge together with a colleague from the programming and DevOps side. He focuses on monitoring and measuring systems, she focuses on quality assurance techniques. Together they ask: what do these techniques teach us about building software?
That includes understanding tools instead of just using them. If you know how a tool works and which language concepts make it possible, you can feed that knowledge back into your own development.
Two Lecturers Who Model the Trade-Offs
One elective course is taught by two lecturers with different approaches, and that is deliberate. They discuss and argue technical points in front of the group.
For students, the effect is concrete. They see that there is rarely one right decision, only trade-offs: what fits the team, what fits the application, what fits this particular solution?
Talking about their own work in this way is hard for many students. When the lecturers act out a technical disagreement, the students practice it along with them. Being able to talk about quality is itself a quality assurance skill.
Why Horizontal Scaling Doesn’t Replace Thinking About Performance
Spinning up more services is not an answer to a performance problem. Karin describes a recurring pattern: a system launches, lots of users pile on the first day, and it crashes immediately.
Ask why nobody tested that load scenario beforehand, and the answer is often that you just spin up a few more services and scale horizontally. Yet a high number of concurrent users is nothing unusual. It is exactly the kind of case you can play through in advance.
Horizontal scaling also adds complexity. Scale by reflex, and you buy that complexity without solving the actual problem.
That is why Karin trains students to investigate systematically instead of reaching for the quick fix. One example comes from the university’s own infrastructure: a small web application in a lean Docker container kept getting killed after ten minutes because it ran out of memory.
The learning question then isn’t how to add more memory, but how to investigate a problem like that in the first place. Is it the memory, the Java Virtual Machine, Tomcat? Students should build scenarios and get curious, rather than falling back on the knee-jerk “just add more memory” fix.
Software Sustainability Starts With Paying Attention to Resources
For Karin, software sustainability starts with seeing resources again. That used to be a given. Anyone working with 128K of memory watched consumption in their algorithms without thinking about it.
Today, resources seem free at first, so hardly anyone looks. Cloud CPUs, more memory, more power are only a few parameters away. That breeds carelessness.
Teaching brings resources back into view through constant measurement. Students measure the runtime of their functions, compare an implementation in another language and watch data throughput. Some find that tedious, because nothing visibly new comes out of it.
The choice of protocol in networked systems is a concrete example. If both sides know each other and share a simple format, a CSV file is often enough. A verbose format has its place, but only where it is really needed. Asking how much data volume is actually required belongs in every developer’s toolbox.
Building Sustainability Into the University’s Infrastructure
Sustainability also shows in how the lab is set up. It used to hold fifteen computers, replaced every five years and outpaced by the students’ laptops six months later, so students simply put their own machines in front of them.
Today, students bring a basic laptop and connect to a central infrastructure, the computer science cloud. It runs on refurbished hardware and is deliberately lean. Every student gets a Docker container with tightly limited memory, so building happens within real resource limits.
This setup links environmental and social sustainability. The program uses open source tools with a uniform environment for Mac, Windows and Linux, so every student can take part. Anyone who can’t afford a device of their own gets a loaner laptop.
A cross-cohort group of lecturers, staff and students keeps all this running. When older students graduate, younger ones step in. That creates a core group that carries the attitude forward in the program.
Programming Stays Mandatory in the Age of AI
Without programming, it isn’t computer science. Karin holds that line firmly, including against the argument that AI can take care of it.
The basics decide whether you can judge results. Experienced developers can assess what an AI produces: is it usable, is it a starting point for further work, or is it junk? That judgment requires basic knowledge of your own.
This leads to a problem that Karin openly calls unsolved. When the simple tasks go to AI, the rung where people used to gain experience disappears. How does anyone become a senior consultant if the junior consultant role no longer exists?
“How am I supposed to get a grip on more complex tasks, where AI only gives me starting points, if I don’t have the experience from the simple tasks?”
(Karin Vosseberg)
That shifts the focus when grading assignments. Instead of a polished text, the lecturers want an authentic one that shows what students actually know. AI use can rarely be proven, so the most useful tool is the conversation.
From Hands to Head: Why Repetition Across All Semesters Matters
You learn programming by doing it, not from books. At a university of applied sciences, that happens in labs where students work through small exercises that gradually grow larger.
The typical dip arrives like clockwork. In Java, the first weeks with loops, conditionals and variables are quite manageable. Then come classes, objects and polymorphism, and that is when many realize programming is hard. It takes that moment when it clicks, much like learning a foreign language.
The real goal is to keep the toolkit within reach. Karin tells of a student in the year-long final project who was asked to download data from a website and realized he hadn’t done that since his first semester.
That is why the program returns to the same techniques again and again, across all courses: measuring, automation chains in the terminal, keeping an eye on resources. Not for the sake of repetition, but so the knowledge sticks and is there when it’s needed in later project work.
What students should take with them is a taste for small, persistent steps. Someone new at a company can’t change everything at once. But they can start asking what is actually going on, and bring sustainability and quality into the project culture one piece at a time.
Frequently Asked Questions
When do computer science students typically recognize the value of testing?
Usually not until their internship semester. There, students often find themselves in a quality assurance role because they have to analyze systems and look inside them. This experience frequently leads to thesis topics, many of which focus on test automation. Karin Vosseberg shares stories of graduates who later work in quality assurance and, looking back, wonder why they found the subject boring during their studies.
How do test design techniques benefit the development process itself?
They prevent errors rather than just finding them after the fact. Equivalence partitions and decision trees aren’t just for test design; they also highlight typical sources of error that can be avoided from the very beginning of the development process. This includes understanding tools rather than just using them: Those who grasp the programming concepts a tool enables can apply that knowledge to their own development work.
Does horizontal scaling solve a performance problem?
No. Anyone who reflexively spins up services is inviting additional complexity and still hasn’t solved the actual problem. The pattern repeats itself: A system goes live, many users arrive on the first day, and it crashes immediately. A high number of concurrent accesses is nothing unusual; it’s something that could be simulated in advance as a load case.
How can we bring software resource consumption back into focus?
Through continuous measurement. Students should measure the runtime of their functions, compare an implementation in another language, and observe the data throughput. Then there’s the question of data volume: If both sides are familiar with each other and share a simple format, a CSV file is often sufficient. A verbose format has its place, but only where it’s needed.
What are the benefits of two instructors with different perspectives co-teaching a course?
Students witness the balancing act firsthand. In an elective course, two instructors deliberately discuss and debate technical issues in front of the group: one focusing on monitoring and measurement, the other on quality assurance procedures. This makes it clear that there is rarely a single “right” decision, but rather questions regarding the team, the application, and the specific solution.
Is learning to code still necessary if AI can generate code?
Yes. Without coding, it’s not computer science, and the basics determine one’s ability to make sound judgments. Only those who have mastered the fundamentals can evaluate an AI output: whether it’s usable, a starting point for further work, or unusable. Without this foundational knowledge of one’s own, there is no yardstick for meaningfully processing the generated results.
What problem arises when AI takes over simple programming tasks?
The stage where experience was gained is eliminated. Karin Vosseberg openly describes this as an unresolved issue: How does someone become a senior consultant if the role of junior consultant no longer exists? For more complex tasks, AI provides only starting points, and then the routine gained from simple cases is missing. In evaluating assignments, therefore, what counts is the authentic text and, above all, the conversation.
How can a computer science lab be set up in a resource-efficient manner?
Through centralized, intentionally limited infrastructure rather than regular hardware purchases. In the past, there were fifteen computers in the lab, replaced every five years and soon outperformed by the students’ laptops. These were replaced by a computer science cloud running on refurbished devices, with one Docker container per student and limited memory. Open-source tools run uniformly on Mac, Windows, and Linux, and loaner laptops make up for the lack of personal devices.
