Nenechejte si ujít nejnovější informace.
Vyplňte nám vaši e-mailovou adresu a dostávejte pravidelnou nálož informací ohledně nadcházejících školení, akcí a testingového know-how.
Blog
3. díl ze série čtyř článků na téma 'O Quality Engineeringu', které přibližují tento celkový přístup v zajištění kvality softwaru.
Když se v týmu začne mluvit o Quality Engineeringu, velmi často se pohledy stočí právě k testerům. Ne nutně proto, že by někdo chtěl jejich roli zpochybňovat, ale proto, že testování bylo dlouhou dobu hlavním symbolem kvality. Je proto přirozené, že v hlavě testerů naskočí otázky typu: Bude moje role ještě potřeba? Neznamená to, že se testování rozpustí mezi ostatní aktivity?
Tyto obavy nejsou iracionální. V minulosti už testování několikrát prošlo změnami, které vedly spíš k posunu role směrem k technickým aktivitám než k jejímu skutečnému posílení. Automatizace, tlak na rychlost a zkracování testovacích fází často vedly k tomu, že se tester ocitl v pozici někoho, kdo „jen spouští testy“. Quality Engineering ale vznikl jako reakce na právě tuto situaci. Nejde přitom o novou samostatnou roli, ale spíše o změnu přístupu ke kvalitě, která se týká celého týmu.
Abychom pochopili změnu role testera v QE, je potřeba si otevřeně přiznat jednu věc: testování jako poslední fáze vývoje dnes jednoduše nestačí. Ne proto, že by bylo méně kvalitní, ale proto, že přichází příliš pozdě. Tester dostává produkt, který už je z velké části navržený a implementovaný, a očekává se od něj, že odhalí všechny problémy dřív, než se dostanou k uživatelům.
V praxi se tak tester dostává do extrémně nevděčné pozice. Nachází chyby, jejichž oprava je často nákladná nebo technicky složitá a tým je pak nucen rozhodovat mezi kvalitou a termínem. Quality Engineering tuto situaci neřeší tím, že by testování omezil, ale tím, že ho posouvá blíž ke vzniku problému, ne až k jeho důsledku.
V prostředí Quality Engineeringu se testovací myšlení začíná uplatňovat mnohem dříve. Tester se zapojuje do diskusí o požadavcích, účastní se návrhu řešení a pomáhá týmu klást otázky, které by jinak nemusely zaznít. Nejde o to, že by tester suploval analytika nebo architekta, ale o to, že do rozhodování přináší pohled na rizika, chování systému a možné scénáře použití.
Tento posun má zásadní dopad. Problémy, které by se dříve objevily až při testování hotového produktu, se často vyřeší ještě předtím, než vznikne první řádek kódu. Testování tak přestává být strážcem na konci procesu a stává se nástrojem prevence.
Jinými slovy:
Quality Engineering není o tom, že tester dělá víc věcí než dříve.
Je o tom, že kvalitu začnou řešit všichni, a to od samého začátku vývoje.
Označení Quality Engineering může někdy svádět k představě nové role nebo titulu. Ve skutečnosti jde především o změnu přístupu ke kvalitě, která se týká celého týmu.
Kvalita přestává být doménou jedné role. Vývojáři, analytici, product owneři i testeři se podílejí na rozhodnutích, která ovlivňují stabilitu systému, jeho udržovatelnost i schopnost reagovat na změny.
Tento posun často znamená větší zapojení do rozhodovacích procesů a také větší zodpovědnost za výsledek. Zároveň ale přináší i větší smysluplnost práce. Tester se nepohybuje jen v roli toho, kdo „nachází problémy“, ale stává se někým, kdo pomáhá vytvářet řešení, na které se dá spolehnout.
Zároveň často působí jako někdo, kdo tyto principy aktivně šíří v týmu – upozorňuje na rizika, podporuje diskusi o kvalitě napříč jednotlivými fázemi vývoje a pomáhá ostatním rolím přemýšlet o kvalitě už během návrhu a implementace řešení.
Quality Engineering zároveň mění způsob, jakým spolu lidé v týmu spolupracují. Tradiční model, kde se práce předává z role na roli, vytváří přirozené bariéry. Každý řeší „svoji část“ a odpovědnost za celek se rozplývá. V takovém prostředí se problémy často objeví až ve chvíli, kdy už je pozdě na jejich řešení.
Quality Engineering podporuje model, kde se role více prolínají a lidé spolupracují napříč specializacemi. Společné diskuse, párová práce nebo sdílené rozhodování o rizicích vedou k hlubšímu pochopení problémů a kvalitnějším řešením.
V praxi to může znamenat například zapojení pohledu na kvalitu už při definici požadavků, společné hodnocení rizik během návrhu řešení nebo sdílenou odpovědnost týmu za kvalitu během celého vývoje. Tým přestává fungovat jako výrobní linka, kde jednotlivé role pracují izolovaně, a začíná fungovat jako celek.
Techniky, nástroje a procesy se dají relativně rychle naučit. Změna myšlení už tak jednoduchá není. Quality Engineering vyžaduje ochotu opustit představu, že kvalita je zodpovědnost někoho jiného. Vyžaduje otevřenou komunikaci, důvěru a schopnost reflektovat vlastní chyby.
Bez tohoto posunu zůstane Quality Engineering jen pojmem v prezentacích a metodikách. Díky němu se ale může stát základem pro zdravější týmy, klidnější releasy a kvalitnější produkty.
V dalším a zároveň posledním dílu se zamyslíme, jak tedy začít s Quality Engineeringem v reálném projektu a „nezabít“ ho hned na začátku.
Nenechejte si ujít nejnovější informace.
Vyplňte nám vaši e-mailovou adresu a dostávejte pravidelnou nálož informací ohledně nadcházejících školení, akcí a testingového know-how.
Chcete poradit?
Napište si o naši bezplatnou, neprodejní konzultaci zdarma. Vyplňte formulář a my se vám ozveme zpět.
Hlídací pes
Nenašeli jste termín, který by vám vyhovoval? ....
Upozornění