[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fL4xHDORq5ikxE2vQmTMz41yTxAs33BGqxihEDb8MBIQ":3,"$fTc7BYY0Q4q1VbL6z6wkpQYd74g_SISBWNa0vVUHCPhM":20},{"id":4,"slug":5,"titleFr":6,"titleEn":7,"titleKm":8,"contentFr":9,"contentEn":10,"contentKm":8,"excerptFr":11,"excerptEn":12,"excerptKm":8,"tags":13,"createdAt":19,"updatedAt":19},111,"qa-en-2026","QA en 2026 : dernier rempart ou poste en sursis ?","QA in 2026: Last Line of Defense or a Role on Borrowed Time?",null,"## QA en 2026 : un poste en sursis ou plus indispensable que jamais ?\n\nEn 2026, dans l'écosystème startup, le QA est souvent le premier poste qu'on supprime quand les temps sont durs. \"Les devs peuvent tester eux-mêmes.\" \"L'IA va automatiser tout ça.\" \"On n'a pas le budget.\"\n\nJ'entends ces phrases régulièrement. Et pourtant, dans mon équipe chez DJUST, la QA est devenue le pilier silencieux sans lequel plus personne ne veut travailler. Voici l'histoire.\n\n---\n\n## Le contexte : une startup B2B sous pression\n\nDJUST est une plateforme e-commerce B2B SaaS. En tant qu'Engineering Manager, je gère l'équipe OMS (Order Management System) — commandes, paiements, panier, intégrations fournisseurs. C'est le cœur transactionnel, là où chaque bug a un impact business direct.\n\nComme beaucoup de startups, DJUST a connu des phases de croissance et de contraction. Les signatures clients sont complexes, le marché B2B est exigeant, et chaque décision de recrutement ou de réduction d'effectif se ressent immédiatement.\n\n---\n\n## Acte 1 : De 0 à 3 QA — la montée en puissance\n\nAu début, il n'y avait qu'**une seule QA manuelle**. Les tests étaient artisanaux, les régressions fréquentes, et chaque release était un moment de stress. On testait \"à la main\", on croisait les doigts, on déployait le jeudi en espérant que le vendredi se passe bien.\n\nPuis l'équipe QA a grandi à **3 personnes**. C'est à ce moment qu'elle est arrivée — une développeuse C# avec **10 ans d'expérience** qui avait décidé de changer de voie pour devenir QA. Un profil atypique qui allait tout changer.\n\n---\n\n## Acte 2 : Le profil atypique qui change la donne\n\nQuand une développeuse senior avec une décennie de code derrière elle arrive en QA, ça se voit immédiatement. Elle ne se contente pas de cliquer sur des boutons et de remplir des fiches de bug. Elle comprend le code, elle anticipe les cas limites, elle pense en systèmes.\n\nDès son arrivée, elle a poussé pour **structurer la QA** :\n\n- **Tests E2E automatisés** adaptés à nos développeurs — pas des tests Selenium fragiles écrits dans un coin, mais des tests pensés avec et pour l'équipe dev\n- **Spécifications en amont** — elle s'est naturellement rapprochée de notre Product Manager pour valider les specs *avant* le lancement des développements\n- **Critères d'acceptance rigoureux** — chaque ticket est passé au crible avant même qu'un dev n'ouvre son IDE\n- **Processus de validation structuré** — fini le \"ça a l'air de marcher\", place à des scénarios de test reproductibles\n\nSon background de développeuse C# lui donnait un avantage énorme : elle parlait le même langage que les devs, comprenait les contraintes techniques, et savait exactement où les bugs allaient se cacher.\n\n---\n\n## Acte 3 : La réduction — et le choix que j'ai dû faire\n\nLe contexte startup a rattrappé l'équipe. Signatures difficiles, complexité du marché B2B, nécessité de réduire les coûts.\n\nLa première QA est partie d'elle-même — elle avait envie de changer de voie et est devenue **Product Manager**. Une belle évolution.\n\nLe deuxième QA a été **licencié** dans le cadre d'une réduction d'effectif. Les temps étaient durs, il fallait faire des choix.\n\nEt puis il y a eu la question : est-ce qu'on garde la troisième ?\n\n**Je l'ai défendue.** Pas par sentimentalisme — par conviction. J'ai expliqué à la direction son apport global à la boîte : la stabilité de nos releases, la réduction des bugs en production, le temps gagné par les développeurs qui ne passaient plus leurs journées à debugger des régressions, et surtout son rôle critique auprès du Product Manager.\n\nElle est restée. La dernière QA de la boîte.\n\n---\n\n## Acte 4 : Le pilier silencieux\n\nAujourd'hui, son rôle est **angulaire**. C'est le mot exact.\n\nNotre **Product Manager** ne peut plus travailler sans elle. Avant chaque sprint, elle est là en amont : elle challenge les specs, identifie les incohérences, pose les questions que personne n'a pensé à poser. Quand le PM présente une feature aux devs, les specifications ont déjà été passées au crible. Résultat : moins d'allers-retours, moins d'ambiguïté, des développements plus fluides.\n\nNos **Project Managers**, ceux qui sont face aux clients — Franprix, Eiffage, VEJA — ont vu l'evolution. Ils ont vécu l'avant et l'apres. La stabilité de la plateforme s'est améliorée de manière visible. Ils ne veulent pas perdre ça. Quand on parle de QA, leur réponse est unanime : \"On ne peut pas revenir en arrière.\"\n\nLes **développeurs** eux-mêmes, qui au début voyaient la QA comme un frein (\"encore un bug a corriger avant la release...\"), ont compris que c'était un filet de sécurité qui les rendait plus rapides, pas plus lents.\n\n---\n\n## Acte 5 : L'inquiétude face a 2026\n\nMais elle s'inquiète. Et je la comprends.\n\n**Première inquiétude : l'IA.** Quand on voit Claude Code écrire des tests unitaires en quelques secondes, quand les outils d'IA génèrent des scénarios de test automatiquement, la question se pose naturellement : \"Est-ce que l'IA va me remplacer ?\"\n\n**Deuxième inquiétude : la solitude.** Elle est la dernière QA de la boîte. Pas de pair avec qui échanger, pas de communauté QA interne, pas de mentor. C'est un poste isolé dans une entreprise qui a tendance à voir la QA comme un coût plutôt qu'un investissement.\n\n**Troisième inquiétude : l'incompréhension.** Dans une startup tech, le prestige va aux développeurs, aux architectes, aux devops. Le QA est souvent le \"mal nécessaire\" qu'on tolère. Certains collègues ne comprennent pas pourquoi ce poste existe encore en 2026.\n\n---\n\n## Ma réponse : l'IA ne remplace pas la rigueur humaine\n\nVoici ce que je lui ai dit, et ce que je crois profondément :\n\n**L'IA est un multiplicateur, pas un remplaçant.** Claude Code peut générer des tests, oui. Mais il ne peut pas :\n- Comprendre le contexte métier d'un client qui commande 10 000 palettes de café via une API B2B\n- Anticiper qu'un flux de paiement Adyen va se comporter différemment en production qu'en sandbox\n- Sentir qu'une spec est incomplète parce qu'elle connaît l'historique des 50 dernières features\n- Challenger un Product Manager sur la cohérence d'un parcours utilisateur\n\n**Avec l'IA et elle, on peut aller plus loin.** Maintenant qu'elle vient de passer **senior**, c'est le moment d'élever les exigences. L'IA automatise les tâches répétitives — les tests de régression, la génération de cas de test, la détection de patterns. Ça la libère pour ce que seule elle sait faire : la réflexion stratégique sur la qualité.\n\nNotre vision pour 2026 :\n- **L'IA génère les tests**, elle les revoit et les enrichit\n- **L'IA détecte les régressions**, elle analyse les causes profondes\n- **L'IA couvre la quantité**, elle assure la pertinence\n- **Les exigences qualité montent**, parce qu'on a les moyens de les imposer\n\n---\n\n## Ce que j'ai appris en tant qu'Engineering Manager\n\nDéfendre un poste QA dans une startup qui réduit ses effectifs, c'est un acte de management. Pas un acte technique.\n\nÇa demande de :\n1. **Quantifier l'apport** — pas en \"nombre de bugs trouvés\" (métrique absurde), mais en stabilité des releases, temps gagné par les devs, confiance des project managers face aux clients\n2. **Expliquer le coût de l'absence** — combien coûte un bug en production chez un client B2B qui passe 2M de commandes par an ?\n3. **Projeter l'avenir** — montrer que le QA + IA est plus puissant que le QA seul ou l'IA seule\n4. **Encourager malgré l'adversité** — parce qu'être le dernier à un poste dans une boîte, c'est dur. C'est solitaire. Et ça demande une vraie force de caractère.\n\nElle a cette force. Et elle le prouve chaque jour.\n\n---\n\n## Conclusion : QA en 2026, plus que jamais\n\nNon, le QA ne disparaît pas en 2026. Il se **transforme**.\n\nLe QA manuel pur, celui qui clique et remplit des fiches — oui, celui-là est en danger. Mais le QA qui comprend le code, qui structure les processus, qui travaille en amont avec le product, qui impose une rigueur que les développeurs seuls ne peuvent pas maintenir — celui-là est **irremplaçable**.\n\nEt quand en plus ce QA a 10 ans de développement C# derrière lui, qu'il parle le langage des devs, qu'il sait écrire des tests E2E qui tiennent la route, et qu'il a la résilience de tenir bon quand tout le monde autour dit que son métier va disparaître...\n\nCe n'est pas un poste à supprimer. C'est un poste à protéger.\n\n*Chetana YIN — Février 2026*","## QA in 2026: A Dying Role or More Essential Than Ever?\n\nIn 2026, within the startup ecosystem, QA is often the first position cut when times get tough. \"Devs can test themselves.\" \"AI will automate all of that.\" \"We don't have the budget.\"\n\nI hear these sentences regularly. And yet, in my team at DJUST, QA has become the silent pillar without which no one wants to work anymore. Here's the story.\n\n---\n\n## The Context: A B2B Startup Under Pressure\n\nDJUST is a B2B SaaS e-commerce platform. As Engineering Manager, I lead the OMS (Order Management System) team — orders, payments, cart, supplier integrations. It's the transactional core, where every bug has a direct business impact.\n\nLike many startups, DJUST has gone through phases of growth and contraction. Client signings are complex, the B2B market is demanding, and every hiring or reduction decision is felt immediately.\n\n---\n\n## Act 1: From 0 to 3 QAs — The Rise\n\nIn the beginning, there was only **one manual QA**. Testing was artisanal, regressions were frequent, and every release was a stressful moment. We tested by hand, crossed our fingers, deployed on Thursday hoping Friday would go smoothly.\n\nThen the QA team grew to **3 people**. That's when she arrived — a C# developer with **10 years of experience** who had decided to change paths and become a QA. An atypical profile that would change everything.\n\n---\n\n## Act 2: The Atypical Profile That Changed Everything\n\nWhen a senior developer with a decade of coding behind her joins QA, it shows immediately. She doesn't just click buttons and fill bug reports. She understands code, anticipates edge cases, thinks in systems.\n\nFrom the start, she pushed to **structure QA**:\n\n- **Automated E2E tests** adapted to our developers — not fragile Selenium tests written in a corner, but tests designed with and for the dev team\n- **Upstream specifications** — she naturally gravitated toward our Product Manager to validate specs *before* development began\n- **Rigorous acceptance criteria** — every ticket gets scrutinized before a dev even opens their IDE\n- **Structured validation process** — no more \"looks like it works,\" replaced by reproducible test scenarios\n\nHer C# developer background gave her a huge advantage: she spoke the same language as the devs, understood technical constraints, and knew exactly where bugs would hide.\n\n---\n\n## Act 3: The Reduction — And the Choice I Had to Make\n\nThe startup reality caught up with the team. Difficult signings, B2B market complexity, need to cut costs.\n\nThe first QA left on her own — she wanted a change and became a **Product Manager**. A great evolution.\n\nThe second QA was **laid off** as part of a workforce reduction. Times were tough, choices had to be made.\n\nAnd then came the question: do we keep the third?\n\n**I defended her.** Not out of sentimentality — out of conviction. I explained to leadership her global contribution to the company: the stability of our releases, the reduction of production bugs, the time saved by developers who no longer spent their days debugging regressions, and especially her critical role alongside the Product Manager.\n\nShe stayed. The last QA in the company.\n\n---\n\n## Act 4: The Silent Pillar\n\nToday, her role is **pivotal**. That's the exact word.\n\nOur **Product Manager** can't work without her anymore. Before every sprint, she's there upstream: challenging specs, identifying inconsistencies, asking questions nobody thought to ask. When the PM presents a feature to devs, the specifications have already been scrutinized. Result: fewer back-and-forths, less ambiguity, smoother development.\n\nOur **Project Managers**, the ones facing clients — Franprix, Eiffage, VEJA — have seen the evolution. They lived through the before and after. Platform stability improved visibly. They don't want to lose that. When QA comes up, their answer is unanimous: \"We can't go back.\"\n\nThe **developers** themselves, who initially saw QA as a brake (\"another bug to fix before release...\"), understood it was a safety net that made them faster, not slower.\n\n---\n\n## Act 5: The 2026 Anxiety\n\nBut she's worried. And I understand.\n\n**First worry: AI.** When you see Claude Code writing unit tests in seconds, when AI tools generate test scenarios automatically, the question naturally arises: \"Will AI replace me?\"\n\n**Second worry: solitude.** She's the last QA in the company. No peer to exchange with, no internal QA community, no mentor. It's an isolated position in a company that tends to see QA as a cost rather than an investment.\n\n**Third worry: misunderstanding.** In a tech startup, prestige goes to developers, architects, devops. QA is often the \"necessary evil\" that's tolerated. Some colleagues don't understand why this position still exists in 2026.\n\n---\n\n## My Answer: AI Doesn't Replace Human Rigor\n\nHere's what I told her, and what I deeply believe:\n\n**AI is a multiplier, not a replacement.** Claude Code can generate tests, yes. But it can't:\n- Understand the business context of a client ordering 10,000 pallets of coffee through a B2B API\n- Anticipate that an Adyen payment flow will behave differently in production than in sandbox\n- Sense that a spec is incomplete because she knows the history of the last 50 features\n- Challenge a Product Manager on the consistency of a user journey\n\n**With AI and her, we can go further.** Now that she's just been promoted to **senior**, it's time to raise the bar. AI automates repetitive tasks — regression tests, test case generation, pattern detection. It frees her for what only she can do: strategic thinking about quality.\n\nOur vision for 2026:\n- **AI generates tests**, she reviews and enriches them\n- **AI detects regressions**, she analyzes root causes\n- **AI covers quantity**, she ensures relevance\n- **Quality standards rise**, because we now have the means to enforce them\n\n---\n\n## What I Learned as an Engineering Manager\n\nDefending a QA position in a startup that's reducing headcount is an act of management. Not a technical act.\n\nIt requires:\n1. **Quantifying the contribution** — not in \"number of bugs found\" (an absurd metric), but in release stability, time saved by devs, project manager confidence when facing clients\n2. **Explaining the cost of absence** — how much does a production bug cost for a B2B client placing 2M in orders per year?\n3. **Projecting the future** — showing that QA + AI is more powerful than QA alone or AI alone\n4. **Encouraging despite adversity** — because being the last person in a role at a company is hard. It's lonely. And it takes real strength of character.\n\nShe has that strength. And she proves it every day.\n\n---\n\n## Conclusion: QA in 2026, More Than Ever\n\nNo, QA isn't disappearing in 2026. It's **transforming**.\n\nPure manual QA, the one that clicks and fills reports — yes, that one is in danger. But the QA who understands code, structures processes, works upstream with product, and enforces a rigor that developers alone can't maintain — that one is **irreplaceable**.\n\nAnd when that QA also has 10 years of C# development behind her, speaks the developers' language, can write E2E tests that hold up, and has the resilience to stand firm when everyone around says her job is about to disappear...\n\nThat's not a position to cut. That's a position to protect.\n\n*Chetana YIN — February 2026*","Dans une startup qui réduit ses effectifs, j'ai défendu le poste QA. Retour sur le parcours d'une ex-dev C# devenue la dernière QA de la boîte — et pourquoi avec l'IA, son rôle n'a jamais été aussi crucial.","In a startup cutting headcount, I defended the QA role. The story of a former C# developer who became the last QA standing — and why with AI, her rôle has never been more crucial.",[14,15,16,17,18],"QA","Management","AI","Startup","Engineering","2026-01-30T19:00:00",[]]