2. Principy Quality Engineeringu: Jak se kvalita skutečně buduje

Quality Engineering je především změna mindsetu

Nejde jen o to, jak testujeme, ale o to, jak o kvalitě přemýšlíme.
Kdo za ni skutečně odpovídá?
Kdy ji začínáme budovat?
Co pro nás vlastně znamená „kvalitní software“?

V praxi totiž velmi často vzniká mylné očekávání, že někde existuje správná sada kroků, která automaticky povede ke kvalitnímu softwaru. U Quality Engineeringu ale nic takového neexistuje. A je to záměr.

Quality Engineering stojí na principech, nikoli na rigidních pravidlech. Tyto principy se dají aplikovat v různých kontextech, různých organizacích i různých typech projektů. To, co funguje v malém agilním týmu, bude vypadat jinak než v rozsáhlém korporátním prostředí s historickými procesy, závislostmi a regulacemi.

Quality Engineering neposkytuje hotové odpovědi, ale pomáhá týmu klást si správné otázky: kdy se dozvídáme, že máme problém, jak rychle jsme schopni reagovat a co můžeme udělat, aby se podobná situace neopakovala.

Právě tato změna mindsetu umožňuje Quality Engineeringu dlouhodobě fungovat tam, kde mechanické zavádění procesů selhává. Nejde o to „dělat QE správně“, ale o to dělat kvalitu vědomě, systematicky a společně.

Mnoho chyb vzniká dávno před testováním

Jedna z nejčastějších iluzí v softwarovém vývoji je představa, že je možné kvalitu „dohnat“ během testování. Zkušenost z praxe ale ukazuje, že velká část problémů má své kořeny mnohem dříve, než se vůbec začne psát kód. Chyby vznikají v okamžiku, kdy tým nemá jasno v tom, co má vlastně vzniknout, proč se daná funkcionalita vytváří a jaký má mít skutečný přínos.

Nejasné zadání, chybějící kontext nebo různé interpretace požadavků vedou k rozhodnutím, která se později velmi těžko vracejí zpět a jejich změna bývá násobně nákladnější než změna provedená na začátku. Quality Engineering se snaží tento problém řešit tím, že posouvá pozornost zpět k začátku vývoje, kde je stále možné věci změnit relativně levně.

Důraz na diskusi, společné pochopení cíle a včasné odhalování rizik má často větší dopad na kvalitu než jakýkoli počet testovacích scénářů. Quality Engineering tímto přístupem nepodceňuje testování, ale dává mu silnější podporu v předchozích fázích.

Odpovědnost za kvalitu jako společný závazek

Jedním z největších posunů, které Quality Engineering přináší, je změna vnímání odpovědnosti za kvalitu. V tradičním pojetí bývá kvalita často spojována s testery a testovací fází. Jakmile se objeví problém v produkci, přirozeně se hledá odpověď na otázku, proč nebyl odhalen dříve.

Quality Engineering tento pohled mění. Kvalita přestává být úkolem jedné role a stává se společným závazkem celého týmu. Každý člen má přímý vliv na výsledek, ať už se podílí na tvorbě požadavků, návrhu řešení nebo implementaci. Tento přístup podporuje otevřenější komunikaci a snižuje tendenci hledat viníky místo řešení.

Průběžná zpětná vazba místo jednoho verdiktu na konci

Tradiční přístup ke kvalitě často spoléhá na jeden silný kontrolní moment těsně před releasem, případně dokonce až ve chvíli, kdy se problém projeví v produkci. V praxi to znamená, že se tým dlouhou dobu pohybuje bez jasné zpětné vazby o skutečném stavu produktu a skutečné kvalitě řešení. Pokud se v této fázi objeví zásadní problém, bývá už velmi složité a nákladné s ním něco udělat.

Quality Engineering se snaží tuto situaci změnit zavedením průběžné zpětné vazby. Informace o kvalitě by měly přicházet neustále (při návrhu řešení, během vývoje i po nasazení do produkce).

V praxi to například může znamenat:

• důslednou spolupráci businessu, vývoje a testování už při formulaci požadavků,
• automatizované testy běžící při každé změně kódu,
• code review jako standardní součást práce,
• průběžný monitoring aplikace v produkci a rychlou reakci na odchylky.

Nejde jen o testy jako takové, ale o celkový tok informací, který týmu umožňuje včas upravovat směr a předcházet vzniku nekvality.

Díky průběžné zpětné vazbě se malé problémy řeší dříve, než přerostou v zásadní riziko. Tým se nedostává do krizového módu a nekvalita přestává být nepříjemným překvapením na konci projektu.

Neustálé zlepšování jako přirozená součást práce

Quality Engineering se nesoustředí pouze na stav aktuálního releasu. Stejně důležitá je schopnost učit se z minulých chyb a průběžně zlepšovat způsob práce. Pokud se v projektu opakovaně objevují podobné typy problémů, je to jasný signál, že se neřeší jejich skutečná příčina.

Quality Engineering podporuje styl práce, ve kterém se chyby analyzují systémově. Namísto rychlých oprav se tým ptá, proč chyba vznikla, jaké rozhodnutí k ní vedlo a co je potřeba změnit, aby se stejná situace neopakovala.

Součástí tohoto přístupu je i kontinuální rozvoj lidí. Vzdělávání, sdílení znalostí napříč rolemi a rozšiřování kompetencí pomáhají týmu lépe porozumět širším souvislostem a předcházet opakování stejných chyb.

Tento přístup postupně zvyšuje vyspělost týmu a vede k větší stabilitě celého vývojového procesu.

Quality Engineering tedy není o tom, kolik testů máme. Je to ucelený přístup, jak brzy jsme schopni poznat, že se ubíráme špatným směrem.

Shrnutí 2. dílu

• Quality Engineering je soubor principů a přístupů, nikoli metodika
• Quality Engineering adresuje příčiny chyb vznikající v raných fázích vývoje
• Průběžná zpětná vazba umožňuje rychlou reakci a dává týmu informace o skutečné kvalitě produktu
• Kontinuální zlepšování je jedním ze základních principů Quliaty Engineeringu
• Kvalita je odpovědností celého týmu

V dalším dílu se zamyslíme nad posunem Testera ke Quality Engineerovi. Jak vypadá skutečná změna role a spolupráce v týmu?