Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : Testování IT služby
Testování IT služby
Kód úlohy

Standardní kód úlohy v MBI.

:
U104A
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Gottfriedová, K. (KIT, VŠE)
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.8
Charakteristiky úlohy

Charakteristiky úlohy

1. “Testování IT služby“ – cíl, účel

Cílem úlohy je zajistit, aby výsledná služba odpovídala původním požadavkům ze strany businessu (tedy aby odpovídala svou povahou původně stanovenému účelu) a zároveň byla na odpovídající kvalitativní úrovni (tedy aby byla připravena k použití a neobsahovala chyby).

2. Obsah úlohy

Testování služby respektuje principy testování aplikací a technologií v daných provozních podmínkách. Testuje se na vybraných testovacích datech, které tvoří vzorek z běžně užívaných dat v dané oblasti. Součástí jsou také zátěžové testy a testy bezpečnosti provozu služby.

Během úlohy je na základě testovací strategie a testovacího plánu otestována:

  1. existující funkcionalita služby na vady, pomocí testovacích případů,
  2. existující funkcionalita služby v porovnání s požadovanou funkcionalitou definovanou business požadavky.

Testování probíhá několika fázemi testů:

  1. Funkční testování jednotlivých částí – může probíhat již během vývoje,
  2. Smoke testy – vždy po nasazení nové verze pro zjištění stavu služby, zda je možné vůbec testovat,
  3. Integrační testování – komunikace mezi jednotlivými komponentami, možná též již během vývoje,
  4. Systémové testování – po dokončení vývoje, zda služba funguje jako celek,
  5. Akceptační testování – po dokončení vývoje, zda služba odpovídá požadavkům.

Provádějí se i následující speciální typy testů:

  • penetrační testy – testování bezpečnosti,
  • zátěžové testy – testování výkonnosti,
  • regresní testy – ovlivňuje-li služba nějaké původní služby, funkcionality atd..

Záleží na konkrétní situaci a službě. Některé z fází se často spojují dohromady. Jaké testy a za splnění jakých podmínek by měly být provedeny je vždy přesně uvedeno testovací strategií. Časový rámec pak stanovuje testovací plán.

Celý proces úlohy je koordinován v rámci test managementu zajištěného test koordinátorem. Tvorba testovací strategie a plánu je v kompetenci test koordinátora. Provedení testovací analýzy a vytvoření testovacích požadavků, testovacích případů a případných dalších speciálních testů je většinou delegováno na test analytika, který za to zodpovídá. Test koordinátor pak koordinuje samotné testování a přecházení mezi jednotlivými fázemi testován í v závislosti na určených podmínkách v testovací strategii.

Při vývoji externími zdroji, začíná testování, až když je předána celá aplikace dodavatelem. Je vhodné se s dodavatelem dohodnout, že bude aplikaci dodávat po menších celcích a bude tak možné začít s testováním dříve. Čím později se chyby nebo případné změny objeví, tím větší budou náklady. Pak se přidává fáze funkčních testů po menších celcích – je vhodné tomu upravit testovací případy a napsat je tak, aby bylo možné je spouštět po předem definovaných celcích.

Při externím vývoji mají začít co nejdříve testovat business vlastníci, aby se co nejdříve začal prověřovat účel služby a splnění jednotlivých požadavků.

3. Vstupy úlohy:
  • Analytická a provozní dokumentace IT služby (D116A ),
  • Testovací strategie (D117A ),
  • Katalog IT služeb (D111A ),
  • Katalog požadavků na IT (D042A ),
  • Procesní dokumentace podniku (DQ003A ),
  • Katalog datových zdrojů (D211A ),
  • Specifikace technologických standardů (D232A ).
4. Výstupy úlohy:
  • Protokol o testování IT služby (D112A ),
  • Analytická a provozní dokumentace IT služby (D116A ), aktualizovaná,
  • Katalog IT služeb (D111A ), aktualizovaný.
