„Hlavně si udělat poznámky, aby to později dávalo smysl.“ To je taková klasická předkonferenční mantra. Jak to nakonec dopadne, všichni víme :-) Já se vždycky snažím si poznámky později utřídit a dát jim hlavu apatu. Z letošního Testing United mám ale pocit, že bude lepší, když to sepíšu tak, jak to přišlo.

Nejčastější slovo, které jste mohli začátkem listopadu ve vídeňské Expedithalle slyšet, byla jednoznačně umělá inteligence. Je vidět, že v automatizaci, strojovém učení, umělých neuronových sítích a umělé inteligenci, je budoucnost. Z pohledu testování bude nejspíš hrát čím dál tím větší roli, takže pokud ještě neovládáte žádný programovací jazyk, hurá do toho. Ať vám neujede vlak.

James Whittaker („ten chlap z Googlu, Microsoftu, IBM, …“) se podělil o pár zkušeností ze své práce. Věděli by jste například, jak otestovat Google Mapy? Ani v Googlu nevěděli, jak na to. Nakonec přidali do aplikace hlášení chyb, což jim přineslo spoustu zpětné vazby a nahlášených bugů. V podstatě zadarmo. Nevíte, jak s testingem začít? Navrhněte nástroj na hlášení chyb :-)

V druhé části se věnoval IoT a celkově věcem kolem nás, které řídí počítače. Dnes už je totiž počítač skoro každé elektronické zařízení. Vaše chytrá televize je vlastně počítač s televizní anténou. Váš telefon je … no, takhle bych mohl pokračovat donekonečna.

A tohle je jeden z důvodů, proč má testování smysl. Software se objevuje ve věcech každodenní potřeby, kdy používáním takového produktu může jít o život. Třeba v autech.

Testovat dá ale i metro. Greet Burkels mluvila o tom o tom, jak řídila uživatelské testování amsterdamského metra.

Když už jsem zmínil ta auta, tak ta samořiditelná bylo další velké téma, o kterém se zmínil snad každý řečník. Software pro taková auta se z velké části učí z reálných dat, ale využívá i různé simulace, nebo počítačové hry (GTA). O výzvách v automobilovém průmyslu měl celou přednášku Roman Nagy z mnichovksého AID.

Stejně jako na silnici, i u obrazovky je potřeba očekávat neočekávané. Z přednášky Rona Wernera z QualityMinds mám hlavně poznámky týkající se toho, jak přistupovat k testování. Není to vlastně žádná novinka, ale opakování je matka moudrosti: Analyzujte co a jak děláte a vyhodnocujte, jaký to má přínos. Vykašlete se na činnosti, které nic nepřináší a naopak hledejte nové cesty. Kombinujte a testuje na více úrovních. To, že projde jeden scénář neznamená, že v dané části aplikace není chyba. Testute zleva, zprava, ...

„Test cases se snažte psát tak, aby odhalily bugy, ne aby potvrdili funkčnost aplikace.“

Bohužel jsem si nezapsal, kdo toto řekl. Nespokojte se jen s popisem bugu, snažte se zjistit jeho příčinu - možná se dostanete hlouběji do aplikace a odhalíte něco mnohem většího.

Nezapomínejte, že testování není jen o tom, zda je aplikace kvalitní z hlediska funkčnosti, ale také použitelnosti. Chápou uživatelé, k čemu jsou jednotlivé položky v menu? Je jasná kontextová nabídka?

Zajímavá byla myšlenka, jak by mohla umělá inteligence pomáhat v testování. Pokud bude mít k dispozici dostatečná a kvalitní data, může nás sledovat během průchodu aplikací a navrhovat další kroky, jako například „zkus tady zadat záporné číslo“, „co udělá aplikace, když otočíš telefon“, … Ze sledování toho, jak se chovají uživatelé, může sama sestavit testovací scénáře. A potom je i provádět.

Kvalitní data jsou základ pro strojové učení. Jeden příklad za všechny: aplikace pro rozpoznání obrázků rozpozná na fotce psa Husky. Někdy ho ale označí jako vlka. A důvod? Pokud je Husky na fotce, kde je sníh, je označen jako vlk. Ve zdrojových datech byl totiž vlk vždy na fotce se sněhem. Místo aplikace na rozpoznání Huskyho tak máte aplikaci na rozpoznání sněhu.

Jak můžete začít hned? Hledejte anomálie v chování aplikace, výsledcích testů nebo třeba rohledáváním logů. Určete si referenční hodnoty a sledujte anomálie. Trvá odpověď aplikace o 100 ms déle, než ve všech předchozích testech? Roste s každou verzí velikost logu? Na první pohled maličkosti, ale můžou odhalovat závažné problémy a jejich odhalení je přitom brnkačka.

Já například nosím už delší dobu v hlavě nápad na testování aplikace porovnáváním screenshotů a proto mě potěšilo, že R. Lawgmin & M. Laskowski z Cognifide představili nástroj AET, který umí porovnávat aktuální stav webové aplikace oproti referenčním datům - HTML kódu a screenshotům. Kromě toho umí hlídat i další věci. Na našem projektu sice použít nejde (Java), ale nakoplo mě to v dalším bádání. Já si nakonec vystačím zřejmě s protractor-image-comparison.

Na konferenci mi trochu chyběly nějaké praktické ukázky, něco co by člověk mohl hned použít. Většinou se jednalo spíše o takové vizionářské, motivační přednášky o tom, jak by mohlo testování v budoucnu vypadat.

Tak co, pustíte se do nějakého toho machine learningu, nebo umělé inteligence? Možná bude stačit začít s programováním. Nemusíte se hned pouštět do psaní nějaké brutální aplikace. Začněte s nějakým menším skriptem, který za vás bude dělat nějaké rutinní denní úkoly. Jak říká Donald Knuth, „programování vám pomůže chápat svět“ a já s tím můžu jen souhlasit. Najděte si mentora, někoho, s kým můžete probírat konkrétní skripty a nápady. On-line školení a kurzy jsou sice fajn, ale většinou vás přestanou bavit a skončíte u druhé lekce. Nechte si ukázat, jak napsat první jednoduchý skript a zbytek najdete na Google/StackOverflow.

Na napsání tohoto článku jsem se chystal od skončení konference. Možná jsem měl využít rady poslední přednášející, Karen N. Johnson, která říkala něco ve smyslu: „Prostě začněte psát, vemte papír a tužku a pište. Třeba z toho nic nebude, třeba ano. Sepište nápady a pak je analyzujte“.

Celou fotogalerii najdete na mém Google Disku.

Já tu mám ještě pár nápadů, které jsme si zapsal a nebylo kam do článku vměstnat:

• Přidat možnost hlášení chyb - textový popis, v příloze screenshot, uživatelská data, logy, apod.
• Jednou za čas projít vyřešené bugy a napsat ke každému krátký automatický test
• V automatizaci se nezaměřovat jen na UI, ale i na backend/API. UI se čas od času mění a testy je potřeba neustále aktualizovat.
• Vytvořit sdílené úložiště testovacích dat pro různé druhy testů.
• Pokusit se znovu prosadit uživatelské testování
• Podílet se na schvalování pull requestů
• Mind mapy na generování testovacích scénářů
• „Don't develop yourself - develop team“
• Pokud akce nevyvolá reakci, uživatel nemusí vědět, co se děje „na pozadí“