📉 Four QA Engineers. One Framework. Zero Continuity.

Over the past few years, the project has seen four QA engineers come and go.
Only one of them built something sustainable.

The rest — for various reasons — didn’t deliver.

This isn’t just a story about team rotation.
It’s a diagnosis of a project that:

  • doesn’t support its people,
  • doesn’t evolve its processes,
  • and has no real strategy for QA.

📌 QA #1 — The TOSCA Dream, Zero Delivery

  • Mission: create automation using TOSCA.

  • Result after a full year:

    • no tests,
    • no framework,
    • nothing maintainable.
  • Conclusion:
    Started in the wrong direction + no results = nothing to show.

📌 QA #2 — From Scratch to Stable

  • Started from scratch, with zero inherited code.

  • Delivered:

    • 🔧 A framework in C# + Playwright + SpecFlow (BDD)
    • 🐍 Python scripts for managing test environments
    • ⚙️ CI pipelines
    • 📚 QA handover: documentation, wiki, OneNote
    • 📈 ~270 scenarios organized into modules
  • Used in production.
  • Stable.
  • Built and maintained solo.

📌 QA #3 — Lost in Setup

  • Came in with experience, but…

    • Spent 2 months stuck on environment setup.
    • Delivered zero tests.
    • Added no measurable value.

📌 QA #4 — Six Months In, Still No Delivery

  • Despite full documentation and a working framework:

    • ❌ No new automation
    • ❌ No refactor
    • ❌ Test execution problems dragged on for months

  • Memorable quotes:

    “I don’t know what to do. There’s no tutorial.”
    “I don’t like reading documentation.”

  • Instead of leveraging existing scenarios and steps,
    there was a constant urge to “rewrite everything from scratch”.

  • End result?
    No regression. Bugs went live. QA faded out.

🎯 Summary

  • Three QA engineers delivered nothing.
  • One QA delivered everything.

And the project?
It learned nothing:

  • No support.
  • No clear QA roadmap.
  • No decisions on automation ownership or strategy.

🧠 The real problem?

If QA is always the problem in your project,
maybe the problem isn’t QA at all —
maybe it’s the project itself and how it treats QA.