Pokud se dnes mluví o metodikách vývoje softwaru, opakují se nejčastěji dva pojmy - agilní metodiky a RUP. Tomu druhému bych se tu chtěl dnes blíže věnovat a protože jsem tester tak se chci zaměřit na roli testování v této metodice.

RUP je zkratka pro Rational Unified Software a skrývá se za ní propracovaná metodika vývoje softwaru. Už jsem tu v jiném článku psal o teoretických přístupech k metodikám vývoje. RUP představuje reálně použitelný rámec, v rámci kterého je možné efektivně řídit vývoj aplikací. Autorem této metodiky je společnost Rational Software Corporation, která je od roku 2003 součástí firmy IBM. Není tedy divu, že právě IBM zavádění této metodiky aktivně podporuje. K dispozici je celý balík nástrojů, které jsou na této metodice založené a slouží k jejímu efektivnímu použití.

RUP se nejčastěji popisuje pomocí diagramu. Já si tu vypůjčím jeden z Wikipedie.

Jen rychlý popis tohoto diagramu. Na spodní x ose je vynesen čas, tedy plnyutí času od počátku projektu do jeho konce. V horní části té samé osy je projekt rozdělen do čtyř fází - Zahájení, Rozpracování, Konstrukce, Předání. Osa y zobrazuje činnosti, ze kterých se vývoj softwaru skládá. Tedy činnosti od sběru požadavků, přes analýzu, vývoj až po testování a nasazení.

Na první pohled se zdá, že RUP je jen podrobnější formou "vodopádu". Ne že by to byla úplně zcestná představa. Ten základní princip tu skutečně uplatněn je. Už z logiky věci vyplývá, že činnosti i fáze ve vývoji softwaru jdou více méně po sobě a tím tedy také vzniká ten "vodopádový" efekt. Ovšem RUP je mnohem více orientován itertivně. Totiž v každé fázi vývoje, tak jak existují v rámci RUP, probíhá v několika opakováních s tím, že jsou definované podmínky jak pro další iteraci tak pro ukončení fáze. 

RUP je metodika značně formální. Tím chci říci, že je zde uplatňován princip "co je psáno to je dáno". Z grafu je patrné, že pro každou fázi je možné rozdělit do jakýchsi bloků dle činností, které se dané fázi provádějí. U každého takového bloku je jasně dáno, kdo má za činnosti v něm odpovědnost, co má dělat a především co je je vstupem a výstupem daného bloku. A těmito vstupy a výstupy jsou právě nejrůznější dokumenty. Navíc jsou pro každou fázi definovány milníky, které říkají, v jakém stavu se musí projekt na konci dané fáze nacházet aby bylo možné přejít do fáze další.

Tato formálnost má svá pozitiva i negativa. Mezi pozitivní stránky lze počítat fakt, že díky všem těmto dokumentům je možné získat v kterýkoli okamžik poměrně přesnou představu o stavu projektu. Navíc je díky ním možné vysledovat, kde a proč došlo v projektu k problémům a chybám. A samozřejmě kdo je za ně odpovědný. Za negativum se dá považovat fakt, že přemíra dokumentace, kterou je nutné vytvářet a přitom nemá přímou souvislost s vyvíjeným produktem, může představovat nárůst pracnosti a tím i času nutného pro vývoj.

Je dobré si říct, že RUP není neměnným kusem kamene. Samotná IBM umožňuje a podporuje přizpůsobení této metodiky konkrétním potřebám toho kterého projektu.

Testování v RUP

RUP je metodika, která je na testování postavena. To příliš nepřeháním. Na diagramu je patrné, že je zde samostatná činnost Testování a tato činnost má svůj začátek již brzy po začátku projektu. Tedy ve chvíli, kdy se teprve vytváří analýza a definují se požadavky. Důraz na testování je ale kladen i mimo tuto konkrétní činnost. Většina bloků, které zde jsou, v sobě obsahuje nějakou formu revizí a ověřování správnosti. Je tak ověřována správnost uživatelských požadavků, ke revidována analýza a podobně.

