Windows-sovellusten testaus: käytännönläheinen suunnitelma

Windows-sovellus voi näyttää siistiltä demotilassa ja silti hidastaa toimintaa maanantaiaamuna. Tallentamaton toimituskirja, kolmen epäonnistuneen yrityksen jälkeen lukittu käyttäjä, tai päivityksen jälkeen eri tavalla reagoiva tulostusvalintaikkuna eivät ole kosmeettisia bugeja. Sen, joka haluaa tietää, miten Windows-sovelluksia testataan, ei siis pitäisi aloittaa yksittäisistä painikkeista, vaan prosesseista, jotka maksavat työtä, rahaa, tai jäljitettävyyttä.

Juuri varastossa, korjaamolla, jakelussa, ja hallinnossa monet kriittiset prosessit kulkevat vuosien varrella kasvaneen työpöytäohjelmiston kautta. Siellä ei ole merkitystä sillä, onko testitapaus vaikuttavasti muotoiltu. Ratkaisevaa on, voivatko työntekijät suorittaa tehtävänsä luotettavasti realistisissa olosuhteissa - myös epätäydellisillä tiedoilla, vaihtuvilla oikeuksilla, hitailla verkoilla, ja suunnittelemattomilla keskeytyksillä.

Windows-sovellusten testaus alkaa kriittisistä prosesseista

Kaikki toiminnot eivät ansaitse samaa testauspanostusta. Harvoin käytettyä vientiä manuaalisella jälkikäsittelyllä on arvioitava eri tavalla kuin tavaran vastaanoton kirjaamista, tarran luontia, tai päivittäistä tilausten täsmäytystä. Aloita siis yksinkertaisella kysymyksellä: mitä konkreettisesti tapahtuu, jos tämä prosessi epäonnistuu?

Korkea prioriteetti on prosesseilla, joilla on suora vaikutus varastoon, toimitukseen, laskutukseen, turvallisuuteen, tai asiakasviestintään. Näihin kuuluvat esimerkiksi kirjautuminen ja oikeustarkistus, perustietojen luonti ja muuttaminen, transaktiokirjaukset, asiakirjatulostus, rajapinnat ERP- tai lähetyspalveluihin, sekä toipuminen virheestä. Myös pienen käyttäjäjoukon käyttämät toiminnot voivat olla kriittisiä, jos ne estävät kuukausisulkemisen tai tavaroiden vapauttamisen.

Näistä prosesseista ei synny abstrakteja testilistoja, vaan jäljitettäviä työvaiheita. Tavaran vastaanoton testi voisi esimerkiksi alkaa olemassa olevalla tilauksella, kirjata osatoimituksen, ilmoittaa poikkeavan määrän, osoittaa varastopaikan, ja sitten tarkistaa, vastaavatko varasto, kirjauslokis, ja tulostettu asiakirja toisiaan. Näin testaat ohjelmiston todellista vaikutusta, et vain yksittäisiä syöttökenttiä.

Luo testipohja, joka kuvastaa toimintaa

Monet virheet tulevat näkyviin vasta, kun testiympäristö lähestyy todellisuutta. Sovellus käyttäytyy usein eri tavalla tyhjän testivuokralaisen kanssa kuin usean vuoden liiketapahtumadatan, estettyjen tuotteiden, puuttuvien pakollisten tietojen, tai jo avattujen tapahtumien kanssa.

Luo siksi testidataa tietoisesti. Sinun ei välttämättä tarvitse täydellistä kopiota tuotannosta. Järkevämpi on hallittu tietokanta tyypillisillä, raja- ja tarkoituksella virheellisillä tapauksilla: tuotteet eri mittayksiköillä, asiakkaat erikoisehdoilla, tilaukset osatoimituksilla, käyttäjät eri rooleilla, ja tapahtumat, jotka ovat jo käsittelyssä. Henkilötiedot tulisi anonymisoida tai korvata realistisella esimerkkidatalla.

