Testovanie Windows aplikácií: praktický plán

Windows aplikácia môže v demo režime vyzerať upravene a napriek tomu v pondelok ráno spomaliť prevádzku. Neuložený dodací list, používateľ zablokovaný po troch neúspešných pokusoch, alebo dialóg tlače, ktorý po aktualizácii reaguje inak, nie sú kozmetické chyby. Kto chce vedieť, ako testovať Windows aplikácie, by preto nemal začínať jednotlivými tlačidlami, ale procesmi, ktoré stoja prácu, peniaze, alebo sledovateľnosť.

Práve v sklade, dielni, dispozícii, a administratíve prebieha mnoho kritických procesov cez desktopový softvér vyvíjaný v priebehu rokov. Tam nezáleží na tom, či je testovací prípad pôsobivo formulovaný. Rozhodujúce je, či zamestnanci spoľahlivo vedia vykonávať svoje úlohy za realistických podmienok - aj pri neúplných dátach, meniacich sa oprávneniach, pomalých sieťach, a neplánovaných prerušeniach.

Testovanie Windows aplikácií začína kritickými procesmi

Nezaslúži si každá funkcia rovnaké úsilie pri testovaní. Zriedkavo používaný export s manuálnym dopracovaním treba hodnotiť inak ako zaúčtovanie príjmu tovaru, vytvorenie štítku, alebo denné odsúhlasovanie objednávok. Začnite preto jednoduchou otázkou: čo sa konkrétne stane, ak tento proces zlyhá?

Vysokú prioritu majú procesy s priamym vplyvom na zásoby, dodávku, fakturáciu, bezpečnosť, alebo komunikáciu so zákazníkom. Sem patrí napríklad prihlásenie a kontrola práv, vytvorenie a zmena kmeňových dát, zaúčtovania transakcií, tlač dokumentov, rozhrania na ERP alebo prepravné služby, ako aj obnovenie po chybe. Aj funkcie, ktoré používa len malá skupina ľudí, môžu byť kritické, ak blokujú mesačnú uzávierku alebo uvoľnenie tovaru.

Z týchto procesov nevznikajú abstraktné zoznamy testov, ale sledovateľné pracovné kroky. Test príjmu tovaru by mohol napríklad začať existujúcou objednávkou, zaznamenať čiastočnú dodávku, nahlásiť odchýlené množstvo, priradiť skladové miesto, a potom overiť, či sa zhodujú zásoby, protokol zaúčtovaní, a vytlačený dokument. Takto testujete skutočný účinok softvéru, nielen jednotlivé vstupné polia.

Vytvoriť testovaciu základňu, ktorá odráža prevádzku

Mnohé chyby sa stanú viditeľnými až vtedy, keď sa testovacie prostredie priblíži k realite. Aplikácia sa s prázdnym testovacím nájomcom často správa inak než s viacročnými pohybovými dátami, zablokovanými artiklami, chýbajúcimi povinnými informáciami, alebo už otvorenými transakciami.

Preto vedome vytvorte testovacie dáta. Nemusíte nutne potrebovať úplnú kópiu produkcie. Zmysluplnejší je kontrolovaný súbor dát s typickými, hraničnými, a zámerne chybnými prípadmi: artikle s rôznymi mernými jednotkami, zákazníci so špeciálnymi podmienkami, objednávky s čiastočnými dodávkami, používatelia s rôznymi rolami, a transakcie, ktoré sú už v spracovaní. Osobné údaje by mali byť pritom anonymizované alebo nahradené realistickými vzorovými dátami.

K testovacej základni patrí aj technické prostredie. Dokumentujte verziu Windows, rozlíšenie, škálovanie, nainštalované tlačiarne, sieťové disky, verziu databázy, pripojené služby, a oprávnenia. Znie to suchopárne, ale neskôr to šetrí čas. Ak sa chyba vyskytuje len na pracoviskách so škálovaním 125% alebo s určitým ovládačom tlačiarne, musí to byť reprodukovateľné.

Neoverovať iba ideálny prípad

Ideálny prípad predovšetkým dokazuje, že aplikácia bola postavená pre očakávanú cestu. V prevádzke vznikajú ťažké situácie popri tom. Čo sa stane, ak používateľ nechá povinné pole prázdne, spustí rovnaké zaúčtovanie dvakrát, alebo stratí spojenie počas ukladania? Zostáva transakcia konzistentná? Dostane osoba zrozumiteľnú správu? Môže bezpečne pokračovať v práci?

Pri Windows aplikáciách sú okrem toho obzvlášť relevantné obsluha a stav. Dialógové okná sa môžu objaviť na pozadí, klávesové skratky sa môžu prekrývať, dialógy výberu súborov môžu blokovať priebeh. Overte, či sú fokus, chybové hlásenia, a blokovania jednoznačné. Technická výnimka bez pokynu na konanie nepomôže vedúcemu zmeny.

Manuálne testy nasadiť tam, kde je potrebný úsudok

Manuálne testy nie sú znakom nedostatočnej vyspelosti. Sú nevyhnutné, keď vzniká nový proces, prestavuje sa rozhranie, alebo o kvalite rozhoduje odborné poznanie. Skúsený vedúci skladu rozpozná rýchlejšie ako skript, či je maska zrozumiteľná pod vysokým časovým tlakom, alebo či sa upozornenie objaví príliš neskoro.

