TestWatchman je v podstatě interceptor, který můžete zavěsit na události failed, finished, starting a succeeded. Ukažme si na následujícím příkladě, jak zareagovat na neúspěšný test a zjistit jméno třídy a název testu. Tento string používáme jako jméno screenshotu v našich selenium testech. Metoda failed se volá jak při assertationFailed tak při výjimce.

import static junit.framework.Assert.fail;

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.MethodRule;
import org.junit.rules.TestWatchman;
import org.junit.runners.model.FrameworkMethod;

public class MyTest {

	@Rule
	public MethodRule watchman = new TestWatchman() {
		@Override
		public void failed(Throwable e, FrameworkMethod method) {
			String methodName = MyTest.this.getClass().getSimpleName() + "." + method.getName();
			System.out.println(methodName + " has failed!");
		}
	};

	@Test
	public void testFailed() {
		fail();
	}

}

Obvykle každý ví, že rodná čísla se tvoří od roku 1954 ve tvaru yymmdd/xxxx a ta starší mají tvar yymmdd/xxx. Pokud je to žena, přičte se k měsíci 50. Také si každý myslí, že by mělo být rodné číslo dělitelné jedenáci. Ale zde je právě kámen úrazu. Vše je trochu jinak.

Poslední desátá číslice přidávaná od roku 1954 je kontrolní a tvoří se tak, že se vydělí devitimístné číslo jedenácti a zbytek po dělení se použije jako desátá kontrolní číslice. Tím je výsledné desetimístné číslo dělitelné jedenácti. Tedy v případě, že zbytek po dělení nebyl 10. V takovém případě je kontrolní číslice rovna 0, ale tím pádem není celé rodné číslo dělitelné jedenácti. Do roku 1985 bylo přiděleno cca 1000 rodných čísel, která nejsou dělitelná 11. Není vyloučeno, že se v minimálním počtu vyskytly i po tomto roce.

Navíc od roku 2004 je zavedena možnost v případě, že jsou v nějaký den vyčerpána všechna platná čtyřčíslí, použít alternativní rodné číslo, u kterého mají muži k číslu měsíce přičteno 20 a ženy 70. A i rodná čísla před rokem 1954 mohou mít čtyřčíslí, pokud se jednalo o dodatečně přidělená rodná čísla (např. při získání občanství).

Více informací třeba na Wikipedii nebo na tomto blogu.

Většina aplikací se spokojí s ověřením dělitelnosti jedenácti. Ale to je evidentně špatně. Ještěže nemám tu smůlu a nemám nestandardní rodné číslo

Napsal jsem pro účely Selenium testů generátor rodných čísel s několika možnostmi, jak číslo generovat:

• pro konkrétní datum a pohlaví
• pro věkové rozpětí – vhodné třeba pro generování mladistvých
• oficiální rodné číslo – dle výše popsaných pravidel
• běžné rodné číslo – takové, které čeká většina aplikací – dělitelnost 11, standarní tvary
• speciální rodné číslo – takové, které není běžné – vhodné pro test validace

Ukázka použití generátoru:

// generates random personal number from 1900 till today
String personalNumber = RcGenerator.generateRc();

// men between 18 and 30
personalNumber = RcGenerator.generateRcForAge(18, 30, Gender.MALE);

// common personal number modulo 11 == 0 which passes most validators
personalNumber = RcGenerator.generateRc(RcType.COMMON);

Přiložené třídy můžete volně použít. Budu rád, když najdete chyby nebo generátor vylepšíte, rozšíříte funkčnost a s kódem se zase podělíte.

RcGenerator.zip

Pozor na pořadí anotací! Řešení popsané ve zmiňovaném článku volá nejprve metodu anotovanou @After a poté teprve @AfterFailure. To samo o sobě není problém, pokud stejně jako my v metodě anotované @After nevoláte metodu Selenium#stop(), která zavírá prohlížeč. To pak vám je získaný snímek obrazovky k ničemu. Rešení je jednoduché, stačí v runneru jen prohodit volání metod v metodě #withAfters(FrameworkMethod, Object, Statement).

@Override
protected Statement withAfters(FrameworkMethod method, Object target, Statement statement) {
      statement = withAfterFailures(method, target, statement);
      return super.withAfters(method, target, statement);
}

Věřím, že vám snímky v případě selhání Selenium testů ušetří čas při opravování bugů.

Edit
JUnit od verze 4.7 má svoje řešení jménem TestWatchman.