I samotná činnost Testování je zde "rozpadlá" na celou řadu úkolů. Ty zde mají plnit čtyři testerské role: Test Manager, Test Analytik, Test Designer a Tester. Tak jak jsem je tu sepsal za sebou, taková je i jejich hierarchie v rámci testování v RUP. 

Jak by mělo dle RUP vypadat testování? Ve stručnosti asi takto:

1. Je určeno co a proč se bude testovat (tedy jaká oblast má být testována a s jakým cílem) a jaká jsou výstupní kritéria z testů. (Test Manager)

2. Stanovení způsobu testů. Tedy jaké konkrétní testy by se měly provádět, jaká je pro ně požadovaná konfigurace testované aplikace, jaké nástroje budou použity. (Test Analytik)

3. Vytváření testů. Jsou připraveny testy, včetně testovacích dat, a ty jsou spojovány do logických celků. (Test Designer)

4. Smoke testy. Ověření, že aplikace je vhodná pro testy. Tedy je nainstalovaná, spuštěná a stabilní. Tento bod obsahuje jak přípravu tak provedení těchto testů. (Test Designer, Tester)

5. Provedení testů. Tester provádí konfiguraci aplikace dle vstupních požadavků daného testu a spouští test. Případné rozdíly oproti očekávanému stavu jsou v požadovaném formátu hlášeny. (Tester)

6. Vyhodnocení testů. Je provedena analýza výsledků testů. Nalezené rozdíly jsou v podobě žádostí o změnu předány k další analýze. Výstupem testů je Test report, který předává informace o rozsahu provedených testů a jejich výsledku. (Test Manager)

Toto je vlastně popis jedné iterace, přičemž v každé iteraci se mohou provádět odlišné testy.

Pro mě je RUP sympatický právě svým důrazem na kvalitu výsledku. Jeho filozofií je nalézt co nejvíce problémů již v průběhu vývoje. Pokud vezmeme obvyklý model, kdy testování je prostě jen konečnou fází vývoje a právě při testování je možné a nutné nalézt co nejvíce chyb, pak je přístup metodiky RUP rozhodně pozitivní změnou. Testování zkrátka musí být součástí všech fází vývoje. Jen tak je možné zajistit, aby se až na konci celého procesu neřešily problémy vzniklé například na úrovni analýzy nebo dokonce ve fázi sběru požadavků.

Musím se bohužel přiznat, že jsem nikdy neviděl RUP skutečně reálně a smysluplně implementovaný. Mnoho firem deklaruje, že jejich proces vývoje je postaven na RUP. Realitou ale je, že rozsáhlost a velká formálnost této metodiky vede často jen k její omezené implementaci. Jinak řečeno, RUP počítá s velkým počtem rolí. V reálném životě je mnoho těchto rolí spojováno do jedné pracovní pozice. A z toho plyne postupná ztráta výhod, které RUP přináší. Čím menší je počet rolí, které se na vývoji podílejí, tím menší je také schopnost zachytit dostatečně včas možný problém. Pokud dochází k redukci RUP při jeho implementaci, často jsou vynechávány právě činnosti spojené s revizí a ověřováním výstupů činností. Malý tým zkrátka neumožňuje provádět opakované revize dokumentů, které při vývoji vznikají. Riziko zavlečení chyby až do fáze vývoje a testování je tak velké. Tomu nepomáhá ani fakt, že redukovaný bývá i počet a rozsah dokumentů.

Abych to nějak shrnul. RUP je dle mě dobrá metodika. Minimálně v teoretické rovině. Představuje dobrý výchozí bod pro tvorbu vlastních metodik. Ovšem její pozitiva jsou vyrovnána jejími negativy, které většino vedou k tomu, že metodika RUP není vůbec implementována nebo je implementace nedostatečná. Upřímně se nedivím, že firmy dnes raději sahají k agilním metodikám, které jsou vlastně postavené na nedostatcích, které má metodika RUP. Tedy nejsou formální a dokáží se pružněji přizpůsobit různým podmínkám.