Quality Assurance

Quality comes from testing early, not from inspection at the end

In modern software organisations, quality assurance (QA) is not a separate step at the end of the project; it is an integral part of every development step. We follow the Shift-Left strategy: tests are carried out as early as possible in the development process.

The goal is a high level of confidence in the system, making it possible to deploy code changes to production multiple times a day without fear of outages.

Anti-Patterns: The Quality Illusion

• Manual test weeks: Before every release, manual checklists are worked through for days. This is slow, expensive, and systematically overlooks edge cases.
• Testing in Production: Bugs are only discovered through customer reports because there is no sufficient test automation in place.
• Silo QA: A separate QA team finds bugs weeks after development, making fixes extremely expensive (context switching for developers).

The Test Pyramid

1. Unit Tests (base): Thousands of small, extremely fast tests for individual logic components. They give developers immediate feedback.
2. Integration Tests: Verification of how modules, databases, and APIs interact.
3. End-to-End (E2E) Tests: Simulation of real user scenarios in the browser or app for the most important business processes.
4. Static Analysis and Linting: Automatic code review for security vulnerabilities and style issues, already at the time of typing or committing.
5. Shift-Left Testing: Integration of security and performance tests directly into the CI/CD pipeline (see CI/CD).

The Focus: Automation Instead of Hope

Quality is not a coincidence; it is built through a disciplined, repeatable process that reduces risk and raises confidence, rather than a deterministic guarantee of correctness. Every security vulnerability or bug that is found ideally leads to a new automated test that reduces the risk of that failure recurring. Tests can be incomplete, faulty, or bypassed, and security fixes often require design or control changes beyond a single test.

FAQ

Don't all these tests slow down the delivery of new features?

In the short term, yes, the first time. But they prevent the bug-fix hell after go-live. Without tests, velocity drops sharply as the project grows. Tests are an essential prerequisite for sustained speed.

Is 100% test coverage enough?

No. The number (Coverage) says nothing about the quality of the tests. What matters more is that the critical business processes (Happy Paths) and the most dangerous failure scenarios are reliably covered.

References

• Vocke, Ham The Practical Test Pyramid. Practical guide to test automation and the test pyramid. martinfowler.com/articles/practical-test-pyramid.html
• Whittaker, James A. et al. How Google Tests Software. Insights into Google's testing culture. (2012). books.google.com/books?id=v6ZpAgAAQBAJ
• OWASP Web Security Testing Guide (WSTG). Standard for security testing. owasp.org/www-project-web-security-testing-guide/