Quality assurance in higher education

Quality assurance in university teaching means teaching quality thinking not as an isolated compulsory subject, but as a cross-cutting topic throughout all semesters: measuring resources, understanding test techniques, incorporating sustainability into architectural decisions. Those who learn to measure performance and scrutinize protocols at an early stage will carry these tools into companies later on.

Key Takeaways

• Quality assurance is not taught as an independent subject at Bremerhaven University of Applied Sciences, but as a cross-cutting topic throughout all semesters so that it becomes part of everyday life.
• Students usually only recognize the value of testing and quality assurance in the practical semester when they encounter concrete problems in companies and are tasked with test automation.
• Sustainability is structurally anchored: instead of buying new lab computers every five years, the university relies on refurbished servers, minimal docker resources and open source tools so that students learn to make do with limited resources.
• Basic knowledge of programming remains indispensable, because only those who have mastered the basics can meaningfully assess and process AI-generated results.
• When two teachers with different perspectives, quality assurance and programming, discuss and also argue together, students learn that technical decisions are a weighing up and not a fixed right-or-wrong.

Quality assurance belongs in the study culture, not in a single lecture

Those who teach quality assurance as an isolated subject are missing out on its real leverage. Karin Vosseberg, professor at Bremerhaven University of Applied Sciences, instead anchors quality throughout teaching, from the first semester to the final project.

The reason is simple. Quality should become an everyday tool for students, not a compulsory exercise at the end of their development. If it only appears as a downstream method, it remains what many students see it as: an annoying additional task.

In Software Engineering at Karin’s university, three lecturers work closely together to advance the topic. This bundling is the prerequisite for ensuring that quality does not depend on the daily form of a single teacher. In pure programming education, on the other hand, it is less hard-wired.

Why quality assurance is considered unsexy by students

Students want to build something new, not test it. This is precisely where the didactic difficulty lies. AI is currently very popular, while quality assurance seems old-fashioned in comparison.

Nevertheless, demand is increasing because students in companies see that this work is needed. Hardly anyone recognizes the appeal during their studies. That often only changes later.

The turning point is often the practical semester. This is where students regularly end up in a quality assurance role, because you have to analyze systems and look inside them. This experience then gives rise to specific final topics, many of which relate to test automation.

Karin reports on graduates who work in quality assurance after their studies and look back and wonder why they didn’t find the topic exciting before. Enthusiasm comes with practice, not with the lecture.

Quality assurance procedures make the software better right from the start

The decisive change of perspective: test procedures are not just there to approve finished software. Those who know them build better from the outset.

Equivalence partitions and decision trees are good examples of this. They are not only useful for test design, but also show typical sources of error that can be avoided in development right from the start.

Karin builds this bridge together with a colleague from the programming and DevOps corner. His focus is on monitoring and measuring systems, while hers is on quality assurance procedures. Together they ask: What do we learn from these processes for building software?

This also includes understanding tools instead of just using them. If you understand how a tool works and which language concepts make it possible, you can feed this knowledge back into your own development.

How two teachers show students how to weigh things up

An elective course is taught by two lecturers with different approaches, and that is intentional. The two discuss and argue on a professional level in front of the group.

The effect for the students is concrete. They see that there is rarely one right decision, but rather a weighing up: What suits the team, what suits the application, what suits the specific solution?

Many students find it difficult to talk about their own work in this way. By demonstrating the professional dispute, lecturers are indirectly practicing it. Talking about quality is itself a quality assurance competence.

Scaling is no substitute for thinking about performance

Scaling up more services is not the answer to a performance problem. Karin describes the recurring pattern: systems are launched, lots of users use them on the first day, and they immediately crash.

When asked why such load cases were not tested beforehand, the answer is often that a few services are simply ramped up and scaled horizontally. However, a high number of simultaneous accesses is nothing unusual that could not be run through in advance.

Horizontal scaling also increases complexity. Those who scale reflexively buy into this complexity and still don’t solve the actual problem.

This is why Karin practises systematic investigation with students instead of quick reflexes. An example from her own infrastructure: a small web application in an economical Docker container was regularly cleared after ten minutes because the memory was full.

The learning question is then not how to add more memory, but how to investigate such a phenomenon in the first place. Is it the memory, the Java Virtual Machine, the Tomcat? Students should build scenarios and become curious instead of resorting to the “more memory” killer argument.

Sustainability begins with the conscious use of resources

For Karin, software sustainability first means seeing resources again. That used to be a matter of course. Anyone working with 128K memory automatically paid attention to consumption in the algorithms.

Today, resources cost nothing in the first place, so hardly anyone pays attention. CPUs in the cloud, more memory, more power are just a few parameters away. That makes you careless.

Teaching brings back the focus on resources through constant measurement. Students are asked to measure the runtime of their functions, compare an implementation in a different language, observe the data throughput. Some find this annoying because nothing new is visibly created.

A concrete example is the choice of protocol for networked systems. If both sides know each other and share a simple format, a CSV is often sufficient. A chatty format has its authorization, but only where it is really needed. The question of how much data volume is actually required belongs in the toolbox.

How the university is building sustainability into its infrastructure

Sustainability is also evident in the layout of the laboratory. There used to be fifteen computers there, replaced every five years and six months later already weaker than the students’ laptops, who simply put their devices in front of them.

Today, students with a simple laptop can access a central infrastructure, the IT cloud. It runs on refurbished devices and is deliberately designed to be economical. Each student is given a Docker container with a limited amount of memory so that building takes place within real resource limits.

This design combines ecological and social sustainability. Open-source tools are used with a uniform environment for Mac, Windows and Linux so that all students can participate. Those who cannot afford their own device are given a laptop on loan.

This is supported by a cross-cohort group of lecturers, staff and students. When the older students complete their studies, the younger ones take over. This creates a core that carries on the attitude in the degree program.

Programming remains compulsory, even in the age of AI

There is no computer science without programming. Karin clearly draws this line, even against the argument that AI could take over.

The basics determine the ability to make judgments. Experienced developers can assess an AI result: Is it usable, is it an approach for further work, or is it garbage. This assessment requires basic knowledge.

This leads to a problem that Karin openly describes as unsolved. When the simple tasks are handed over to the AI, the level at which experience was previously gained is lost. How does someone become a senior consultant if the role of junior consultant no longer exists?

How can I get to grips with more complex tasks, where the AI only provides approaches, if I don’t have the experience of the simple tasks?

Karin Vosseberg

This shifts the focus in the evaluation of submissions. Instead of a polished text, teachers want an authentic text that shows what students actually know. The use of AI can rarely be proven, so it’s mainly the conversation that helps.

From the craft to the mind: why repetition counts across all semesters

Programming is learned by doing, not from books. At a university of applied sciences, this happens in labs where students carry out small exercises themselves, which gradually grow in size.

The typical kink comes reliably. In Java, the first few weeks with loops, queries and variables are easy to do. Then come classes, objects and polymorphism, and it is at this point that many people realize that programming is difficult. It takes that moment when it clicks, similar to learning a language.

The real goal is for the tools to remain available. Karin tells the story of a student in a one-year final project who was asked to download data from a website and realized that he hadn’t done that since the first semester.

That’s why the teaching uses the same techniques again and again across all courses. Measuring, automation chains in the terminal, keeping an eye on resources. Not out of repetition compulsion, but so that the knowledge is internalized and can be called up later in everyday project work.

What the students should take away with them is this enthusiasm for small, persistent steps. If you are new to a company, you can’t change everything at once. But they can start to question what is happening and thus gradually introduce sustainability and quality into the project culture.