Testipohjaan kuuluu myös tekninen ympäristö. Dokumentoi Windows-versio, resoluutio, skaalaus, asennetut tulostimet, verkkoasemat, tietokantaversio, liitetyt palvelut, ja käyttöoikeudet. Se kuulostaa kuivalta, mutta säästää aikaa myöhemmin. Jos virhe esiintyy vain työasemilla, joissa on 125 prosentin skaalaus, tai tietyllä tulostinajurilla, sen on oltava toistettavissa.

Älä tarkista vain ihanteellista tapausta

Ihanteellinen tapaus todistaa ennen kaikkea, että sovellus on rakennettu odotettua polkua varten. Toiminnassa vaikeat tilanteet syntyvät sen rinnalla. Mitä tapahtuu, jos käyttäjä jättää pakollisen kentän tyhjäksi, laukaisee saman kirjauksen kahdesti, tai menettää yhteyden tallennuksen aikana? Pysyykö tapahtuma johdonmukaisena? Saako henkilö ymmärrettävän viestin? Voiko hän jatkaa työskentelyä turvallisesti?

Windows-sovelluksissa myös käyttö ja tila ovat erityisen tärkeitä. Valintaikkunat voivat tulla näkyviin taustalla, pikanäppäimet voivat mennä päällekkäin, tiedostonvalintaikkunat voivat estää kulun. Tarkista, ovatko fokus, virheilmoitukset, ja lukitukset yksiselitteisiä. Tekninen poikkeus ilman toimintaohjetta ei auta vuoropäällikköä.

Käytä manuaalisia testejä siellä, missä tarvitaan arviointikykyä

Manuaaliset testit eivät ole merkki riittämättömästä kypsyydestä. Ne ovat välttämättömiä, kun syntyy uusi prosessi, käyttöliittymä rakennetaan uudelleen, tai asiantuntemus ratkaisee laadun. Kokenut varastopäällikkö huomaa nopeammin kuin skripti, onko näyttö ymmärrettävä kovan aikapaineen alla, tai tuleeko varoitus liian myöhään.

Manuaalisesta testauksesta tulee kuitenkin kallista ja epäluotettavaa, kun samoja vakaita prosesseja toistetaan ennen jokaista versiota. Silloin julkaisu riippuu käytettävissä olevista henkilöistä, muistista, ja hajanaisista muistiinpanoista. Oikea siirtymäkohta automaatioon on yleensä siellä, missä prosessia suoritetaan usein, se voi aiheuttaa suurta vahinkoa, ja sillä on selkeät odotetut tulokset.

Hyvä manuaalinen testitapaus kuvaa lähtötilanteen, vaiheet, odotetun tuloksen, ja tarvittavan datan. Lisää virheen yhteydessä kuvakaappaus, aikaleima, sovellus- ja build-versio, sekä tarkka toiminto. "Tulostus ei toimi" ei ole käyttökelpoinen virhekuvaus. "Toimitusosoitteen muuttamisen jälkeen tulostusvalintaikkuna jää auki, tilaus 4711 ei saa PDF:ää, eikä mitään ilmoitusta näy" on.

Automatisoidut regressiotestit toistuville riskeille

Automaatio ei tarkista, onko ohjelmisto perustavanlaatuisesti hyvä. Se tarkistaa, toimivatko aiemmin toimineet, määritellyt prosessit edelleen muutoksen jälkeen. Se on erityisen arvokasta Windows-ohjelmistolle, jonka käyttöliittymiä, tietokantalogiikkaa, ja ulkoisia rajapintoja kehitetään vuosien ajan.

Aloita pienestä. Valitse ensin viisi-kymmenen liiketoimintakriittistä prosessia, jotka tulisi tarkistaa jokaisen julkaisun yhteydessä. Näihin voivat kuulua kirjautuminen account-lockout-vuolla, tilausten syöttö, varastokirjaus, PDF- tai tarratulostus, roolinvaihto, ja keskitetty tuonti. Vasta kun nämä testit toimivat luotettavasti, laajentaminen erikoistapauksiin kannattaa.

