Testování Windows aplikací: praktický plán

Windows aplikace může v demo režimu vypadat upraveně a přesto v pondělí ráno zpomalit provoz. Neuložený dodací list, uživatel zablokovaný po třech neúspěšných pokusech, nebo dialog tisku, který po aktualizaci reaguje jinak, nejsou kosmetické chyby. Kdo chce vědět, jak testovat Windows aplikace, by proto neměl začínat jednotlivými tlačítky, ale procesy, které stojí práci, peníze, nebo sledovatelnost.

Právě ve skladu, dílně, dispozici, a administrativě probíhá mnoho kritických procesů přes desktopový software vyvíjený v průběhu let. Tam nezáleží na tom, zda je testovací případ působivě formulován. Rozhodující je, zda zaměstnanci spolehlivě dokážou vykonávat své úkoly za realistických podmínek - i při neúplných datech, měnících se oprávněních, pomalých sítích, a neplánovaných přerušeních.

Testování Windows aplikací začíná kritickými procesy

Nezaslouží si každá funkce stejné úsilí při testování. Zřídka používaný export s manuálním dopracováním je třeba hodnotit jinak než zaúčtování příjmu zboží, vytvoření štítku, nebo denní odsouhlasení objednávek. Začněte proto jednoduchou otázkou: co se konkrétně stane, pokud tento proces selže?

Vysokou prioritu mají procesy s přímým vlivem na zásoby, dodávku, fakturaci, bezpečnost, nebo komunikaci se zákazníkem. Sem patří například přihlášení a kontrola práv, vytvoření a změna kmenových dat, zaúčtování transakcí, tisk dokumentů, rozhraní na ERP nebo přepravní služby, jakož i obnovení po chybě. I funkce, které používá jen malá skupina lidí, mohou být kritické, pokud blokují měsíční uzávěrku nebo uvolnění zboží.

Z těchto procesů nevznikají abstraktní seznamy testů, ale sledovatelné pracovní kroky. Test příjmu zboží by mohl například začít existující objednávkou, zaznamenat částečnou dodávku, nahlásit odchylné množství, přiřadit skladové místo, a poté ověřit, zda se shodují zásoby, protokol zaúčtování, a vytištěný dokument. Tak testujete skutečný účinek softwaru, nejen jednotlivá vstupní pole.

Vytvořit testovací základnu, která odráží provoz

Mnohé chyby se stanou viditelnými až tehdy, když se testovací prostředí přiblíží realitě. Aplikace se s prázdným testovacím nájemcem často chová jinak než s víceletými pohybovými daty, blokovanými artikly, chybějícími povinnými informacemi, nebo již otevřenými transakcemi.

Proto vědomě vytvořte testovací data. Nemusíte nutně potřebovat úplnou kopii produkce. Smysluplnější je kontrolovaný soubor dat s typickými, hraničními, a záměrně chybnými případy: artikly s různými měrnými jednotkami, zákazníci se speciálními podmínkami, objednávky s částečnými dodávkami, uživatelé s různými rolemi, a transakce, které jsou již ve zpracování. Osobní údaje by měly být přitom anonymizovány nebo nahrazeny realistickými vzorovými daty.

K testovací základně patří i technické prostředí. Dokumentujte verzi Windows, rozlišení, škálování, nainstalované tiskárny, síťové disky, verzi databáze, připojené služby, a oprávnění. Zní to suchopárně, ale později to šetří čas. Pokud se chyba vyskytuje jen na pracovištích se škálováním 125% nebo s určitým ovladačem tiskárny, musí to být reprodukovatelné.

Neověřovat jen ideální případ

Ideální případ především dokazuje, že aplikace byla postavena pro očekávanou cestu. V provozu vznikají obtížné situace vedle toho. Co se stane, pokud uživatel nechá povinné pole prázdné, spustí stejné zaúčtování dvakrát, nebo ztratí spojení během ukládání? Zůstává transakce konzistentní? Dostane osoba srozumitelnou zprávu? Může bezpečně pokračovat v práci?

U Windows aplikací jsou kromě toho obzvlášť relevantní obsluha a stav. Dialogová okna se mohou objevit na pozadí, klávesové zkratky se mohou překrývat, dialogy výběru souborů mohou blokovat průběh. Ověřte, zda jsou fokus, chybová hlášení, a blokování jednoznačné. Technická výjimka bez pokynu k jednání nepomůže vedoucímu směny.

Manuální testy nasadit tam, kde je potřeba úsudek

Manuální testy nejsou znakem nedostatečné vyspělosti. Jsou nepostradatelné, když vzniká nový proces, přestavuje se rozhraní, nebo o kvalitě rozhoduje odborné poznání. Zkušený vedoucí skladu rozpozná rychleji než skript, zda je maska srozumitelná pod vysokým časovým tlakem, nebo zda se upozornění objeví příliš pozdě.

