Testaussuunnitelma

"...mutta se oli semmoista teoriapaskaa..."

Näin ajattelee valitettavan moni softan tekijä. Myydään se asiakkaalle niin kyllä se sitten kertoo mikä siinä on vialla.

Testaus on kuitenkin ehkä tärkein osa sovelluskehitystä. Kehitys on nimenomaan prosessi jossa testauksen tulee olla olennainen osa ja siten että on alusta lähtien mukana eikä niin että tehdään ensin valmis kokonaisuus joka testaan lopuksi.

Virheen hinta kasvaa huimasti sitä mukaa mitä myöhemmin se löydetään. Ylivoimaisesti kallein virhe on se jonka löytää asiakas.


Nämä ajatukset ja paljon muuta löytyy vaikka tuolta:

http://www.cc.jyu.fi/~akrats/harkat/ohjtuo/Ohjelmiston_testaus.htm#_Toc530809326

Mulla on yksi testaussuunnitelmapohja, mutta en voi pistää sitä jakoon koska opettaja antoi sen sillä ehdolla ettei jaeta julkisesti.

Auttaisko asiaa jos vaikka kirjoittaisit googleen Master Test Plan?

Meillä oli hyvä testauskurssi, tehtiin hommia käytännössä eli vedettiin testauksen vaiheet kokonaisuudessaan lävitse, tarkastettiin määritysdokumentaatio, testattiin sovellus jne.. tehtiin näistä omat testauksen dokumentaatiot jne...

Meillä oli tosi hyvä testauksen kurssi.

Lopuksi vielä kävimme lävitse erilaisia testausvälineitä.

Laitan tässä jakoon testaukseen liittyviä linkkejä jos vaikka joku näistä jeesaa.

En ole käynyt linkkejä itse lävitse.

http://www.testingeducation.org/

http://groups.yahoo.com/group/fi-testaus/

http://www.kaner.com/

http://www.pettichord.com/

http://www.aptest.com/resources.html

http://www.testauskirja.com/

http://www.stickyminds.com/

http://www.sei.cmu.edu/str/descriptions/

http://www.cetus-links.org/oo_testing.html

Ehkä tämä vastaus tulee vähän myöhässä, ehkä jollain toisella on hyötyä siitä?

Ymmärrän hyvin kiusantuneisuutesi, puhtaasti käytännön ongelmasta yritetään pakolla vääntää jotain teoreettista puppua. Olen kyllä tutustunut erilaisiin teoreettisiin testaussuunnitelmiin ja todennut että niiden hyöty ohjelmoinnissa ovat lähinnä marginaalisia.

Ohjelman testaus alkaa samanaikaisesti kuin itse ohjelmointi, eikä nämä kaksi vaihetta mielestäni voi erottaa toisistaan. Ohjelmointitapa määrää myös osittain testausstrategian.

Testaus? Mitä halutaan testata? Näkemykseni mukaan pääasiassa kaksi asiaa: 1) ohjelma toimii laskennallisesti oikein(Aikalisä: "mää teen peliohjelmaa, ei siinä mitään laskemista tarvita". Paitsi projisointia, renderointia etc. 2) se ei kaadu (3. se on riittävän nopea 4. käyttää muistia maltillisesti ym. nämä ovat kuitenkin ns. bench mark ongelmia).

Kohta 1. Toimivuus: Käytä ohjelmaa ja rekisteröi tarkasti mahd. ongelmat silloin kun ne ilmenevät (ja myös ongelmaa edeltävät toimeenpiteet). Yritä luoda toistettavissa oleva virhetilanne. Ainoa keino mitä tiedän on ohjelman käyttö käytännössä, ehkä se vaimon avuksianto ei ole niin hassua? (Tai, istahda näppäimistön päälle, pistä soimaan Jail House Rock, pysy rytmissä ja jos ohjelma yhä pystyssä, hyvä merkki!)