5. Podmínky úspěšnosti úlohy
  • informovanost organizace o důležitosti testování a možných dodatečných nákladech či nebezpečí nepoužitelnosti vyvinuté služby,
  • úroveň komunikace ve firmě mezi IT a business,
  • používaný systém pro reportování chyb a celý proces reportování chyb a change management,
  • způsobilost testerů k testování (samostatnost, schopnost objevování možných souvislostí),
  • ochota business vlastníků spolupracovat,
  • úroveň dostupných testovacích dat!!!,
  • stabilita testovacího prostředí,
  • míra shody testovacího a live prostředí, testovacích a reálných dat.
6. Doporučené praktiky
  • Je vhodné, existuje-li jedna osoba (nejčastěji test koordinátor), který spravuje reportované defekty a change requesty (CR) v reportovacím systému. Posílá defekty vedoucímu týmu vývojářů, případně při retestech vývojáři zabývajícího se daným problémem. CR posílá k hrubé analýze business analytikovi před možným schválením, zda se bude CR implementovat či ne.
  • Vše je vhodné spravovat v  jediném nástroji (např. JIRA), který je schopný zvládnout jednoduše workflow potřebné pro danou organizaci.
  • Po každé iteraci je vhodné udělat report a odeslat ho všem zúčastněným stranám.
  • Při vytváření testovací analýzy by měl být k dispozici business analytik pro možné konzultace nad jednotlivými nejasnostmi ve specifikaci služby či k dodatečným analýzám objevených problémů.
  • Je vhodné, jde-li business analýza společně s testovací analýzou (testovací analýza začne ještě před koncem etapy tvorby specifikace služby a před započetím samotného vývoje).
  • Testovací analýzu by měl před schválením projít business analytik a okomentovat, zda dostatečně pokrývá jím specifikovanou službu.
  • Testeři by pak měli mít k dispozici jak testovací, tak business analýzu v dostatečném předstihu před započetím testovací periody.
  • Pro kompletní otestování funkcionality i účelu služby je vhodná kombinace testovacích požadavků a testovacích případů.
  • Za každou konkrétní oblast (business požadavek) by měl být odpovědný jeden business vlastník. Všichni tito business vlastníci by měli být aktivně zapojeni do testování a odpovědní za konečné rozhodnutí, zda je jejich požadavek splněn či ne.
  • Při reportování chyb je vhodné určovat jejich závažnost a prioritu opravy.
7. “Testování IT služby“ - klíčové aktivity

7.1. Nastavení a zajištění průběžného řízení testů IT služby

Činnost probíhající v průběhu celé úlohy, zajišťující její správný chod (vykonávanou test koordinátorem)., tj.:

  1. sledování stavu a informování všech stran o průběhu testování,
  2. zařizování relevantních podmínek pro testování,
  3. porovnávání skutečnosti s testovacím plánem a jeho aktualizace.
7.2. Plánování testování

Definování zodpovědností za testy, specifikace typů testů, jejich následnosti a nutných podmínek pro spuštění daných testovacích fází, definování způsobu akceptace a odsouhlasení akceptačních kritérií, definování workflow pro opravu chyb, +Design testů - vytvoření testů v závislosti na testovací strategii, vytváření testovacích požadavků a testovacích případů pro systémové a akceptační testování, volba způsobu testování pro jednotlivé testovací fáze (manuální, automatické), analýza a pořízení potřebných testovacích dat.

7.3. Ověření plánu a designu

Zhodnocení, zda testovací strategie a testy pokrývají dostatečným způsobem službu.

7.4. Příprava testovacího prostředí, příprava a zajištění testovacích dat.
7.5. Provedení testů

Průchod definovanými testovacími fázemi dle testovací strategie:

  1. spouštění tesů, zaznamenávání jejich výsledků, reportování chyb a požadavků na změnu,
  2. retestování opravených chyb a regresní testování (je nutné se vracet i k tomu co již bylo otestováno při velkých změnách).
7.6. Report, zhodnocení výsledků a rozhodnutí o další iteraci testování či akceptování služby.
7.7. Uzavření testovacích činností a zhodnocení plánu a strategie testování.