Rozdíly mezi testováním, řízením/kontrolou kvality a zajištěním/prokazováním kvality

V praxi mnozí členové vývojového týmu, počítaje v to programátory, testery, manažery…, pojmy „testování“, „řízení/kontrola kvality“ (QC)  a „zajištění/prokazování kvality“ (QA) chybně zaměňují. V softwarovém průmyslu jsou velmi často odborníci na testování zároveň mylně označováni jako profesionálové na QA. Nejednou někdo hovoří o QA, ale myslí QC nebo testování. S tímto fenoménem se velmi často setkávám kupodivu také na odborných konferencích či v tematické literatuře. QA oddělení máme samozřejmě také v našem sdružení, přičemž s tímto faktem se setkávám i zde. Několik kolegů z jiných organizací se mi svěřilo, že takové rozpory v jejich týmech bývají příčinou napjatých rozhovorů, ale též takový stav vnímají jako kontraproduktivní.

Pojďme se tedy ve stručnosti seznámit s tím, čím testování, QC a QA jsou.

Testování

Testováním se snažíme zjistit, jestli software splňuje specifikované požadavky, které jsou na něj kladeny a objevovat odchylky od požadovaného stavu – chyby. Avšak testeři nejenže kontrolují splnění samotných specifikovaných požadavků, ale také prověřují, jestli specifikované požadavky naplňují představy zákazníka. Požadavky sdělují, „jaký“ (latinsky „qualis“) vyvíjený software má být. Jaké má mít vlastnosti. Software může mít mnoho typů kvalit a dokonce existují modely, které softwarové charakteristiky úhledně obecně kategorizují. Například mezinárodní norma ISO/IEC 25010 nebo model atributů kvality FURPS.

ISO/IEC 25010 popisuje osm charakteristik: funkčnost, účinnost, kompatibilita, použitelnost, bezporuchovost, bezpečnost, udržovatelnost, přenositelnost. A pro každou z nich určuje další subcharakteristiky; třeba pro přenositelnost adaptabilitu, instalovatelnost, nahraditelnost.

FURPS je akronym složený z počátečních písmen podstatných znaků kvality, na které se zaměřuje: funkčnost (funkcionality), použitelnost (usability), spolehlivost (reliability), výkonnost (performance), rozšířitelnost (supportability).

Řízení/kontrola kvality (QC)

Testování je jednou z činností kontroly kvality. Ačkoli testování softwaru je dominantní součástí kontroly kvality softwaru, kontrola kvality může zajít dál než testování. Kontroluje také kvalitu všech faktorů, které se podílejí na vývoji, například dodržování domluvených pravidel, předpisů, procesů, porovnává výsledky testů různých verzí softwaru atd. a poskytuje zpětnou vazbu o příčinách problémů s kvalitou softwaru. Z tohoto pohledu má kontrola kvality charakter inspekce dle ISO 9000 „hodnocení shody pozorováním a posouzením doplněné podle vhodnosti měřením, zkoušením nebo srovnáváním“.

Kontrola kvality z pohledu procesu reaguje na nějaký výstup. Různými nástroji a technikami se snaží identifikovat a eliminovat defekty.

V softwarovém průmyslu se velmi často „quality control“ překládá jako „kontrola kvality“. Slovo „control“ do češtiny však můžeme přeložit také jako „řídit“ či „regulovat“. V praxi nám nejde jen o to, abychom věděli, zda je nebo není výstup „OK“, což je předmětem činnosti kontroly kvality/testování, ale chceme také zjistit, proč výstup není „OK“, co je příčinou špatného stavu a chceme tomu nějak zabránit. Proto je vhodnější hovořit spíše o „řízení kvality“ než o „kontrole kvality“.

Řízením kvality systematicky sledujeme a vyhodnocujeme kvalitu vznikajícího softwarového produktu a případnou nápravu se snažíme zajistit ještě před jeho vydáním.

Uvedené pojetí „řízení kvality“ ale nesmíme zaměňovat s pojmem „management kvality“. Slovo „management“ se běžně nepřekládá a může být interpretován také jako „řízení“ – v tomto duchu je obsahová interpretace odlišná od výše uvedeného pojetí „řízení kvality“. Management kvality je nutné chápat z pohledu vedení a řízení organizace, pro které kvalita má význam a proto se na ni zaměřuje.

