Zdeněk Jonáš
26.8.2009

Testujme s rozumem: Seriál



Jak rozumně začít testovat malý nebo středně velký softwarový projekt? Jako specialista na oblast testování a kvality se čas od času dostanu do rozjetého projektu, kde mám pomoci při testování aplikací. Povětšinou se nejedná bohužel o výpomoc, ale o záchranu projektu. Proč k tomu dochází? 

Málokdy jsem se setkal s rozumnou přípravou práce pro testery. Povětšinou neexistovaly ani definované cíle testování, natož popsané jednotlivé testované případy apod. Ale ve většině případů testeři netestovali to, co bylo skutečně zapotřebí. Pokud začínáte projekt a potřebujete začít nějakým rozumným způsobem řídit testování a aktivity testerů, právě pro vás je určena tato série článků. Provede vás postupně celým procesem testování.

Jak začít?

Máme projekt, vyhranou zakázku nebo prostě potřebujeme začít testovat. Jak začít? Co dát testerům?

Potřebujete klíčové vlastnosti

Začněte tím, že si definujte (pokud ještě nemáte) podmínky úspěchu. Odpovězte si na otázku: Co musí software (produkt) splňovat, aby byl úspěšný? Co musí umět?

Příklad:

Představme si implementaci systému správy výpůjček do knihovny. Co náš systém musí splňovat?

  • Systém umožní vyhledat konkrétního klienta knihovny.
  • Systém umožní vyhledat konkrétní knihu k vypůjčení.
  • Systém umožní zobrazit historii výpůjček daného klienta.
  • Systém poskytne statistiku o vypůjčovaných knihách.


Co se může stát

Nyní si projděte seznam těchto klíčových vlastností a definujte, co všechno se může zkazit, přerušit, přestat fungovat a tím ohrozit splnění požadavků na produkt. Jinými slovy, identifikujte produktová rizika.

Příklad:

Co se může přihodit v našem knihovním systému?
  • Seznam uživatelů nemusí být dostupný.
  • Seznam knih nemusí být dostupný.
  • Systém neuloží výpůjčku, knihy nepůjde půjčit.
  • Systém neuloží vrácení knihy, uživatelé budou následně pokutováni.


Ohodnoťte rizika

Dopad:
Jednotky uživatelů 1
Skupiny uživatelů 2
Všichni uživatelé 3
Pravděpodobnost:
Pravděpodobně nenastane 1
Může nastat 2
Velmi pravděpodobně nastane 3

Nyní provedeme kvalifikaci rizik. Není to nic těžkého. Pouze ohodnotíme, jak jsou daná rizika pro nás podstatná. Jinými slovy, jak moc si jich musíme všímat. Ohodnotíme si rizika například od 1 do 3, a to dle dopadu a pravděpodobnosti výskytu. S tím, že 1 bude nejméně vážný stav a 3 nejhorší možnost. Můžete si zvolit svoje rozsahy a zvolit dokonce vlastní typ rizika. Například místo dopadu, můžete v určitých aplikacích kalkulovat s finanční ztrátou.

Příklad:

Riziko Dopad Pravděpodobnost
Systém uživatelů nemusí být dostupný. 3 1
Seznam knih nemusí být dostupný. 2 1
Systém neuloží výpůjčku, knihy nepůjde půjčit. 3 2
Systém neuloží vrácení knihy, uživatelé budou následně pokutováni 3 3


Definujte si tabulku závažností

Zde doporučuji použít metodu MoSCoW. Metoda dělí jednotlivá rizika na Must test, Should test, Could test a Won’t test. Hodnoty v tabulce jsou součinem jednotlivých vah vynesených na jednotlivých osách tabulky.

Závažnost = Dopad * Pravděpodobnost

Bodové hodnocení je čistě na vás. Zde pro názornost jsme je zvolili následovně:

Příklad:

  Pravděpodobnost
1 2 3
Dopad 1 1 2 3
2 2 4 6
3 3 6 9
Závažnost Zvolená kategorie
1 Won’t test (nemusíme testovat)
2-3 Could test (můžeme testovat)
4-5 Should test (měli bychom testovat)
6-9 Must test (musíme testovat)


K čemu to bylo dobré

Nyní máme identifikovaná produktová rizika projektu, máme definovanou jejich závažnost a víme, které jsou pro nás z hlediska úspěšnosti projektu důležité a kterým je zapotřebí věnovat nejvíce síly a energie. Můžeme rovněž prohlásit, že ověření těchto rizik jsou naše cíle testování (Test target).

Příklad:

Riziko Závažnost Kategorie
Systém uživatelů nemusí být dostupný. 3 Should test
Seznam knih nemusí být dostupný. 2 Could test
Systém neuloží výpůjčku, knihy nepůjde půjčit. 6 Must test
Systém neuloží vrácení knihy, uživatelé budou následně pokutováni. 9 Must test


Co dále

Pokud máte k dispozici test analytika, ten by měl být schopen s tímto vstupem efektivně pracovat. Pokud ho nemáte a není k dispozici senior tester, musíme ještě naši práci doplnit testovanými scénáři (test cases). Získání „Test case“ z „Use case“ a další metody získávání potřebných scénářů pro testování budou náplní dalšího článku v tomto seriálu. Následující díl: Jak z UC získat TC

Vaše emailová adresa nebude zveřejněna

Komentáře

Děkujeme za váš komentář
Další
  • David Mach

    Zrovna se chystám ve firmě evangelizovat automatické testování, takže mi tento seriál přijde vhod. Už se těším na další pokračování!

  • ufak

    Prima, serial budu sledovat, protoze testovani je ted moje oblibene tema. Jen poznamku: v "Systém umožní vyhledat konkrétní knihu k vypůjčení." je UseCase Vyhledání knihy nebo Vypůjčení knihy ?

  • Petr Podzimek

    Pěkný článek! Kdy bude pokračování?

  • ufak: Nojo, to že systém umožňuje půjčovat a vracet knihy by tam asi být mělo :-)

  • Zdeněk Jonáš

    ufak: Určitě by tam tento UseCase měl být. A s ním spousta dalších. Vybral jsem pouze 4, aby tyto příklady byly krátké. Petr Podzimek: Času je málo, ale budu se snažit.

  • jjjjj

    pekny clanok na uvod. tesim sa na pokracovanie. a plz zvacsite si pismo, je velmi drobne (i ked nenosim okuliare)

  • Petr Heller Kostroun

    Hezký článek, určitě se těším na další pokračování.

  • Písmo jsem zvětšil, snad to teď bude čitelnější.

  • uf

    Ahoj, kdy bude pokracovani?