Manuálne testovanie sa však stáva drahým a nespoľahlivým, keď sa rovnaké stabilné procesy opakujú pred každou verziou. Vtedy uvoľnenie závisí od dostupných osôb, pamäti, a roztrúsených poznámok. Správny prechod na automatizáciu sa zvyčajne nachádza tam, kde sa proces vykonáva často, môže spôsobiť veľkú škodu, a má jasné očakávané výsledky.

Dobrý manuálny testovací prípad opisuje východiskovú situáciu, kroky, očakávaný výsledok, a potrebné dáta. Pri chybe doplňte snímku obrazovky, časovú pečiatku, verziu aplikácie a buildu, ako aj presnú akciu. "Tlač nefunguje" nie je použiteľný popis chyby. "Po zmene dodacej adresy zostáva dialóg tlače otvorený, objednávka 4711 nedostane PDF, a nezobrazuje sa žiadna správa" je.

Automatizované regresné testy pre opakujúce sa riziká

Automatizácia neoveruje, či je softvér zásadne dobrý. Overuje, či predtým fungujúce, definované procesy fungujú aj po zmene. To je obzvlášť cenné pri Windows softvéri, ktorého rozhrania, logika databázy, a externé rozhrania sa vyvíjajú roky.

Začnite malým krokom. Vyberte si najprv päť až desať obchodne kritických procesov, ktoré by sa mali overovať pri každom vydaní. Sem môžu patriť prihlásenie s account-lockout postupom, zadávanie objednávok, skladové zaúčtovanie, tlač PDF alebo štítkov, zmena role, a centrálny import. Až keď tieto testy bežia spoľahlivo, oplatí sa rozšírenie na špeciálne prípady.

Pri desktopových aplikáciách automatizované testy často riadia viditeľné prvky rozhrania: okná, vstupné polia, tabuľky, tlačidlá, a dialógy. To funguje, ale je citlivejšie ako čistý test rozhrania. Malé zmeny rozloženia, pomalšie počítače, alebo nejednoznačne pomenované prvky môžu testy pokaziť. Preto by vývojári, odborný útvar, a zodpovední za testovanie mali spoločne určiť, ktoré prvky sú stabilne adresovateľné a ktoré kontrolné kroky je lepšie zabezpečiť cez databázu, protokol, alebo rozhranie.

Zmysluplný test navyše neoveruje len to, že sa dalo kliknúť na tlačidlo. Kontroluje odborný dôsledok: bolo zaúčtovanie uložené? Je zásoba správna? Bol vytvorený dokument? Nebol vytvorený duplicitný záznam? Viditeľná interakcia a overiteľný výsledok patria k sebe.

Dôkazy sú súčasťou výsledku testu

Samotný zelený stav pri kritických aplikáciách málokedy stačí. Keď test zlyhá, tímy rýchlo potrebujú odpoveď na tri otázky: aká bola východisková situácia? Na akom kroku proces zlyhal? Čo aplikácia v tom momente zobrazovala?

Snímky obrazovky, protokoly priebehu, a prípadne záznamy obrazovky robia chyby predmetom diskusie. Výrazne skracujú odovzdanie medzi prevádzkou, QA, a vývojom. Pre regulované alebo bezpečnostne uvedomelé spoločnosti sú navyše spoľahlivým základom na sledovanie schválení a odchýlok.

Pritom miesto uloženia nie je vedľajšou záležitosťou. Testovacie behy môžu obsahovať interné zákaznícke dáta, cenníky, informácie o objednávkach, alebo pohľady na obrazovku. Kto automatizovane testuje citlivé Windows aplikácie, by mal objasniť, či tieto dáta smú opustiť vlastnú infraštruktúru. Samostatne hostované prostredie ako COCO tu môže byť zmysluplné, pretože vykonávanie testov, dôkazy, a hodnotenie zostávajú pod vlastnou kontrolou. Či je to potrebné, závisí od požiadaviek na ochranu údajov, zmluvnej situácie, a potreby ochrany - nie každý tím potrebuje na to rovnakú architektúru.

Zabudovať testovanie do procesu vydávania

Najlepší katalóg testov stráca hodnotu, ak sa použije až po hektickom nasadení do produkcie. Definujte pevný okamih: automatizované jadrové regresie bežia pred každým vydaním, manuálna akceptácia overuje nové alebo zmenené procesy, a známe obmedzenia sa otvorene dokumentujú.

Nemusí každý neúspešný test zastaviť vydanie. Chyba v zriedkavo používanom administratívnom zobrazení môže byť prijateľná, ak existuje bezpečné riešenie a dotknutá oblasť je jasne informovaná. Chyba, ktorá nesprávne zaúčtuje zásoby alebo nepozorovane zablokuje používateľov, sa musí riešiť inak. Toto rozhodnutie by sa malo prijať podľa obchodného dopadu, nie podľa samotného počtu červených testov.

Udržiavajte testy spolu s aplikáciou. Keď sa proces zámerne mení, aktualizujte testovací prípad, testovacie dáta, a očakávaný výsledok spolu s požiadavkou. Zastarané testy vytvárajú šum a nakoniec sa ignorujú. Niekoľko dôveryhodných kontrol je cennejších než stovky automatizovaných procesov, ktorých výsledky už nikto neberie vážne.

Napokon nejde o simuláciu každého myslitelného vstupu. Ide o ochranu práce, ktorá musí opäť fungovať na druhý deň ráno. Začnite jediným kritickým procesom, urobte jeho výsledok dokázateľným, a stavajte odtiaľ ďalej.