Quality Assurance in IT – More Than Just Testing

Testing in IT has many meanings and approaches. Depending on the business case, system landscape, and requirements, different methods are employed. However, the actual goal always remains the same: ensuring the quality of a product for the end user.

In complex projects, this goal can sometimes slip out of focus. There are many reasons for this:

• Teams only validate their own systems and not the entire business flow
• Missing or weak QA processes
• Too little or no test automation
• Lack of communication between stakeholders
• Unclear requirements or missing hypercare phases after major releases
• Overly rigid or poorly adapted processes
• Missing monitoring and alerting
• Insufficient unit and integration tests
• High system complexity
• Loss of know-how due to personnel changes
• Missing planning for refactorings
• Outdated processes or assumptions that are no longer questioned
• Too much distance between technical teams and the actual end product

Throughout my career, I've experienced different roles and thereby learned different perspectives on quality and software development. In doing so, it became increasingly clear to me: Quality doesn't just emerge at the end of a project through testing. It emerges through good communication, clear requirements, clean processes, technical stability, and a shared understanding of the overall product.

The Tester's Perspective

I've worked in several areas:

1. Technical SEO consulting
2. Software development with JavaScript and TypeScript
3. Test and validation management in the automotive environment
4. Backend development with Java and Spring Boot

All of these positions had something in common: high quality requirements.

Particularly exciting for me was the transition from developer to the test and validation area in an automotive project in the context of the BMW Crowd Data Collector. There I was able to connect both worlds: development and quality assurance.

While a colleague performed tests directly on the vehicle or on the test rack, my focus was on:

• Analysis of DLT logs and system data
• Creation and preliminary analysis of bug tickets
• Requirements analysis and validation
• Data consistency and error analysis
• Solution proposals for development teams
• Coordination between different stakeholders

Among the tools used were:

• DLT Viewer
• Kibana
• Jira
• Confluence
• Log and data analyses
• Documentation and ticket processes

Especially in such projects, it becomes clear that testing means far more than just executing test cases. A good tester not only tries to find errors, but also to understand:

• Why does a problem occur?
• What impact does it have on other systems?
• Is a requirement perhaps missing?
• Is the architecture comprehensible?
• Are there risks to performance or stability?

Planning Test Scenarios

An important part of quality assurance is the structured consideration of different scenarios:

• What are the expected standard cases?
• Which edge cases could occur?
• How does error handling behave?
• How efficiently does the system work?
• Which regulatory requirements such as DSGVO/GDPR must be considered?
• How does the system react under load or with unstable dependencies?

The more complex systems become, the more important it becomes to understand not just individual functions, but the interplay of all components.

Quality as a Shared Goal

For me, quality is not an isolated task of a single team. It emerges through collaboration between development, testing, architecture, product ownership, and stakeholders.

Good software rarely emerges by chance. It requires:

• open communication,
• clear responsibilities,
• technical curiosity,
• pragmatic solutions,
• and the will to continuously improve systems.

In modern IT projects, it's often not enough to just deliver "working code." Systems must remain maintainable, comprehensible, and stable in the long term — especially when many teams, services, and external dependencies work together.

That's why I see quality assurance not as a brake on development, but as an important component of sustainable software development.