Tyto scénáře testů nazýváme „testovanými scénáři“, anglicky test case, zkratkou TC. Co je to TC? Co by měl obsahovat? TC je soubor vstupů, kroků i podmínek a očekávaných výstupů. Ale kde ho vezmeme?

Každá analýza vyvíjeného systému by měla obsahovat případy užití (use cases), dále UC. Tyto scénáře užití lze s výhodou použít pro vytvoření seznamu TC. Jak na to? Ukážeme si na následujícím příkladu.

Nyní máme zpracovaný zcela jednoduchý UC, kde máme základní průchod aplikací. Bohužel svět není jednoduchý a ani náš příklad nemůže být takto jednoduchý. Je zapotřebí se zamyslet a definovat další toky, kterými může tento scénář být přerušen, či pokračovat zcela jinou cestu. Jedná se o tzv. Alternate flows.

Nyní si sepíšeme do tabulky pod sebe všechny možné scénáře, a pojmenujeme si je. Pojmenování volte rozumně, neboť by se mělo používat skrze celé testování.

Teď již máme identifikovány hlavní scénáře, které budeme potřebovat otestovat. Pro vlastní testování však toto ještě nestačí. Musíme definovat vstupy a očekávané výstupy jednotlivých TC. Vstupy lze identifikovat dle rozhodovacích bloků v UC. Každé alternative flow by mělo být způsobeno nějakou příčinou, vstupem. V našem případě máme situaci poněkud zjednodušenou. V reálných systémech jsou i desítky vstupů. Zde lze s výhodou použít excel, či vhodný TC management nástroj.

V našem případě dochází k startu alternate flow 3 v scénáři č.4: Datum splatnosti v minulosti.
Je tedy evidentní, že v tomto scénáři se rozhodne o provedení alternativního scénáře v bodě 6. Tudíž je zapotřebí zadat číslo faktury, částku a datum splatnosti. Číslo faktury a částka je validní a datum splatnosti je neplatné (Invalid). Další vstupy jsou již pro tento scénář irelevantní a v tabulce se neobjeví.

Nyní vyplňme tabulku. „V“ představuje potřebný validní vstup a „I“ invalidní vstup. Pokud na vstupech nezáleží nebo jsou irelevantní, zanechte příslušné buňku tabulky prázdnou. Názvy jednotlivých TC volíme ve sloupci TC ID# tak, aby odpovídaly testovanému scénáři. V našem případě jde o evidenci faktury, zvolil jsem tedy zkratku IE (Invoice Evidence). V případě velkých systémů nám toto pojmenování pomůže v orientaci.

Nyní máme tabulku validních a nevalidních vstupů. Víme, na kterých vstupech záleží úspěšnost dané operace. Připravíme si testovací prostředí tak, abychom mohli splnit tyto scénáře. Dost často mají UC tzv. preconditions. Tyto precondititons například říkají, že uživatel, který chce založit jiného uživatele, musí mít administrátorská práva. Musíte tedy do systému před začátkem testovaní založit uživatele s administrátorskými právy.
Na základě takto připraveného testovacího prostředí jste již schopni definovat konkrétní tabulku s konkrétními vstupy.
V našem případě vypadá například takto. Pokud používáte excel, doplňte si tabulku o sloupce precondition a postconditions. Tam definujte, co je zapotřebí udělat před spuštěním testu a zároveň co má tester udělat po ukončení testu. (například po sobě v aplikaci uklidit).

Dost často na svých školeních se setkávám s názorem, že tento postup je příliš přebyrokratizovaný a prý zdržuje. Praxe ovšem ukazuje, že problémem není vyplnění tabulky, ale neochota některých (test) analytiků se dopředu zamyslet a definovat tyto scénáře a vstupy. Pokud se ovšem nechcete smířit s intuitivním testováním a postoupit například až k objektivnímu měření kvality, zavedení podobných pravidel vás nejspíše nemine.

Pozorný čtenář teď zareaguje: Vždyť v těch TC nemám přeci kroky, jak mám postupovat? Tehdy ale nehledáme artefakt TC ale Test Script. Čili postup, kterým bude tester postupovat při ověřování konkrétního testovaného případu. Test Scripty psát je časově náročné a mnohdy se musí s měnící aplikací znovu přepisovat. Proč je tedy píšeme?

Rozdíl mezi TC a Test Script je v době jejich vzniku a v tom, kdo tyto artefakty vytváří. Zatímco k definici TC dochází na začátku projektu a provádí je test analytik (dosti často i analytik projektu), tak Test Scripty si píší sami testeři.

