SISÄLLYSLUETTELO
1. JOHDANTO
1.1 Tarkoitus ja kattavuus
1.2 Tuote ja ympäristö
1.3 Määritelmät, termit ja lyhenteet
1.4 Viitteet
2. YMPÄRISTÖVAATIMUKSET
2.1 Laitteisto (hw)
2.2 Ohjelmisto (sw)
2.3 Turvallisuus
2.4 Apuvälineet (työkalut)
3. HENKILÖSTÖ- JA KOULUTUSVAATIMUKSET
3.1 Henkilöstö
3.2 Koulutus
4. VASTUUALUEET
4.1 Integrointitestausryhmä
4.2 Järjestelmätestausryhmä
4.3 Sovellusalueen testausryhmä
4.4 Kehitysprojektin testausryhmä
5. VAADITTTAVA TULOSAINEISTO
6. TESTATTAVAT TOIMINNOT
6.1 Moduulit
6.2 Ohjelmaan liittyvät toiset ohjelmat
6.3 Käyttäjän toiminnot
6.4 Operaattorin toiminnot
7. ERIKOISOMINAISUUKSIA
7.1 Ominaisuudet joita ei testata
7.2 Ominaisuudet jotka testataan
8. TESTAUKSEN TEHTÄVÄJÄRJESTYS
9. TESTAUSMENETTELY JA TESTAUSTAPAUKSET
9.1 Testitapausluokat
9.2 Menetelmät ja tekniikat
9.3 Kattavuus
9.4 Rajoitukset
9.5 Tietokannan testaus
9.6 Ohjelmaan liittyvien osien testaus
9.7 Käyttöliittymän testaus
9.8 Liittymien testaus
9.9 Tulostustoimintojen testaus
9.10 Turvallisuuden testaus
9.11 Toipumisen (elpymisen) testaus
9.12 Suorituskyvyn testaus
9.13 Regressiotestaus
10. TESTIN HYVÄKSYMIS- JA HYLKÄÄMISKRITEERIT
10.1 Hyväksymiskriteerit
10.2 Hylkäämiskriteerit
10.3 Vaatimukset testauksen keskeyttämiselle
10.4 Vaatimukset testauksen jatkamiselle
10.5 Vaatimukset testauksen lopettamiselle
11. RISKIEN HALLINTA
12. AIKATAULU
13. HYVÄKSYJÄT
13.1 Testit ja testitapaukset
13.2 Koko testaus
Tämän dokumentin tarkoitus. Onko kyseessä moduuli-, integrointi-, vai kenties järjestelmätestaus.
Yhteenveto testattavista ohjelmiston osista ja ominaisuuksista. (Koko ohjelman kaikkia valintoja ja ominaisuuksiahan on usein mahdoton testata.)
Tai että esimerkiksi testataan määrittelyn [VIITE siihen] kohdan 4.2 toiminnot eikä muuta (perustelut, esimerkiksi: muilta osin tämä ohjelmaversio on sama kuin edellinen testattu, eikä regressiotestausta tarvita firman laatuohjeen L-97-01A mukaan).
Tämän dokumentin tarkoitus.
Tuotteen identifiointi, esimerkiksi nimi, tuotenumero, versio, liittymät muihin tuotteisiin, onko jonkin tuoteperheen jäsen.
Hyvin lyhyesti ko. testauksen kohteen esittely.
Myös projektin kulkua voidaan kuvailla lyhyesti, esimerkiksi miten juuri tämä osuus liittyy koko projektin testaukseen
Sellaiset määritelmät, termit ja lyhenteet, joiden ei voida olettaa olevan lukijalle tuttuja, tai joiden suhteen voi syntyä väärinymmärrystä ilman tätä selostusta.
Esim. projektin aiemmat dokumentit; projektisuunnitelma, laadunvarmistussuunnitelma, tuotteenhallintasuunnitelma ja näihin liittyvät standardit tai suositukset (mm. laatukäsikirjan kohdat). Myös mahdolliset firman omat testausohjeet voidaan mainita tässä.
Testausympäristölle asetettavat vaatimukset kuvataan tässä, tarkasti ja täsmällisesti.
Etenkin jos tarvitaan useita arkkitehtuuri/ käyttöjärjestelmäympäristöjä.
(Usein toimivuus testataan ensin "nopealla" koneella ja sen jälkeen suorituskyky minimivaatimusten mukaisella laitteistolla.)
Testausympäristön minimi- ja tavoiteltava kokoonpano. Nämä voidaan haluttaessa jakaa omiksi alakohdikseenkin, esimerkiksi 2.1.1 ja 2.1.2.
Esimerkiksi vaadittava kiintolevytila
Vaaditaanko useampia erilaisia kokoonpanoja. Mikäli, niin ne olisi selkeintä luetella omissa alakohdissaan.
Testausympäristön minimi- ja tavoiteltava kokoonpano.
Esimerkiksi käyttöjärjestelmä, ikkunointiympäristö (ikkunointijärjestelmä) ja varusohjelmat (jos tarvitaan) tarkasti.
Vaaditaanko useampia erilaisia kokoonpanoja. Mikäli, niin ne olisi selkeintä luetella omissa alakohdissaan.
Esimerkiksi
2.2.1 Windows 3.x
2.2.2 Windows 95
2.2.3 Windows NT4
2.2.4 Windows 98
Tarvitaanko erityistä testauskäyttäjätunnusta ja -salasanaa.
Myös tietoliikenneominaisuudet. Ohjelman tila (esimerkiksi monenkäyttäjän tai yhden käyttäjän tila).
Esimerkiksi testaus ei saa aiheuttaa liiallisia turvallisuusriskejä omalle firmalle tai asiakkaalle. Eikä häiriötä muille käyttäjille (kuormitus, muisti loppu, hakemistot sekaisin, levyjen temp-tila täynnä, kaikki työasemat käytössä,...).
Esimerkiksi järjestelmää testattaessa se irroitetaan
firman lähiverkosta tai jos verkkotoimintoja tarvitaan niin irroitetaan
testauksen kohde firman ulkopuolisesta verkkomaailmasta. Tai testaus tulee tehdä
viikonloppuna klo 22-06 välisenä aikana.
Onko syytä ottaa täysi/osittainen varmuuskopio firman (oma tai asiakas) levystä ennen testauksen aloittamista ?
Tarvitaanko oma testaushakemisto; tarkat tiedot kohtaan 7.1.
Varusohjelmisto ja muut tarvittavat ohjelmakomponentit, myös tarvittava syöteaineisto (esimerkiksi mallidatatiedostot, testausaineisto) ja laitteisto.
Itse tehdyt testipenkit (testipetit) ja vastaavat apupalikat mainitaan tässä tiedostonimen, päivämäärän ja sijainnin tarkkuudella.
Testauksessa mahdollisesti käytettävät ohjelmistoapuvälineet, esimerkiki testikattavuustyökalut, testipetigeneraattorit, tulosten tilastointiohjelmat, kompleksisuusmittarit. Esimerkiksi testigeneraattori XY versio Z. Onko käyttöliittymän testaukseen apuvälineitä (eräs tärkeä osa-alue) ?
TTKK:n Lintulassa olevia testausapuvälineitä ovat mm. gct ja ctc-tuoteperhe (tuttuja OTM-kurssilta). Lisää ja tarkempaa asiaa testauksesta saa testauskurssilla 81950 (entinen Työkurssi).
Tarvitaanko asiantuntija-apua johonkin testauksen vaiheeseen ? Tai asiakkaan edustajia koekaniineiksi?
Vaatiiko asiakas päästä seuraamaan testausta ? Vaatiiko asiakas jonkinlaista testaus-koulutusta?
Kurssi 81820 Käyttöliittymät täytyy ehkä olla käytynä?
Testaushenkilöstön tarve tämän testaussuunnitelman mukaisiin tehtäviin. Esimerkiksi kaksi testaajaa sekä testauspäällikkö.
Laajoissa sovelluksissa voidaan resurssitarve luetella osittainkin (testausalueittain).
Esimerkiksi luottamuksellisissa projekteissa testaajilta vaaditaan kansallinen turvaluokitus A2 (minkä asian tutkii Suojelupoliisi).
Vaadittava koulutus tämän testaussuunnitelman mukaisiin tehtäviin määritellään.
Esimerkiksi vaaditaan kokemusta sulautettujen tietoliikenneohjelmien (ZYX-prosessoriperhe) testauksesta.
Henkilöt ja ryhmät joiden vastuulla ovat testauksen osat: valmistelu, suunnittelu, johto, suoritus, varmentaminen eli todistaminen, tarkastus ja virheiden selvittäminen.
Näissä ryhmissä voivat olla edustettuina mm. suunnittelijat, käyttäjien edustajat, operaattorit/ylläpitäjät, teknisen tuen henkilöt, tiedonhallinnan edustajat sekä laadunvarmistuksen edustajat.
Mikäli kyseessä on pieni testausprojekti, voidaan moduulitestauksesta mainita tässä kootusti yleiset asiat. Tai jopa tehdä siitä oma kohtansa; eniten kiinnostava asia on testaushenkilöstö.
Kuka/ketkä testaavat; osien tekijät ja/tai toiset ryhmän jäsenet?
Kuka/ketkä testaavat; osien tekijät ja/tai toiset ryhmän jäsenet?
Mikäli tarvitaan. Esimerkiksi käyttöliittymä olisi hyvä testata tulevilla käyttäjillä.
Käytettävyys ei ole välttämättä sama asia kuin toimivuus.
Mikäli tarvitaan.
Testauksen tuloksena saatavat konkreettiset todenteet; dokumentit ja/tai raportit sekä mahdolliset tiedostot (regressiotestausta varten, ellei mainittu ao. kohdassa testitapausten yhteydessä). Nimet ja sijainti.
Esimerkiksi testausraportti, testiloki, testitapausten määrittelyt, tulosteet, palautelistaukset. Tarvittaessa selostetaan testitulosten nimeäminen.
(Kohdassa 2.4 mainitaan apuvälineet, mm. malliaineisto.)
Testattavat ohjelman osat versio/revisiotasolla, päivämäärineen. Eli luettelo moduuleista/pakkauksista, jotka ovat testattavina.
Jälkeenpäin voidaan katsoa, mikä versio mistäkin moduulista osallistui tähän testaukseen.
Mikäli on tarpeen määritellä testaukselle rajaus se mainitaan tässä. Useamman ohjelman osan testaus ilman päällekkäisyyttä saattaa vaatia yleisemmän tason testauksen jakosuunnitelmaa (tai se voidaan kuvata tämän dokumentin kohdassa 2.3).
Mitä kaikkia toimintoja testataan (määrittelyn näkökulmasta). Esimerkiksi kaikki käyttäjälle mahdolliset (määrittelydokumentti XYZ, versio a.b, pvm) toiminnot. Eli tämä dokumentti kattaa kaikkien käyttäjän toimintojen testauksen.
Onko tarpeen otta kantaa; yksi käyttäjä - moniajo - monta käyttäjää.
Mikäli nämä selostetaan omissa dokumenteissaan, mainitaan viite
niihin.
Mitä kaikkia toimintoja testataan (määrittelyn näkökulmasta).
Mikäli nämä selostetaan omissa dokumenteissaan, mainitaan viite niihin. Tai mikäli järjestelmässä ei tarvita erillistä ylläpitäjää, ei tätä osuutta tarvita.
Kaikki ohjelman osat ja toiminnot joita ei testata luetellaan. Rajaus laajoissa ohjelmissa on välttämätöntä. Perustelut tässä kohtaa ovat tärkeitä.
Ei-testattavia osia voivat olla esimerkiksi sellaiset tässä vaiheessa mukana olevat moduulit, joita lopulliseen toimitukseen ei sisällytetä. Tai sellaiset uudelleenkäytetyt vakiokomponentit tai kirjasto-osat, joita ei ole muokattu.
...tarpeen mukaan tarkasti alakohdittain...
Tässä luetellaan yleiset kokonaisuudet, tarkemmat kuvaukset löytyvät 9. luvusta. Esimerkiksi testiryhmittäin. Yksi testausryhmä voi sisältää useita testejä tai testitapauksia.
Kaikki ohjelman osat ja toiminnot jotka testataan luetellaan. Rajaus laajoissa ohjelmissa on välttämätöntä. Perusteluineen.
Toiminnalliset vaatimukset sekä muut vaatimukset (ja lisäksi mitä ohjelma EI saa tehdä).
Mikäli painotutaan jollekin erityiselle sovelluksen osa-alueelle, tulisi se mainita tässä. Esimerkiksi nopeus, grafiikka.
...tarpeen mukaan tarkasti alakohdittain...
Mikäli noista osista on omat dokumenttinsa, mainitaan ne tässä ja tämän luvun sisältä rajoittuukin siihen.
(Eräs täsmällinen tapa olisi numeroida määrittelydokumentissa kaikki toiminnot sekä muut testauksen kohteet. Sitten testaussuunnitelmassa olisi samat numerot ja vain testitapauksen nimi. Testausraportissa olisi testin numero ja lopputulos.)
Mitä valmistelevia toimenpiteitä tarvitaan ennen varsinaista testausta, sekä itse testauksen tehtäväluettelo. Myös tehtävien keskinäiset riippuvuudet ja mahdolliset tarvittavat erikoistiedot ja -taidot.
Esimerkiksi osat A ja B on testattava ennen osaa C, ja moduulit D..G on testattava järjestyksessä D F G E.
Mitä osia voidaan testata yhtaikaa (rinnakkain) ? Taka-ajatuksena on kysymys montako testaajaa saadaan yhtäaikaa töihin (jolloin testauksen kokonaisaika lyhenee)?
Päätoiminnot mainitaan. Apuvälineet selostetaan tarkasti kohdassa 2.4. Toimintojen osalta pyritään sellaiseen tarkkuuteen jonka perusteella voidaan esittää testaukselle aika-arvio (työaika).
Testaustapaukset kuvataan yksityiskohtaisesti (eli yksilöidään) tämän luvun alakohdissa. Testaustapaukset kannattaa numeroida yksikäsitteisesti mm. testausraportin tekoa helpottamaan.
Testitapausten numeroinnissa/merkinnässä huomio mahdollisuus lisätä testitapauksia jälkeenpäin keskelle luetteloa. Esimerkiksi kun testauksen aikana keksitään uusia testejä. Yksinkertaisinta on lisätä testitapauksen numeron/merkinnän loppuun numero tai kirjain, eroteltuna esimerkiksi pisteellä tai tavuviivalla.
Testitapaukset voidaan luokitella tärkeysryhmiin. Esimerkiksi tärkeysluokat 1, 2 ja 3 tai vakavuusluokat A, B, C, D ja E. Tai ihan mitä tunnisteita tahansa halutaan käyttää.
Virheluokitus voidaan tehdä; vakavuustaso määritellään. Esimerkiksi virheluokat vakava, keskimääräinen ja lievä/pieni sekä kenties kosmeettinen. Tai virheluokat 1, 2 ja 3 (projekti sopikoon keskenään onko vakavin luokka 1 vai 3).
Mitä testejä täytyy testata uudelleen korjausten jälkeen, mille tapauksille riittää pelkkä korjaus?
Mahdolliset testauksen erityiset tekniikat tai menetelmät.
Esimerkiksi käytössä on oma erityinen testaushakemisto (kaikkinaisen sekoilun ehkäisemiseksi).
Missä kohtaa ohjelmistoprosessia kooditarkastuksia/koodi-katselmointeja pidetään? Ne ovat eräs tärkeä osa testausta, ja yleensä ne pidetään ennen integrointi- tai järjestelmätestausta.
Mikäli testauksen tuloksen on virheellinen toiminta, montako kertaa ko. testitapaus täytyy toistaa ? Miksi ?
Mikäli uutta sovellusta voidaan verrata (asiakkaan) aikaisempiin vastaaviin järjestelmiin, löytyy siitä hyvä mittauspohja toiminnallisuuden testaukselle. Esimerkiksi uuden suhde vanhaan; nopeus, tulosten oikeellisuus, käyttöliittymä, koko.
Miten määritellään testauksen riittävyys, minimi ja lisävaatimukset.
Esimerkiksi jokainen toiminto testataan vähintään kerran. Toistokertoja voidaan määrätä testitapausten tärkeys- ja/tai vakavuusluokittelun mukaan. Esimerkiksi A-luokan testit toistetaan 10 kertaa, B-luokan 5 kertaa ja muut yhden kerran.
Esimerkiksi muistinhallinnan testauksessa kannattaa testejä toistaa useita kertoja (etenkin sellaisia jotka käsittelevät dynaamisia tietorakenteita), niin nähdään toimiiko mm. roskien keruu.
Koodikattavuudesta (mittaus jollakin testausvälineellä) voidaan mainita tässä mikäli sellaista tavoitellaan. Muista kuitenkin että suuri kattavuus ei takaa ohjelman oikeaa toiminnallisuutta.
Raja-arvojen testaukseen kannattaa kiinnittää huomiota.
Esimerkiksi milloin ohjelma on testattavissa, testauslaitteiston ja -hen-kilöstön saatavuus ja aikatakarajat.
Esimerkiksi testaus vain iltaisin ja viikonloppuisin, aikaisintaan viikolla 4 mutta viimeistään viikolla 6.
...tarpeen mukaan lisäillen tai poistellen...
Esimerkiksi tyhjän syötteen aiheuttamat toiminnot, luku ja kirjoitus, haut, nopeus.
Muut ulkopuoliset osat, eli ei saman projektin tuotteet.
Käyttöliittymän testauksessa voi olla monta näkökulmaa; esimerkiksi toiminnallisuus/ergonomisuus/selkeys/käytön helppous.
Muista testata myös "määrittelemättömät" näppäimet eli esimerkiksi funktionäppäimet sekä kaikenlaiset "tutut" Shift-,Control-, Alt-yhdistelmät. Toimiiko erillinen numeronäppäimistö vai ei pitäisikö sen toimia vai ei?
Miten näppäimistö ja hiiri toimivat yhdessä ja erikseen.
Syötteiden oikeellisuuden tarkistus on iso apu ohjelman kaatumisen ehkäisyssä.
Rajapinnat mahdollisiin muihin ohjelmiin tai toimilaitteisiin.
Esimerkiksi eri sivukokojen tuki, eri kirjasinmallien tuki, ohjelman käyttäytyminen kirjoittimen virhetilanteissa, tiedostoon tulostaminen, pitkän ja/tai leveän tulosteen muodostuminen.
Esimerkiksi käyttäjätunnukset, tiedostojen ja hakemistojen suojaukset, verkkoyhteydet, www-selainten back-toiminnot.
Esimerkiksi verkkoyhteys poikki, kone kaatuu, sähkökatko, levyn
tmp-tila täyttyy.
Esimerkiksi vasteajat, kuormitus, datan koko, muistin riittävyys. Muistinhallinta voi olla tässä kohdassa.
Esimerkiksi yksittäinen kone vaiko verkon yli tapahtuva liikennöinti tietokantaan. Tuosta saadaan mittauspohja vertailulle. Montako testikertaa verkon yli tulee tehdä, jotta saadaan tilastollisesti merkittävä tulos?
Testaus muutosten/päivitysten jälkeen. Kun systeemiin tehdään muutos, ei riitä että muutos testataan, täytyy testata ettei muutos aiheuttanut sivuvaikutuksia (vakiotesti, josta on olemassa vakiosyötteet ja -tulokset).
Määritetään rajat joiden perusteella todetaan testauksen kohteen joko läpäisseen testin tai reputtaneen tässä testauksessa.
Kriteerit ja vaatimukset osalle testausta tai koko testille.
Mainitaan kuka päättää testituloksen tai testauksen osakokonaisuuden arvioimisesta (hyv/hyl).
Kriteerien ja vaatimusten tekniset vaatimukset ?
Onko testi hyväksytty, jos testitapaukset 1-200 ovat antaneet hyväksyttävän tuloksen mutta testitapaukset 201-235 eivät ole menneet läpi? Onko testitapauksia luokiteltu "tärkeysjärjestykseen"?
Tai onko testi hyväksytty aina kun kaikki 1. tärkeys/vakavuus-luokan testit ovat menneet läpi ?
Yksittäinen testitapaus tai jopa koko testaus voidaan joutua hylkäämään mikäli sitä ei voida saattaa päätökseen jonkin syyn (esimerkiksi havaitaan testitapauksen olevan väärin tehty tai vaadittavaa laitteistoa ei ole saatavilla) takia.
Testaus voidaan keskeyttää (tilapäisesti) kun huomataan jokin isompi virhe joka aiheuttaa välittömiä muutospaineita.
(Tämä ei ole sama kuin lopettaminen.)
Esimerkiksi jollei jotakin tärkeää tai keskeistä osaa saada testattua, ei siihen liittyviä muitakaan osia ehkä voida testata (tietty testausjärjestys).
Kun testausta taas jatketaan, täytyy tietään tarvitseeko joitakin aiempia testejä toistaa (liittyy regressiotestaukseen).
Myös mitä aiemmin tehtyjä testejä tulee toistaa testauksen jatkamisen jälkeen. Samoin kuka päättää testauksen keskeyttämisestä tai jatkamisesta.
Mikäli on käytetty testitapausten luokittelua, voidaan kenties todeta esimerkiksi että kyseisen testiluokan A- ja B-luokan testit täytyy toistaa, muttei alempien luokkien testejä tarvitse toistaa.
Tämä ei välttämättä ole sama asia kuin testin hyväksyminen.
Milloin testaus(vaihe) voidaan katsoa kokonaan suoritetuksi eli testaus voidaan lopettaa ? Esimerkiksi; toiminnot 1..567 on testattu hyväksytysti, tai toiminto X on läpäissyt 42 kertaa testin Y.
Tämä seikka on tärkeätä määritellä tarkasti, ettei sitten testauksessa tule ongelmia.
Testaus voidaan painavista syistä kertakaikkiaan lopettaa kesken. Esimerkiksi laitteisto ei vastaa vaadittua, ohjelmisto ei ole valmistunut, on testattu 180 tuntia ja rahat ovat loppu.
Määritä suurimmat riskitekijät testauksen kannalta ja selvitä niille varasuunnitelma. Yleisesti riskejä voivat aiheuttaa henkilöstö, laitteisto, asiakas, alihankkija tai muut osapuolet, testausympäristö, testitapausten oikeellisuus ja sopivuus.
Esimerkiksi aikataulun lipsuessa projektista riippumattomista syistä (esimerkiksi alihankkijan toimitusvaikeudet) varaudutaan lisäämään ylitöitä testauksen loppuvaiheessa.
Esimerkiksi jos henkilöstöä puuttuu testaushetkellä, mistä hankitaan tarvittavat henkilöresurssit ja kuka vastaa hankinnasta. Tarvitaanko varalaitteistoa?
Testauksen haitat (pahin mahdollinen tapaus) projektille ja muille (asiakas, muu toteuttajafirman toiminta)?
Testausympäristön hajoaminen? Ohjelma ei valmistu ajoissa
testaukseen, vaikutuksen projektiin?
Testauksen etapit eli tarkistuspisteet määritellään tässä. Ne voivat olla mainittuina myös projektisuunnitelmassa (silloin viittaus tuonne). Luettelo voi olla esimerkiksi toiminnoittain tai testauksen aikajärjestyksessä.
Jokainen testauksen vaihe määritellään kestoltaan. Näistä saadaan testauksen työmääräarvio ja työaika-arvio.
Aikatauluun vaikuttavat myös testausympäristön pystytys, testauksen raportointi ja uusintatestaukset.
Pessimistinen arvio on puolet ajasta testataan ja puolet kuluu löytyneiden virheiden korjaamiseen. Projektisuunnitelmassa on karkea aika-arvio testaukselle, mutta tässä esitetään se tarkka arvio (on mahdollista, koska testitapaukset on nyt kirjattu).
Esimerkiksi sovellus joka rakennetaan toimimaan kahdessa eri selaimessa ja kolmessa eri käyttöjärjestelmässä, vaatii kuusi erillistä testiryhmää. Mikäli kummastakin selaimesta testataan kahta eri versiota, testiryhmiä kertyy 12. Mikäli yhden testiryhmän eli ympäristökokoonpanon testaukseen lasketaan kuluvan 30 tuntia, niin...
Testauksen hyväksyjät määritellään nimen ja
virkanimikkeen (vakanssin) tarkkuudella. Laatukäsikirja vaatinee ko. henkilöiden
allekirjoitukset. Esimerkiksi testauspäällikkö, projektipäällikkö ja
laadunvarmistuspäällikkö, kaikkien allekirjoitukset päivämäärineen.
LIITTEET
Esimerkiksi järjestelmän tapahtumalista.