Cross-platform testování: výběr konfigurací

Testování na více konfiguracích je relevantní zejména ve fázích testování, kdy je UI produktu stabilnější. Abychom zaručili maximální funkčnost aplikace pro co nejvíce koncových uživatelů, je nutné co nejlépe pokrýt nejen případy užití, ale i podmínky, ve kterých bude aplikace používána.

Vzhledem k množství proměnných a rychlosti vývoje nových verzí systémů a zařízení, nemůžeme nikdy pokrýt všechny případy. Snažíme se proto zvažovat zásadní prvky:

• typ zařízení,
• výrobce,
• operační systém,
• prohlížeč,
• rozlišení obrazovky,

podle kterých navrhujeme konfigurace k testování. Od návrhu k implementaci často narážíme na různé problémy. Povězme si, jak se k nim můžeme a máme stavět.

Pokud bychom chtěli být důkladnější, vždy můžeme přidat další parametry, mezi které patří například architektura systému, systémové zvětšení zobrazení, podpora dotykového ovládání, jazyk systému, používaný file system, úroveň uživatelských oprávnění a další.

1. Časté problémy při plánování a výběru konfigurací

1.1. Nevíme, co je důležité

Řešení je zároveň jednoduché i složité. Existuje řada placených či neplacených služeb a portálů poskytujících informace o popularitě prohlížečů, operačních systémů, rozlišení obrazovek a dalších ukazatelích. Podniky často také sledují tyto statistiky přímo u svých uživatelů skrz Google Analytics.

Při testování bychom měli pokrýt statisticky nejvýznamnější konfigurace těchto proměnných. Při analýze je nutné si dát pozor na kontext a data vstupující do sledovaných statistik. Proto se řídíme následujícími pravidly:

1. Vlastní data jsou lepší než data trhu
2. Používáme data na nejnižší možné úrovni přesnosti (země, kontinent, svět)
3. Data analyzujeme separátně pro osobní počítače, tablety i telefony
4. Verze Chrome, Safari, Firefox i IE agregujeme do jedné proměnné
5. Operační systémy dále dělíme na: 
   • Nové (trendová vlna)
   • Udržované (moderní, často se mění)
   • Podporované (často populární, vysoký podíl na trhu)
   • Nepodporované (často značný podíl na trhu)
   • Ukončené (netřeba testovat)