Oblast okolo názvů, tvorby TC a organizace práce je natolik rozsáhlá, že by vydala na několik článků. Pokud máme menší projekty a sdílené role, potřebujeme relativně malý aparát. Pokud ovšem projekt přerůstá určitou hranici, je zapotřebí zvolit adekvátní metody přístupu k testování.

Předchozí díl: Úvod seriálu

• Obchodník neví jak nabízet QA
• Zákazník netuší, proč by QA měl platit, chtít a vyžadovat.

Hledal jsem přirovnání, které by pomohlo odstranit tuto neznalost a vysvětlit člověku neznalému softwarového vývoje, proč je QA nezbytné.

Začínáme

Potřebuje Vaše firma vyvinout software na míru? Vyberte si spolehlivého dodavatele, neboť výběr kvalitního dodavatele je polovinou úspěchu.
Co prosím? Pouze polovinou? Cožpak dobrý dodavatel nezaručí úspěšnost projektu?
Nezaručí. Abyste skutečně dostali software, jaký potřebujete, bude se i Vaše firma muset naplno zapojit do vývoje – a právě na nezkušenosti zadavatele krachuje značná část softwarových projektů.

zdroj: flickr.com / CC BY 2.0

Vývoj softwaru jako stavba domu

Vývoj softwaru na míru se dosti podobá stavbě domu, hlavně v tom, neboť jak stavba domu, tak i vývoj softwaru Vás nakonec může stát daleko více, než jste původně čekali. Pro omezení tohoto rizika je zapotřebí se pečlivě připravit, nepodcenit plánování, najmout dobrého architekta a na samotnou realizaci najmout stavební dozor, který je nezávislý a zajistí dobrou kvalitu stavby. Tohle je stejné ve stavebnictví i při vývoji aplikací. Pouze v IT místo stavebního dozoru nastupuje QA.

Jak budete stavět? (zajištění prostředků)

Dnes si již málokdo postaví dům svépomocí. Splnit všechny normy a požadavky je příliš složité, než aby to běžný člověk dokázal sám zvládnout. Najmout ty správné lidi je první podmínkou úspěchu. Ale dokážete to?
Poraďte se s někým, kdo se na trhu vyzná, vyžádejte si reference a zajistěte, aby Váš nezávislý dozor byl opravdu nezávislý. Dejte si pozor na příliš nízké, ale i neobvykle vysoké cenové nabídky. A nezapomeňte na průběžné testování po celou dobu projektu, neboť náklady na odstranění chyby v hotovém softwaru mohou být mnohonásobně vyšší, než když je chyba odhalena v raných stádiích vývoje.

Co budete stavět? (stanovení cílů)

Než začneme, je třeba se rozhodnout, co budeme stavět – zda rodinný dům, chatu, garáž nebo činžák. Víte to u Vašeho softwaru? Řeknete-li dodavateli „Potřebuji program na mzdy“, bude z toho asi tak moudrý jako když architektovi řeknete „Chci dům na bydlení“. Ale kolik má mít pater a místností, pro kolik lidí je určen, jakému životnímu stylu má dům vyhovovat, jak má být vybaven? Mnoho otázek je třeba zodpovědět i při vývoji softwaru a je na dodavateli, aby Vám ty správné otázky položil. Ale jak zjistíte, že opravdu nic nezanedbal? Je zřejmé, že již ve fázi plánování budete potřebovat nezávislého poradce, který zajistí, že cíle projektu se opravdu budou shodovat s Vašimi skutečnými potřebami.

Kde budete stavět? (integrace)

Při stavbě domu je nesmírně důležité také okolí. Je na Vašem pozemku zavedená voda, elektřina, plyn, je zde telefonní signál? Nebude stát pozemek vedle čističky či dálnice? Jak snadno se Vaše dítě dostane do školy?
I ve Vaší firmě již určitě je nějaké softwarové prostředí, běží tu další aplikace a je téměř jisté, že bude třeba nějak je s novým systémem propojit. Tomuto procesu říkáme integrace a může výrazně zvýšit náklady na realizaci projektu. Abyste se vyvarovali nepříjemných překvapení, je třeba integraci předvídat a zahrnout ji do svých plánů i finančních odhadů.

Opravdu se staví to co chcete? (testování)