Työpöytäsovelluksissa automatisoidut testit ohjaavat usein näkyviä käyttöliittymäelementtejä: ikkunoita, syöttökenttiä, taulukoita, painikkeita, ja valintaikkunoita. Se toimii, mutta on herkempi kuin puhdas rajapintatesti. Pienet ulkoasumuutokset, hitaammat tietokoneet, tai epäselvästi nimetyt elementit voivat rikkoa testejä. Siksi kehittäjien, liiketoiminta-alueen, ja testivastaavien tulisi yhdessä määrittää, mitkä elementit ovat vakaasti osoitettavissa ja mitkä tarkistusvaiheet on parempi varmistaa tietokannan, lokin, tai rajapinnan kautta.

Järkevä testi ei myöskään tarkista vain sitä, että painiketta pystyi klikkaamaan. Se valvoo asiallista seurausta: tallennettiinko kirjaus? Onko varasto oikein? Luotiinko asiakirja? Ei luotu kaksoiskappaletta? Näkyvä vuorovaikutus ja todennettava tulos kuuluvat yhteen.

Todisteet ovat osa testitulosta

Pelkkä vihreä tila riittää harvoin kriittisissä sovelluksissa. Kun testi epäonnistuu, tiimit tarvitsevat nopeasti vastauksen kolmeen kysymykseen: mikä oli lähtötilanne? Missä vaiheessa prosessi epäonnistui? Mitä sovellus näytti sillä hetkellä?

Kuvakaappaukset, suorituslokit, ja tarvittaessa näytön tallenteet tekevät virheistä keskusteltavia. Ne lyhentävät huomattavasti siirtoa toiminnan, QA:n, ja kehityksen välillä. Säänneltyille tai tietoturvatietoisille yrityksille ne ovat lisäksi vankka perusta hyväksyntöjen ja poikkeamien jäljittämiseen.

Tässä tallennuspaikka ei ole sivuseikka. Testiajot voivat sisältää sisäistä asiakasdataa, hinnastoja, tilaustietoja, tai näyttönäkymiä. Sen, joka testaa automatisoidusti arkaluontoisia Windows-sovelluksia, tulisi selvittää, saako tämä data poistua omasta infrastruktuurista. Itse isännöity ympäristö kuten COCO voi olla tässä järkevä, koska testien suoritus, todisteet, ja arviointi pysyvät oman hallinnan alla. Onko se tarpeen, riippuu tietosuojavaatimuksista, sopimustilanteesta, ja suojaustarpeesta - jokainen tiimi ei tarvitse samaa arkkitehtuuria siihen.

Rakenna testaus osaksi julkaisuprosessia

Paras testikatalogi menettää arvonsa, jos sitä käytetään vasta kiireisen tuotantoonviennin jälkeen. Määritä kiinteä ajankohta: automatisoidut ydinregressiot ajetaan ennen jokaista julkaisua, manuaalinen hyväksyntä tarkistaa uudet tai muuttuneet prosessit, ja tunnetut rajoitukset dokumentoidaan avoimesti.

Kaikkien epäonnistuneiden testien ei tarvitse pysäyttää julkaisua. Virhe harvoin käytetyssä hallintanäkymässä voi olla hyväksyttävä, jos turvallinen kiertotie on olemassa ja kyseinen alue on selkeästi tiedotettu. Virhettä, joka kirjaa varastot väärin tai lukitsee käyttäjät huomaamatta, on käsiteltävä eri tavalla. Tämä päätös tulisi tehdä liiketoimintavaikutuksen perusteella, ei pelkän punaisten testien määrän perusteella.

Ylläpidä testejä yhdessä sovelluksen kanssa. Kun prosessi muuttuu tietoisesti, päivitä testitapaus, testidata, ja odotettu tulos yhdessä vaatimuksen kanssa. Vanhentuneet testit aiheuttavat melua ja jäävät lopulta huomiotta. Muutama luotettava tarkistus on arvokkaampi kuin sadat automatisoidut prosessit, joiden tuloksia kukaan ei enää ota vakavasti.

Lopulta kyse ei ole jokaisen kuviteltavissa olevan syötteen simuloinnista. Kyse on työn suojaamisesta, jonka on toimittava taas seuraavana aamuna. Aloita yhdestä ainoasta kriittisestä prosessista, tee sen tulos todistettavaksi, ja rakenna siitä eteenpäin.