Kohta 2. Kaatuminen: 95 % johtuu seuraavista syistä: a) allokoidaan muistia, unohdetaan vapauttaa b) unohdetaan päivittää pointereiden sisältöä c) indeksoitujen taulukoiden indeksointivirheitä (usein indeksin yläpäässä, lipsahti "yksi yli") d) pakotettu cast-operaatio (kääntäjä herjaa mutta saa "toimimaan" laittomalla ( ja virheellisellä) tyypinmuutoksella). Nämä ovat standardivirheitä, ne puuttuvat 5% ovat todella v-mäisiä, kysy B. Gates ;)

Miten vältytään (tai rajoitetaan ongelmaa niin että se on löydettävissä ja korjattavissa; Tämä kai on koko testauksen tarkoitus?):

(Ei yritetty esittää) tärkeysjärjestyksessä (subjektiivinen mielipide):
- Kommentoi ohjelmakoodia (älä ajattele että olen niin terävä että en tarvitse kirjoittaa kommentteja, muut ihailevat minun nerouttani. Älä käytä slangia kommenteissasi, yritä olla ammattimaisen tarkka ja asiallinen, yllätä kaikkia veitsenterävällä logiikallasi ja asiallisuudella!).
- Käytä exceptions (pahoillani, äidinkieleni ei ole tästä maasta, oikea sana olisiko "prosessorivirhepoikkeus-hyppy"?). Mitä tarkoitan, käytä TRY-CATCH-rakennetta aina kun se lainkaan on mahdollista. Virhe ei näy käyttäjälle silloin kun se tapahtuu, tyyppillisesti vasta paljon myöhemmin!
- Jos kääntäjä herjaa jostain virheestä, älä yritä kiertää sitä "poppaskonsteilla " ymmärtämättä mikä on pielessä (esim. cast-operaattorit ovat vaarallisia tässä suhteessa). Ne kaverit jotka kirjoittavat kääntäjiä, ymmärtävät todennäköisesti (toivottavasti) paljon enemmän näistä ongelmista kuin sinä!
- Opi käyttämään Debuggeria vähintään yhtä hyvin kuin käyttämäsi kääntäjää/linkeriä! Voit tietysti rakentaa "testipenkkejä" selvitäkseen ongelmia, debuggerin käyttö on nopeampaa ja tarkempaa.
- Kaikkien kääntäjien mukana tulee useita testausohjelmia (muistivuotoja, profilers(minne laskenta-ajat menevät) jne. Opi käyttämään (ja tulkitsemaan tuloksia!).
- Yritä ehkäisemään virheitäisi! Teet todennäköisesti virheen joka viides koodirivi. Lue taaksepäin neljä riviä, yritä löytää se. Mieti missä se voisi olla. Jos 20 ihmistä jälkikäteen yrittävät löytää sitä vuoden aikana, tuote myöhästyy, kaiki tietävät kuka syyllinen oli kun se löytyy, et ole kovin suosittu kun asia on selvitetty (ref. Windows 95, eikä asiat ovat niistä ajoista parantuneet!)

Eli yhteenvetona: Vältä tekemästä virheitä mutta jos niitä kuitenkin sattuu, varmista että löydät niitä nopeasti!

Lopuksi: Kirjoitin tämän (n. neljän milj. kaupallisen kielirivin kokemuksella) jotta emme kaikki tarvitsisi tehdä näitä virheitä uudestaan. Jos jollakin on täsmennyksiä asiaan (ei tämä ole mikään täydellinen juttu, siitä voisi kirjoittaa kirjoija) ne ovat tervetulleita, mutta, edes tämän kerran, pysykää asiallisella linjalla. Täällä pyörii niin paljon ihmisiä jotka(metafora):' Äskettäin ovat saanneet ajokortin ja kuvittelevat että ne tämän perusteella osaavat suunnitella ja rakentaa auton'.

PS. Tekstiä riittäisi vielä, alkaa kuitenkin TV:ssä "Tanssiopettajan paluu". Olen lukennut Henning Mankellin deckarin, en muista miten se päättyy, ja haluasin verrata kirjaa filmiin ;)