Robert Whitney
Tarkkojen ja oikeiden ohjelmistotestauksen toteuttaminen seuraa lukuisia periaatteita. Kansainvälinen ohjelmistotestaussertifiointilautakunta (ISTQB) erottelee seitsemän perustavanlaatuista periaatetta, joita aiomme tänään käsitellä. Kiinnostaako? Lue artikkeli keskeisistä ISTQB-testauksen periaatteista!
ISTQB-testauksen periaatteet – sisällysluettelo:
- Testaus paljastaa virheitä, mutta ei voi todistaa niiden puuttumista
- Kattava testaus on mahdotonta
- Aikainen testaus säästää aikaa ja rahaa
- Vikojen lumipalloefekti
- Torjunta-aineparadoksi
- Se riippuu kontekstista
- Virheettömän ohjelmiston mainostaminen on ei-toivottua
- Yhteenveto
Testaus paljastaa virheitä, mutta ei voi todistaa niiden puuttumista
Testaus lisää todennäköisyyttä löytää virheitä, mikä puolestaan helpottaa niiden korjaamista. Kuitenkin se ei voi täysin taata, että ohjelmisto on vapaa kaikista vioista, vaikka suurin osa niistä havaitaan ja korjataan. Virheettömän ohjelmiston luomisen mahdottomuuden vuoksi monet pitävät prosessia negatiivisena suunnitteluna, koska et koskaan saa positiivista tulosta ja löydät aina jotain “likaista” ohjelmista.
Kattava testaus on mahdotonta
Yllä oleva nyrkkisääntö toteaa, että kaikkien ohjelmiston vikojen havaitseminen on turhaa. Tämä ei kuitenkaan päde yksinkertaisiin lyhyisiin ohjelmiin. Tämä puolestaan tarkoittaa, että on mahdollisuus nähdä kaikki syötteiden ja ennakkoedellytysten yhdistelmät testatakseen joitakin ohjelmia täysin. Kun arvioidaan monimutkaista ohjelmistoa, edes paras tekoäly ei voi suorittaa kaikkia tarvittavia mittauksia, puhumattakaan manuaalisista testaajista. Automaattiset arvioijat käyvät sovellusten läpi tehokkaammin ja tarkemmin, mutta ne eivät silti voi taata virheetöntä suorituskykyä. Tätä varten sinun on ryhdyttävä lisätehtäviin, kuten priorisointiin, riskianalyysiin sekä muiden testausmenetelmien löytämiseen ja toteuttamiseen.
Aikainen testaus säästää aikaa ja rahaa
Monet ammattilaiset kutsuvat tätä periaatetta “siirtämiseksi vasemmalle.” Mitä aikaisemmin havaitset viat, sitä helpompi on korjata ne, joten staattisen ja dynaamisen testauksen tulisi alkaa mahdollisimman pian. Yhteenvetona:
- Staattinen testaus – tuotteen arvioiminen ilman koodin suorittamista.
- Dynaaminen testaus – moduulin tai järjestelmän koodin arviointi sen suorituskyvyn aikana
Vikojen havaitseminen toteutuksen ensimmäisissä vaiheissa helpottaa lisädiagnostiikkaa. Mutta kun kaksi ohjelmiston aluetta vuorovaikuttaa, vikojen korjaaminen muuttuu hankalaksi, koska on mahdotonta paikantaa se, jossa virhe on. Tällaisissa tapauksissa tarvitaan ylimääräistä aikaa, vaivannäköä ja työvoimaa. Kaiken kaikkiaan nopea reagointi esiin tuleviin esteisiin voi estää halkeamien lisääntymisen.
Vikojen lumipalloefekti
Useimmat viat taipuvat keskittymään kriittisimpiin moduleihin, joten niiden syvällinen tarkastelu paljastaa ja riittävästi eliminoi suurimman osan. Nämä ryhmät muodostavat pääpainon riskin analysoimiseksi, jotta voidaan kartoittaa ja määrittää tulevat toimenpiteet. Suurin osa vioista ilmenee seuraamalla käyttäjien kulkemia polkuja, mutta näissä tapauksissa pelkkä tieto ei tee moduuleista virheettömiä.
Pareto-periaate sanoo, että 80 % tuloksista johtuu vain 20 % syistä. Toisin sanoen, 80 % bugeista esiintyy 20 % moduuleissa. Jos kohtaat useita vikoja yhdessä moduulissa, jatka kaivamista, sillä ne ovat siellä.
Torjunta-aineparadoksi
Saman testin toistuva suorittaminen voi epäonnistua, koska ne on voitu suunnitella alun perin väärin eikä ne koskaan osoittaudu tehokkaiksi. Sinun on korjattava ja päivitettävä testaus lisätäksesi mahdollisuuksia löytää uusia vikoja ohjelmistosta.
Uuden diagnosointijärjestelmän luominen ei myöskään ratkaise ongelmaa. Aiemmista yhdistelmistä seuraaminen voi pysäyttää arviointiprosessin samalla tasolla. Tätä periaatetta kutsutaan ‘torjunta-aineparadoksi’, koska torjunta-aineet, jotka hallitsevat tuholaisia, menettävät myös tehokkuutensa tietyn käytön jälkeen.
Se riippuu kontekstista
Testauksen toteuttamistapa riippuu tutkittavista aiheista. Näin ollen kirjanpito-ohjelman, videopelin tai sosiaalisen verkostoitumisen sovelluksen testaaminen vaihtelee huomattavasti. Se riippuu myös tilanteesta, esimerkiksi analyysi, joka keskittyy sovelluksen käytännöllisyyteen, kuten sen houkuttelevuuteen käyttäjille, käytettävyyteen, visuaaliseen kerrokseen jne., eroaa myös ohjelman toiminnallisia ominaisuuksia arvioivista arvioinneista, esim. oikeiden laskelmien suorittamisesta.
Virheettömän ohjelmiston mainostaminen on ei-toivottua
Erilaisten diagnostiikkatyökalujen käyttö ei voi taata virheettömiä sovelluksia. Monet, jotka väittävät ja mainostavat sovelluksiaan sellaisina, ovat väärässä, mutta todennäköisesti se johtuu vain markkinointiponnisteluista, joilla he tekevät väitteen. Voit suorittaa useita manuaalisia ja automatisoituja testejä lisätäksesi todennäköisyyttä löytää ja korjata mahdollisimman monta virhettä, mutta silti ei ole takeita täydellisestä suorituskyvystä. Joissakin tapauksissa esteet liittyvät toimivaan ohjelmistoon, esim. ohjelma ei ehkä täytä kaikkia käyttäjien odotuksia.
ISTQB-testauksen periaatteet – yhteenveto
Tällä tavoin ISTQB, peruslähtökohdiltaan, esittelee seitsemän ISTQB-testauksen periaatetta, joita ohjelmistotestaajan tulisi noudattaa. Ensinnäkin ne osoittavat täydellisen ohjelmistodiagnoosin mahdottomuuden, joten on tärkeää, muiden asioiden ohella, muokata testejä sekä suorittaa perusteellinen haku keskeisissä moduuleissa. Nämä toimet parantavat suurimman osan vikojen etsintää ja poistamista, vähentäen tulevien vikojen todennäköisyyttä.
Mitä ohjelmistotestaus on? Nyt tiedät vastauksen! Tutustu myös muihin sarjoihimme Pythonista ja Javascriptista!
Jos pidät sisällöstämme, liity vilkkaaseen mehiläisyhteisöömme Facebookissa, Twitterissä, LinkedInissä, Instagramissa, YouTubessa, Pinterestissä.
Robert Whitney
JavaScript-asiantuntija ja opettaja, joka valmentaa IT-osastoja. Hänen päämääränsä on nostaa tiimin tuottavuutta opettamalla muille, kuinka tehdä tehokasta yhteistyötä koodauksen aikana.