Zajištění/prokazování kvality (QA)

Mnohé činnosti řízení/kontroly kvality slouží také pro sledování jednotlivých fází procesu vývoje, které je náplní zajištění kvality. Zajištění kvality má za cíl zabraňovat vzniku defektů zlepšováním vývojových a testovacích procesů. Má tedy charakter preventivní.

Cílem QA je zajistit, aby software splňoval dané požadavky na kvalitu.

„Quality assurance“ se běžně překládá buď jako „prokazování kvality“ nebo jako „zajištění kvality“. Termín „prokazování kvality“ má blíže k pojetí ve smyslu definice ISO 9000 – „část managementu kvality zaměřená na poskytování důvěry, že požadavky na kvalitu budou splněny“. V tomto duchu má blízko k řízení/kontrole kvality. Termín „zajištění kvality“ však o něco více inklinuje k managementu kvality, který v sobě (podle ISO 9000) obsahuje určení politiky a cílů kvality, plánování kvality, řízení kvality, zlepšování kvality a také právě prokazování kvality.

 

Obrázek - První model QA, QC, testování

Častý model QA zahrnující také QC a testování.

 

Obrázek - Druhý model QA, QC, testování

Zvláště v případech, kdy je kladen větší důraz na nezávislost QA, se používá model, ve kterém je QA postaveno vedle QC.

Jak je vidět, testování, QC a QA spolu velmi úzce souvisejí. Ale neznamenají totéž, ačkoli významová hranice mezi nimi nejenže není ostrá, ale naopak je nesnadno rozeznatelná. Zatímco QC se zaměřuje na řízení a ověřování kvality výstupů (systému, komponent, dokumentace…), QA je soustředěno na prevenci před vznikem kvalitativních nedostatků. Pomocí QA se snažíme zajistit, aby procesy vývoje, testování a údržby softwaru byly dostačující k tomu, aby softwarový systém byl „bezvadný“. Jednou z činností QC je testování, kterým zjišťujeme defekty. QA bez QC a QC bez QA postrádají smysl – vytváří společný systém zaměřený na kvalitu. Množství různých procesů, které by nám mohly zajistit vyšší kvalitu vyvíjeného softwaru, nám jsou k ničemu, pokud není kontrolován. Podobně k ničemu jsou různé neopakovatelné kontroly bez jasného cíle, systému, postupů…

V mnoha organizacích samozřejmě může být pojetí kýžených pojmů odlišné. Za nejdůležitější považuji, aby lidé v týmech hovořili společným jazykem a tyto pojmy si ujasnili. Čtenář jistě rád svým komentáře přispěje svými zkušenostmi, za které budeme samozřejmě velmi vděční.

Autor:

Komentáře (1)

  1. Petr Roudenský říká:

    Pěkně shrnuto, toto je opravdu častý problém nejen v ČR. Doplnil bych, že na vině jsou/bylyi standardy typu IEEE 610, který QA nesmyslně definoval jako soulad s technickými specifikacemi a u QC uváděl, že ve světě SW nemá ekvivalent. Nicméně tento standard je již dávno neaktivní,
    Dovolil bych si lehce nesouhlasit se zobrazením QC „uvnitř“ QA – samotné ISO 9000 totiž oboje QA a QC klade na stejnou úroveň jako jednotlivé součásti managementu kvality. Ovšem tento typický obrázek lze vykládat jako závislost, což máte hezky shrnuto v předposledním odstavci. I zde je však třeba říct, že QC bez QA existuje – jde o čistě reaktivní přístup, typický pro malé společnosti využívající tradiční vodopád.
    Z pohledu definic a pochopení rolí QA a QC je velmi užitečný model CMM(i), který koneckonců vnesl při svém uvedení konečně jasné rozlišení mezi oběma funkcemi.
    Nejjednodušší rozlišení pro ty, kteří stále tapou – QA se zaměřuje na defekty procesní, zatímco QC na ty produktové.

Napsat komentář: Petr Roudenský Zrušit odpověď na komentář

Všechny údaje jsou povinné. E-mail nebude zobrazen.

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..