Skip to content

Quality engineering: a pragmatic approach

The field of quality assurance is evolving. We have long reduced this role to validation at the end of the chain or to writing scripts, but that era is over.

I am a quality engineer, and the reason I am starting this blog today is to move away from the beaten path of traditional QA and document a different approach.

My vision: quality serving delivery

We often read that quality is “everyone’s business,” or that one must “aim for zero defects.” This looks nice on a slide, but the operational reality is different.

Over the years and projects, I have forged a simple conviction: quality should not be a hindrance, but an accelerator for development.

If your test suite takes 2 hours to run, its operational utility is drastically reduced. It no longer adapts to a rapid agile development cycle, but instead constrains the team to monolithic deployments. The result: feedback arrives too late, context is lost, and delivery is slowed down.

Here, I want to champion a “lean” approach to engineering:

  1. Protecting trust: A test that fails randomly (flaky) is worse than no test at all, as it erodes the team’s confidence in the CI. There are only three viable options: fix it, delete it, or isolate it (quarantine) immediately to avoid blocking the flow.
  2. Automating strategically: The goal is not to automate 100% of manual tests, but to build robust safety nets that allow for refactoring and evolving the software serenely.
  3. Technology as a lever: Using modern tools to reduce the friction between development and production deployment.

What we will discuss

This blog will serve as public documentation for topics I deal with daily:

You will not find grand academic theories here, but concrete experience feedback, working code, and a vision oriented towards efficiency.

I look forward to exchanging with you.

Jean-Michel


Share this post on:

Next Post
Verification & Validation: two Compasses