Manuální testování se však stává nákladným a nespolehlivým, když se stejné stabilní procesy opakují před každou verzí. Pak uvolnění závisí na dostupných osobách, paměti, a roztroušených poznámkách. Správný přechod na automatizaci se obvykle nachází tam, kde se proces vykonává často, může způsobit velkou škodu, a má jasné očekávané výsledky.

Dobrý manuální testovací případ popisuje výchozí situaci, kroky, očekávaný výsledek, a potřebná data. Při chybě doplňte snímek obrazovky, časové razítko, verzi aplikace a buildu, jakož i přesnou akci. "Tisk nefunguje" není použitelný popis chyby. "Po změně dodací adresy zůstává dialog tisku otevřený, objednávka 4711 nedostane PDF, a nezobrazí se žádná zpráva" je.

Automatizované regresní testy pro opakující se rizika

Automatizace neověřuje, zda je software zásadně dobrý. Ověřuje, zda dříve fungující, definované procesy fungují i po změně. To je obzvlášť cenné u Windows softwaru, jehož rozhraní, logika databáze, a externí rozhraní se vyvíjejí po léta.

Začněte malým krokem. Vyberte si nejprve pět až deset obchodně kritických procesů, které by se měly ověřovat při každém vydání. Sem mohou patřit přihlášení s account-lockout postupem, zadávání objednávek, skladové zaúčtování, tisk PDF nebo štítků, změna role, a centrální import. Až když tyto testy běží spolehlivě, vyplatí se rozšíření na speciální případy.

U desktopových aplikací automatizované testy často řídí viditelné prvky rozhraní: okna, vstupní pole, tabulky, tlačítka, a dialogy. To funguje, ale je citlivější než čistý test rozhraní. Malé změny rozvržení, pomalejší počítače, nebo nejednoznačně pojmenované prvky mohou testy pokazit. Proto by vývojáři, odborný útvar, a odpovědní za testování měli společně určit, které prvky jsou stabilně adresovatelné a které kontrolní kroky je lepší zajistit přes databázi, protokol, nebo rozhraní.

Smysluplný test navíc neověřuje jen to, že se dalo kliknout na tlačítko. Kontroluje odborný důsledek: bylo zaúčtování uloženo? Je zásoba správná? Byl vytvořen dokument? Nebyl vytvořen duplicitní záznam? Viditelná interakce a ověřitelný výsledek patří k sobě.

Důkazy jsou součástí výsledku testu

Samotný zelený stav u kritických aplikací málokdy stačí. Když test selže, týmy rychle potřebují odpověď na tři otázky: jaká byla výchozí situace? Na jakém kroku proces selhal? Co aplikace v tom momentě zobrazovala?

Snímky obrazovky, protokoly průběhu, a případně záznamy obrazovky dělají chyby předmětem diskuse. Výrazně zkracují předání mezi provozem, QA, a vývojem. Pro regulované nebo bezpečnostně uvědomělé společnosti jsou navíc spolehlivým základem pro sledování schválení a odchylek.

Přitom místo uložení není vedlejší záležitostí. Testovací běhy mohou obsahovat interní zákaznická data, ceníky, informace o objednávkách, nebo pohledy na obrazovku. Kdo automatizovaně testuje citlivé Windows aplikace, by měl objasnit, zda tato data smí opustit vlastní infrastrukturu. Samostatně hostované prostředí jako COCO zde může být smysluplné, protože provádění testů, důkazy, a hodnocení zůstávají pod vlastní kontrolou. Zda je to nutné, závisí na požadavcích na ochranu údajů, smluvní situaci, a potřebě ochrany - ne každý tým potřebuje k tomu stejnou architekturu.

Zabudovat testování do procesu vydávání

Nejlepší katalog testů ztrácí hodnotu, pokud se použije až po hektickém nasazení do produkce. Definujte pevný okamžik: automatizované jádrové regrese běží před každým vydáním, manuální akceptace ověřuje nové nebo změněné procesy, a známá omezení se otevřeně dokumentují.

Nemusí každý neúspěšný test zastavit vydání. Chyba ve zřídka používaném administrativním zobrazení může být přijatelná, pokud existuje bezpečné řešení a dotčená oblast je jasně informována. Chyba, která nesprávně zaúčtuje zásoby nebo nepozorovaně zablokuje uživatele, se musí řešit jinak. Toto rozhodnutí by se mělo přijmout podle obchodního dopadu, ne podle pouhého počtu červených testů.

Udržujte testy společně s aplikací. Když se proces záměrně mění, aktualizujte testovací případ, testovací data, a očekávaný výsledek společně s požadavkem. Zastaralé testy vytvářejí šum a nakonec se ignorují. Několik důvěryhodných kontrol je cennějších než stovky automatizovaných procesů, jejichž výsledky už nikdo nebere vážně.

Nakonec nejde o simulaci každého myslitelného vstupu. Jde o ochranu práce, která musí opět fungovat další ráno. Začněte jediným kritickým procesem, učiňte jeho výsledek prokazatelným, a stavějte odtud dál.