6. Rozlišení obrazovek mobilních zařízení analyzujeme podle dvou kontextů
   • Podle poměru stran
   • Podle podobnosti rozlišení (moderní zařízení často mívají unikátní rozlišení, ty často testujeme na nejbližším běžném rozlišení

1.2. Nemáme potřebná zařízení

Obecně chceme buď zajistit fyzická zařízení, nebo si pomoct virtualizací. Testování na fyzických zařízeních je vždy lepší z pohledu spolehlivosti. Virtualizovaná zařízení se nemusí vždy chovat stejně jako ta reálná.

Pokud investice do fyzických zařízení není možná, zvažujeme sdílení s okolními týmy či projekty. Čerpáme tak méně rozpočtu našeho projektu, ale přiděláváme si starosti s dostupností a správou zařízení.

Alternativně, podobně jako máme ve firmách služební počítače, můžeme si zřídit i služební testovací zařízení. Po počátečním trápení s minimálním počtem stejných zařízení pro jednotlivé konfigurace toto řešení funguje krásně s relativně malými náklady na průběžné rozšiřování a doplňování zařízení.

Můžeme si také pořídit službu, která správu těchto zařízení, případně jejich virtualizaci, řeší za nás. Na trhu dostupná řešení, například Sauce Labs, stále více podporují i automatizaci testů. Jsme v ranných fázích jejich používání namísto fyzických zařízení, proto očekáváme jejich průběžné zlepšování, co se týká rychlosti a stability v nejbližších letech.

1.3. Nedostatek zdrojů

Lidské zdroje, čas a finance dohromady určují objem práce, kterou na projektu budeme schopni vykonat. Dokážeme s nimi udělat jen velmi málo, pokud jsou fixní. Pokud nás ale trápí jeden nebo druhý natolik, že mu jsme ochotni podřídit spotřebu jiného zdroje, tak máme jisté možnosti.

Pokud máme fixní zdroje:

• Snížit rozsah testování
• Zvýšit kvalifikovanost lidí
• Eliminovat prostoje, zvýšit efektivitu
  • Silnější pracovní stanice, pomocný monitor
  • Řízení procesu a průběžná optimalizace
  • Vytvoření pracovního postupu
• Revidovat přístup k automatizaci
  • Vynechat zavádění nové automatizace
  • Podpořit údržbu automatů
  • Podpořit dobře škálovatelnou automatizaci

Pokud máme flexibilní zdroje:

• Posunout termín dokončení
• Nabrat více lidí do týmu
• Přidat profesionály v automatizaci pro
  • Funkční testy
  • Testy designu
  • Výkonnostní testy

2. Výběr konfigurací

Obecně nejprve určujeme, jaké konfigurace jsou pro nás relevantní, které bychom ideálně chtěli hlídat. Jejich rozsah poté snižujeme o ty:

1. které nastat nemohou,
2. které naše aplikace nepodporuje,
3. které sloučíme,
4. které jsou statisticky nevýznamné,
5. které se nevejdou do rozpočtu projektu.

Řekněme, že na projektu hledáme konfigurace pro testování, z analýzy nám vyšlo, že nás zajímají operační systémy Windows 10, Mac OS a Linux, prohlížeče Chrome, Firefox, IE a Safari v rozlišeních 480p, 720p, 1080p a 1440p. Z toho jsme schopni vytvořit 32 validních a 16 nesmyslných kombinací.

Provádět každý test 32krát je pro většinu projektů nerealistické, potřebujeme je nějak snížit. Pomocí výše uvedených kroků tyto konfigurace snížíme na 16, což je stále příliš. Jaké jsou naše možnosti?

• Dále snižovat počet konfigurací
• V každém kole testovat pouze některé konfigurace, tak aby na konci testování byly všechny vyzkoušeny
• Pokrýt méně prioritní testy méně konfiguracemi

2.1. Konfigurace metodou Pairwise

Jedná o přístup, kdy redukujeme počet konfigurací tak, abychom v nich maximalizovali počet nezávislých kombinací dvou parametrů. Uvažujme z výše uvedené situace, že jsme redukovali rozlišení na 720p a 1080p, tím jsme získali 16 racionálních konfigurací, viz Tabulka 1: Racionální konfigurace.

Tabulka 1: Racionální konfigurace

Tabulku optimalizujeme tak, že odstraníme opakující se páry proměnných. Na konci procesu budeme mít ideálně jednu konfiguraci s kombinací Windows – Chrome, jednu konfiguraci s kombinací Chrome – 1080p.

V praxi se nejspíš nepodaří vytvořit ideální sadu konfigurací bez opakování. Referenčním výsledkem je Tabulka 2: Pairwise kombinace konfigurací. Minimální počet řádků je zde určen kombinacemi operačního systému a prohlížeče. Kombinace prohlížeče a rozlišení také nejsou ideální, Chrome a Firefox testujeme dvakrát na stejném rozlišení, zatímco IE a Safari netestujeme na všech rozlišeních.

Tabulka 2: Pairwise kombinace konfigurací

Metoda Pairwise je o něco složitější, než jak je zde na jednoduchém příkladě uvedena a její těžiště leží v jejím praktickém využití nad konkrétním příkladem, proto nejlepší, co lze v tomto ohledu udělat, je odkázat zájemce na kurz praktické test analýzy, kde se aplikaci této metody mimo jiné věnujeme.

2.2. Přiřazení konfigurací k testům

Konfigurace přiřazujeme k testům obvykle teprve tehdy, kdy už víme kolik času na testování máme a jak dlouho bude trvat provedení jednoho testu. Když víme, že chceme provést 800 testů, ale máme čas na provedení pouze 300 z nich, je třeba začít škrtat. Neškrtáme už ale konfigurace, ale jejich příslušnost ke scénářům.

Běžně používáme dva přístupy, přiřazení podle priority nebo podle průchodu aplikací. Přiřazování dle priority spojí nejdůležitější testy a nejvýznamnější konfigurace a primárně se zaměřuje na ně. Zbylé testy dle klesající priority jsou testovány na méně konfiguracích. Testy s nejmenší prioritou tak mohou být testovány pouze v jedné konfiguraci, nebo být vyřazeny úplně.

Rozdělení dle priorit ale často soustředí mnoho úsilí na malou část aplikace. Procházíme pak stejnou obrazovku mnohokrát ve všech konfiguracích a může se stát, že jiné obrazovky neprojdeme v některých konfiguracích ani jednou.

Proto často vytipujeme menší sadu testů, která prochází všemi obrazovkami aplikace a tu provádíme ve všech konfiguracích. Případně obdobně jako při výběru konfigurací pairwise metodou, rozdělíme konfigurace mezi alternativní průchody danými obrazovkami. Tím si zajistíme, že všechny obrazovky byly otestovány ve vybraných konfiguracích a zůstane nám více prostoru pro zodpovědné testování důležitých funkcionalit a procesů.