Jak zjistit, zda se staví přesně to, co chceme? Jste schopni poznat na základě diagramu tříd, zda je vše v pořádku? U stavby to poznáte? Stojí zdi tam kde chci? To zjistíte letmým pohledem. Ale jsou zdi postaveny tak jak mají? Má vrstva malty správnou tloušťku? Je tloušťka zdi dostatečná? Nezkazí zedník práci hned zítra? Tohle jsou věci, které musíme pečlivě kontrolovat v průběhu celé stavby.
I u softwaru musíme provádět kontroly kvality průběžně. Ponechat testování až na dodání produktu může být cestou do pekel. Testování není pouze finální proklikání aplikace, ale důsledná kontrola, ověřování a měření po celou dobu softwarového vývoje.

Bude dům pořád stejný? (rozvoj)

Stavba se vydařila, dům stojí a dokonce se v něm dá i bydlet. Ale ouha, místo plánovaného potomka se narodily trojčata a jeden pokoj jim už nestačí. Co s tím? Je možné dům upravit nebo dokonce něco přistavět? Nebo budete potřebovat jiný dům?
Stejné problémy řeší i provozovatelé firemních aplikací – firma se rozrůstá a stávající software přestává stačit. V platnost vstupují nové směrnice a zákony a aplikace se jim musí přizpůsobit. Úpravy jsou nezbytné, ale nerozbije zdánlivě drobná změna celý systém?
Pokud dodavatel při vývoji nedodržel správné postupy a neodevzdal kvalitní práci, může i malá změna vést k nutnosti přepracovat velké části softwaru. To může vést k neadekvátním nákladům, oprava může trvat neúměrně dlouho a můžete se dokonce stát „rukojmím“ nesolidního dodavatele, který těží z toho, že jediný rozumí Vašemu systému, a tudíž je nenahraditelný.
Co s tím?
Opět doporučujeme si najmout tzv. „stavební dozor“ a dopředu zhodnotit návrh systému. Mezi firmami dodávajícími software totiž existuje spousta garážových firem, které se naoko tváří jako profesionální. Ovšem kvalita jejich práce bývá mizerná a tyto firmy přežívají právě díky tomu, že se staly nenahraditelnými pro své odběratele, neboť jejich aplikacích a řešením nemá šanci nikdo jiný rozumět. V době realizace je tedy vhodné kontrolovat architekturu aplikace a zároveň dohlížet na použité technologie, kvalitu kódu i kvalitu architektury. Pouze kvalitní produkt je dále udržovatelný bez výrazného nárůstu investic.

Proč zrovna stavebnictví

Proč jsem si zvolil zrovna tento příklad? Většina lidí, co má pravomoc rozhodnout povětšinou staví, nebo již má postaveno. Budete-li se s nimi bavit, jsou Vám schopni odvykládat kompletní několikahodinové historky o zkušenostech se stavbou svého domu. Lze tedy využít jejich zkušenosti v náš prospěch.
Máte podobnou zkušenost i vy? Museli jste někdy obhajovat testování jako takové v projektu? Napište nám svoje zkušenosti.

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?

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.

Ohodnoťte rizika

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.

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ě:

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).

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

<!-- Define LogDigger filter -->
<filter>
    <filter-name>LogDigger Servlet Filter</filter-name>
    <filter-class>org.logdigger.servlet.filter.LogDiggerServletFilter</filter-class>
</filter>

<!-- Define mapping for the LogDigger filter -->
<filter-mapping>
    <filter-name>LogDigger Servlet Filter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

V našem případě jsem do AspectWorks Frameworku přidal wrapper filter tak, aby šel filter konfigurovat ve Springu, ale to je pouze detail. Wrapper si můžete prohlédnout v příloze.

Do  browseru se potom nainstaluje plugin integrující s FireBugem. Můžete pak sledovat přímo serverové logy vztažené k HTTP požadavku. Lze nastavit i úroveň, takže třeba sledujete jenom ERROR zprávy. Uvidíme, jak se to osvědčí při testech. Předpokládám, že testeři budou moci snadněji poznat, jestli došlo opravdu k chybě, a bude pro ně snazší přikládat logy do bugreportů.

LogDigger umožňuje konfigurovat také appender pro Log4J, takže můžete sledovat jen vybrané části aplikace a vynechat například hlášky z použitých knihoven. Atribut allowLogLevelChange povoluje měnit log level i přímo z prohlížeče.

# appender to customize output to LogDigger Firefox plugin
log4j.appender.logdigger=com.logdigger.connector.log4j.LogDiggerAppender
#log4j.appender.logdigger.allowLogLevelChange=false

Do budoucna plánuje LogDigger integrovat i s aplikací JIRA pro snadné vkládání logů do hlášení chyb. Tak uvidíme.