Synapsi: Automaattinen ohjelmiston etäpäivitys
NetSeal Technologies
Tietojenkäsittelyn ohjelmatyö Tik-76.115
| Versio | Editoija | Päiväys | Kommentti |
| 0.1 | Antti Vainio | 26.10.2000 | Kohdat 1 ja 3 alustavasti tehty |
| 0.2 | Mika Mäntylä | 28.10.2000 | Kohdat 2 ja 4 alustavasti tehty |
| 0.3 | Cemo Timucin | 31.10.2000 | Kohdat 5, 10 ja 11 alustavasti tehty |
| 0.4 | Cemo Timucin | 06.11.2000 | Kohdat 6, 7, 8, 13 alustavasti tehty + päivityksiä |
| 1.0 | Juho Anttila | 07.11.2000 | Korjattu linkitys, palautettava versio |
| 1.1 | Cemo Timucin | 10.12.2000 | Kohdat 1.3, 2, 6.1, 8 ja 9 päivitetty |
| 1.2 | Cemo Timucin | 11.12.2000 | Kohta 9.2 päivitetty |
| 2.0 | Juho Anttila, Mika Mäntylä | 11.12.2000 | Katselmoitu ja hyväksytty |
2.1 |
Cemo Timucin |
12.02.2001 |
Kohta 5 päivitetty |
| 3.0 | Mika Mäntylä, Juho Anttila | 12.02.2001 | Katselmoitu ja hyväksytty. |
| 3.1 | Cemo Timucin | 16.3.2001 | 1.4 poistettu, 7.2 päivitetty |
| 3.2 | Cemo Timucin | 18.3.2001 | 7.2 päivitetty |
| 4.0 | Juho Anttila, Mika Mäntylä | 19.3.2001 | Katselmoitu ja hyväksytty |
| 5.0 | Juho Anttila, Mika Mäntylä | 23.4.2001 | Tarkistettu ja hyväksytty lopulliseksi versioksi |
SISÄLLYSLUETTELO
0. Versiohistoria
1. JOHDANTO
1.1 Tarkoitus ja kattavuus
1.2 Tuote ja ympäristö
1.3 Määritelmät, termit ja lyhenteet
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
LAINAUKSET
LIITTEET
Tässä dokumentissa on kuvattu Synapsi-ryhmän valmistaman ohjelmatuotteen testaukseen liittyvät käytännöt ja menetelmät. Dokumentissa määriteltyä testauskäytäntöä tullaan soveltamaan eri tasoilla: testauksen kohteena ovat niin yksittäiset ohjelmamoduulit kuin koko järjestelmänkin testaus.
Ohjelmiston testaus koostuu mm. ohjelmamoduulien testauksesta, client-osan ja server-osan testauksista, näiden yhteensopivuuden testauksesta sekä koko rakennettavan ohjelmisto-osan yhteensopivuus asiakkaan nykyisen järjestelmän kanssa. Tarkempi testien määrittely löytyy seuraavista kappaleista.
Dokumentissa käsiteltävä ohjelmistotuote on automatisoituun ohjelmiston etäpäivitykseen tarkoitettu ohjelmisto. Ohjelmistosta ei ole olemassa aiempaa versiota ja näin ollen projektin aikana siitä tullaan valmistamaan versio numero 1. Tuotteella ei ole varsinaista nimeä ja se tullaan integroimaan osaksi projektin asiakkaan RoamMate-ohjelmistoa. Työnimenä tullaan käyttämään nimeä Neuroni.
Ohjelmiston tarkoituksena on se, että RoamMate-server voi clientin tullessa sen alueelle päivittää RoamMate:n moduuleita eli esim. vaihtaa koneessa oleva NetSeal-ajuri uudempaan tms. Järjestelmän tavoitteena on saada automaitsoitua kyseinen toimenpide mahdollisimman pitkälle ja näin helpottaa clientin ohjelmiston päivitystä.
Tuote rakentuu siis client-server -mallille. Server-osassa
tullaan tekemään liittymä asiakkaan aiempaan ohjelmistoon, johon Neuroni integroidaan.
Client-osalla on rajapinta luonnollisesti server-osalle päin osien kommunikoinnin
mahdollistamiseksi. Muut mahdolliset clientin rajapinnat tullaan määrittämään
myöhemmin.
| RoamMate | Projektin asiakkaana toimivan yrityksen client-server -mallille perustuva ohjelmisto, johon projektissa tehdään laajennuksia |
| Synapsi | Ryhmä, jonka valmistaman ohjelmistotuotteen testausta dokumentissa käsitellään. |
| Neuroni | Projektissa valmistettavan ohjelmistotuotteen työnimi |
| JRE | Java Runtime Environment. Javan virtuaali kone |
| NC | Neuroni Client |
| NS | Neuroni Server |
Client-koneen minivaatimukset:
Server-koneen minivaatmukset:
Client-koneen suositeltavat vaatimukset:
Serever-koneen tehovaatimukset riippuvat luonnollisesti, kuinka monta client konetta on
testauksessa mukana.
Suositeltavat serveri-koneen vaatimukset maksimissaan neljän clientin testaamisen:
Näissä kokoonkokoonpanojen lisäksi tullaan testaus suorittamaan suorittamaan myös käyttäen modeemia kommunikaatioyhteytenä siis ethernet-verkkokoritn lisäksi.
Client-ohjelman testausta varten on syytä varata oma kone. Client-koneessa Neuroni-ohjelmiston virheellinen toiminta voi aihettaa koneen käyttöjärjestelmän joutumisen käyttökelvottomaan tilaan.
Serveri-ohjelman testaukseen on myös hyvä varata oma kone. Vaikkei Neuroni server-ohjelma voikkaan virheellisellä toiminnalla pysyvästi vahingoittaa tietokonetta tai sen muita ohjelmia saattaa se intensiivisessä käytössä viedä varsin paljon prosessori aikaa, jolloin tietokoneen muu käyttö vaikeutuu.
Mikäli kuormatestauksessa testataan useampaa kuin kymentä client-konetta kerralla, tulee testausta varten luoda oma muusta lähiverkosta erotettu testiverkko.
Testauksen suunnittelemiseen käytämme Mercury Interactiven TestDirector 6.0 -ohjelmistoa. Ohjelmiston avulla voimme dokumentoida ja lajitella testitapaukset sekä generoida erilaisia raportteja mm. testitapauslistat, testiraportit, virheraportit jne. TestDirectorin käyttämisestä on myös se hyöty että käyttämämme vaatimusten hallintatyökalu CaliberRM:ssä on integraatio TestDirectoriin, jonka avulla voimme linkittää vaatimuset testitapauksiin, jolloin muutosten sattuessa näemme vaikutusalueet välittömästi.
Tässä kappaleessa kuvataan Neuronin testauksen kannalta olennaiset testauksen henkilöstöstölle asettamat vaatimukset.
Ohjelmiston testaushenkilöstö koostuu testauspäälliköstä sekä varsinaisista testaajista. Seuraavassa lueteltu testaukseen osallistuvien henkilöiden roolit:
Testaus on jaettu loogisiin kokonaisuuksiin ja hajautettu usealle henkilölle, jotta eri osien testaus saadaan suoritettua mahdollisimman rinnakkain ja näin vietyä tehokkaasti läpi. Tarvittaessa testaushenkilöstön määrää voidaan lisätä (mikäli esim. jonkin ohjelmiston osan testaus osoittautuu huomattavasti arvioitua hankalammaksi).
Neuroni toteutetaan NetSeal Technologies -yritykselle ja yritys vaatii ohjelmiston kehittäjiltä vaitiolovelvollisuutta ohjelmiston kehitykseen liittyvissä asioissa. Näin ollen kaikki ryhmän jäsenet joutuvat allekirjoittamaan erillisen sopimuksen asiasta.
Neuronin testaus ei aseta testaajilleen juuri koulutuksellisia vaatimuksia. Ohjelmisto tullaan toteuttamaan ryhmälle tutuissa toteutusympäristöissä (Windows NT ja RedHat 6.2 -ympäristöissä käytettävät kehitysohjelmistot; käytettävät ympäristöt on tarkemmin määritelty Synapsin projektisuunnitelmassa), joten tämän suhteen lisäkoulutusta ei tarvita.
Integrointi testauksen suorittavat kyseisistä moduleista vastuulliset henkilöt. He myös selvittävät keskenään mahdollisesti löytyneet ongelmat. Testauspäälikkö antaa yleiset ohjeet testaamisesta ja varmeentaa raportien perusteella tulokset.
Järjestelmä testauksessa testataan ensin Client-osan ja Server-osan ohjelmat, jonka jälkeen testataan Client-osan ja Server-osan yhteentoimivuus. Näille tehtäville on määritelty vastuulliset kohdassa 3.1. Testauspäälikkö antaa tässäkin kohtaa yleiset ohjeet testaamisesta ja varmeentaa raportien perusteella tulokset. Jokainen testaaja vastaa periaatteessa oman osansa virheiden selvittelystä niin pitkälle, että tietää, mistä osasta ohjelmistoa virhe löytyy.
Käyttöliittymän testauksessa tullaan pyytämään mahdollisemman aikaisessa kommenteja asikasfirman työntekijöiltä. Käyttöliittymän testauksesta vastaava ottaa nämä kommentit, ja parantaa käyttöliittymää niiden perusteella
Mikäli tarvitaan.
Client -moduulin toiminnot, joihin käyttäjä pääsee käsiksi, on selostettu yksityiskohtaisesti Käyttöliittymän määrittelyssä.
Projektin tässä vaiheessa suunniteltu toteutus Neuronista on sen verran suppea, että uskomme pystyvämme testaamaan kaikki Toiminnallisessa määrittelyssä esitetyt toiminnot. Tähän saattaa kuitenkin tulla tarkennuksia siinä vaiheessa, kun Tekninen määrittely saadaan valmiiksi. Ohjelmisto on tällä hetkellä kuitenkin sen verran suppea, että uskomme pystyvämme testaamaan sen kokonaisuudessaan projektin puitteissa.
Tietysti on olemassa erityistilanteita, joita ei välttämättä edes pystytä testaamaan, mutta pääsääntöisesti jokainen Toiminnallisessa määrittelyssä esitetty toiminto olisi tarkoitus testata toimivaksi.
Seuraavassa lueteltu kaikki ne toiminnot, jotka testataan tämän projektin puitteissa. Tarkempi selostus toiminnoista on Toiminnallisessa määrittelyssä. Ominaisuudet ovat jaoteltu Toiminnallinen määrittely -dokumentin mukaan, ja kappalenumerot ovat vastaavat kuin Toiminnallisessa määrittelyssä (alakohdat myös lisäksi numeroituina tässä, testitapausten linkittämisen helpottamiseksi).
4.1.1 Talletettujen versioarvojen lukeminen
4.1.2 Nykyisen version lukeminen
4.1.3 Arvojen vertailu ja tallennus
4.1.4 Käyttäjän informointi
4.2.1. Ilmoitus nykyisestä versionumerosta
4.2.2. Nykyisen versionumeron tarkistus
4.2.3. Ilmoitus päivitystarpeesta
4.2.4. Päivityspyyntö käyttäjälle
4.2.5. Käyttäjän vastaus päivityspyyntöön
4.2.6. Päivityspaketin siirto
4.2.7. Pyyntö päivityspaketin saamiseksi
4.2.8. Päivityspaketin lähetys
4.2.9. Siirron visualisointi
4.2.10. Siirron keskeytys
4.2.11. Päivityspaketin kelvollisuuden tarkistus
4.2.12. Hyväksymisviestin lähetys
4.2.13. Asennusohjelman käynnistys
4.2.14. Selvitetty käyttöliittymää kuvaavassa dokumentissa.
Tässä mainittu testauksen päävaiheet ja -tehtävät.
Tehtäväjärjestys on todennäköisesti vielä puutteellinen ja sitä tullaan projektin
edetessä vielä päivittämään.
Tehtävät on listattu alustavasti kronologisessa järjestyksessä. Osa tehtävistä voidaan suorittaa samanaikaisesti (mm. testiraporttien kirjoittaminen ja virheraporttien kirjoittaminen) ja osaa tehtävistä joudutaan iteratiivisesti toistamaan (mm. testitapausten suorittaminen, testiraportin kirjoittaminen, virheraportin kirjoittaminen, ja sykli uudelleen).
Testitapaukset ovat määritelty omassa dokumentissaan.
Testitapaukset ovat tärkeytensä mukaan lajiteltu kolmeen ryhmään: 1=kriittinen, 2=tärkeä, 3=triviaali. Jokainen kriittisen tärkeysasteen testitapaus on mentävä läpi, jotta kyseinen moduuli läpäisisi testauksen. Triviaaleja testitapauksia ei toistaiseksi ole määritelty, mutta arvo haluttiin ottaa mukaan, jos tulee tilanne että testitapauksia pitää lisätä, jolloin arvon käyttäminen saattaa tulla ajankohtaiseksi.
Virheissä luokitus kulkee samoilla linjoilla, eli olemme määritelleet virheluokat 1=kriittinen, 2=tärkeä, 3=kosmeettinen. Jokainen löydetty kriittinen virhe on korjattava, jotta moduuli läpäisisi regressiotestauksen.
Testauksen suunnitteluun olemme käyttäneet TestDirector-ohjelmistoa (dokumentoitu luvussa 2.4), tämän avulla voimme generoida testisuunnitelmat sekä testausraportit (mahdollisesti myös virheraportit). TestDirectorin käytöstä on myös se hyöty, että voimme suoraan linkata testitapaukset CaliberRM:ssa oleviin vaatimuksiin/määritelmiin, jolloin mahdollisesti vaatimusten muuttuessa näemme välittömästi mihin testitapauksiin muutoksilla on vaikutus.
Moduulitestauksesta vastaa jokaisen moduulin kirjoittaja eikä moduulitestausta erikseen ole dokumentoitu. Koodikatselmoinnit pidetään jokaisen moduulin valmistuttua, ennen moduulien integrointia, jolloin voimme alkuvaiheessa identifioida mahdolliset ongelmatilanteet, jolloin työmäärä seuraavissa vaiheissa toivon mukaan pienenee.
Testauksessa löydettyjen virheiden korjauksesta on vastuussa sen moduulin kirjoittaja, josta virhe löytyy. Virheen löytäjä on velvollinen tekemään luvussa 5 mainitun kaltaisen virheraportin ja informoimaan moduulin kirjoittajaa löytämästään virheestä. Virheen kriittisyydestä riippuen testausta joko jatketaan tai joudutaan keskeyttämään luvussa 10 määriteltyjen ehtojen mukaisesti.
Kuten luvussa 6 käy ilmi on testauksemme kattavuus hyvin suuri, eli testaamme jokaisen toiminnon käsitetasolla. Suunnitelmissamme ei kuitenkaan ole mitata kattavuutta funktiotasolla (ja vaatia mm. 75% kattavuus funktiotasolla esim. ehtolauseiden kaikki eri variaatiot mukaanlukien). Katsomme siis että skoopissamme testauksen kattavuudelle riittävä peruste on testata jokainen toiminto sekä myöskin ottaa huomioon tietyissä tapauksissä raja-arvojen testaus ja virheellisten syötteiden oikea kontrollointi.
Rajoituksia ei toistaiseksi tiedossa, aikataulullisten seikkojen lisäksi. Tarkennetaan projektin myöhäisemmässä vaiheessa mikäli katsotaan tarpeelliseksi.
Järjestelmässämme ei ole erillistä tietokantaa, joka vaatisi testausta. NCData -moduuli on eräänlainen tietopankki, jonka testauksen hoitaa kyseisen moduulin kirjoittaja.
Ei koske projektiamme. Tarkennetaan projektin myöhäisemmässä vaiheessa mikäli katsotaan tarpeelliseksi.
Käyttöliittymästä ei ole tarkoitus suorittaa käytettävyys ym. tutkimuksia. Käyttöliittymästä varmistetaan vain että se toteuttaa määrittelyt ja kaikki käyttöliittymän kautta suoritetut toiminnot lähtevät odotetulla tavalla käyntiin. Emme katso tarpeelliseksi dokumentoida käyttöliittymän testausta erikseen. Tarkennetaan projektin myöhäisemmässä vaiheessa mikäli katsotaan tarpeelliseksi.
Neuronin liittymisen RoamMate ohjelmistoon varmistaa kyseisen moduulin kirjoittaja.
Ei koske projektiamme.
Neuronin toimintaympäristö on VPN (Virtual Private Network), joten erillistä turvallisuustestausta ei vaadita, sillä turvallisuuden hoito on hoidettu alempien tasojen protokollissa.
Toipumista on tarkoitus projektin puitteissa testata kahdessa poikkeustilanteessa. Poikkeustilanteet ovat verrkoyhteyden katkeaminen sekä sähkökatkos. Molemmat poikkeustilanteet on helppo simuloida 'irroittamalla piuhat' eli verkkoyhteyden katkeamisen yhteydessä irroittaa verkkokaapeli hetkellisesti sekä sähkökatkoksen yhteydessä ottaa virtajohto irti hetkellisesti.
NS:n suorituskykyä on tarkoitus testata kirjoittamalla testausskripti, jonka avulla pystymme simuloimaan yhtäaikaisia käyttäjiä. Mikäli aikaa/resursseja/laitteistoa riittää voimme testata järjestelmän suorituskykyä myös luomalla todellisen kuormitustilanteen usealla fyysisellä käyttäjällä.
Regressiotestaus helpoimmillaan voidaa suorittaa moduulitasolla, mikäli muutoksen kohde vaikuttaa vain yhteen itsenäiseen moduuliin. Mikäli muutoksen kohde sijaitsee kohdassa, joka koskee useampaa moduulia on jokainen kyseinen moduuli luonnollisesti testattava erikseen.
Jokaiselle testitapaukselle on määritelty sen tärkeysaste, jonka perusteella voidaan
päätellä kuinka kriittistä kyseisen testitapauksen läpäiseminen onnistuneesti on.
Testisuunnitelmassa määritellään myös tärkeysasteet jokaiselle moduulille, jonka
perusteella voidaan päätellä kuinka kriittistä kyseisen moduulin testauksen
onnistuminen on koko järjestelmän näkökulmasta.
Hyväksymis- ja hylkäämiskriteerejä asetetaan siis myös moduuleille että koko järjestelmälle, jonka perusteella voidaan nähdä mitkä moduulit ovat käyneet testauksen läpi hyväksytysti sekä onko koko järjestelmä läpikäynyt testauksen hyväksytysti.
Testitapausten ajamisesta ovat vastuussa jokaiselle testitapaukselle määritelty vastuuhenkilö. Koko testausprosessin suorittamisesta ja koordinoinnista vastuu on testipäälliköllä. Kyseiset vastuuhenkilöt päättävät onko kyseinen testitapaus/moduuli/koko järjestelmä läpikäynyt testauksen onnistuneesti allamainituin kriteerein.
Yksittäinen testitapaus menee hyväksyttävästi läpi, mikäli sen tulos vastaa sen määriteltyä odotettua tulosta. Testattava moduuli on läpikäynyt testauksen hyväksytysti, jos kaikki kyseisen moduulin testitapaukset, jotka ovat saaneet tärkeysasteen korkea, ovat menneet läpi hyväksyttävästi. Koko järjestelmä on läpikäynyt testauksen hyväksytysti, mikäli jokainen moduuli, joka on saanut tärkeysasteen korkea, on mennyt testauksesta läpi hyväksyttävästi.
Yksittäinen testitapaus ei mene hyväksyttävästi läpi, mikäli sen tulos ei vastaa sen määriteltyä odotettua tulosta. Yksittäinen testitapaus voidaan joutua myös hylkäämään, mikäli huomataan että testitapaus on virheellisesti määritelty tai irrelevantti. Tällöin testitapausta ei noteerata mitenkään, ellei siihen kohdisteta korjaavia toimenpiteitä. Moduuli ei läpäise testausta hyväksytysti, jos yksikin moduulin testitapauksista, joka on saanut tärkeysasteen korka, ei mene läpi hyväksyttävästi. Koko järjestelmä ei läpäise testausta hyväksytysti, jos yksikin järjestelmän moduuleista, joka on saanut tärkeysasteen korkea, ei mene läpi hyväksyttävästi.
Testaus voidaan keskeyttää tilapäisesti, mikäli ohjelmistossa huomataan virhe, joka estää muiden testitapausten ajamisen normaalisti. Virhe on korjattava, jonka jälkeen testaus voi jälleen jatkua. Mikäli ohjelmisto kaatuu, kesken testitapauksen ajon, joudutaan luonnollisesti testitapauksen ajaminenkin keskeyttämään. Testaus saatetaan joutua keskeyttämään myös, jos testaus suoritetaan jossain tilassa, jossa on kiinteät aukioloajat, joiden seurauksena testin ajaminen loppuun ei aukioloaikojen puitteissa ole välttämättä mahdollista.
Vastuu testauksen keskeyttämisen päätöksestä on yksin sillä henkilöllä, joka on kyseistä testitapausta ajamassa. Hän päättää tai määrittää samalla myös, milloin testausta voidaan jatkaa.
Testauksen jatkaminen riippuu siitä mihin testitapauksen ajamiseen testaus jouduttiin keskeyttämään. Yksinkertaisimmillaan riittää, että ajetaan kyseinen testitapaus uudelleen. Mikäli testitapaus jouduttiin keskeyttämään tilanteessa, jossa oli oleellista useamman testitapauksen ajo oikeassa järjestyksessä, joudutaan kaikki testitapaukset, jotka liittyvät tähän jaksoon, ajamaan uudelleen. Mikäli testitapauksen ajamiseen vaadittiin ohjelmistossa jokin tietty tila, täytyy myöskin testauksen jatkuessa saattaa ohjelmisto samaan tilaan kuin se testin keskeytyshetkellä oli.
Testaus voidaan lopettaa, kun kaikki testitapaukset, jotka voidaan ajaa ovat ajettu. Mikäli ohjelmisto täyttää kohdassa 10.1 määritellyt kriteerit, on testaus lopetettu myös onnistuneesti. Testaus voidaan lopettaa myös seuraavissa erikoistilanteissa:
Kaikki testitapaukset, jotka ovat saaneet tärkeysasteen korkea on ajettu hyväksyttävästi, eikä testaustiimillä ole motivaatiota ajaa alemman tärkeystason testitapauksia. Tällöin testiraportissa tulee eksplisiittisesti ilmaista mitkä testitapaukset ovat jääneet ajamatta ja mitä mahdollisia vaikutuksia tällä on ohjelmistoon.
Testaukseen on käytetty aikaa 100% suunniteltua aikaa enemmän, jolloin testaus joudutaan lopettamaan, jotta testaajat vapautuvat ainakin hetkellisesti työskentelemään projektin parissa myös muissa tehtävissä.
Projektin toteuttamisvaihe ei valmistu, eli ohjelmisto ei kaikilta toiminnallisilta osiltaan ole valmis, jolloin myöskään ei testausta voida niiltä osin jatkaa, jotka koskevat toteuttamattomia moduuleita.
| Riskitekijä | Riskin kriittisyys (1-korkea...3-matala) |
Riskin todennäköisyys |
Vaikutusalue | Varasuunnitelma |
| Kokematon testaustiimi | 2 | 65% |
|
|
| Aika ei riitä | 2 | 75% |
|
|
| Testattava ohjelmisto ei valmis | 1 | 45% |
|
|
| Testitapaukset määritelty puutteellisesti | 2 | 30% |
|
|
| Motivaation puute | 3 | 30% |
|
|
| Tarvittava ohjelmisto/hardis ei saatavilla | 1 | 20% |
|
|
Tarkennetaan projektin myöhäisemmässä vaiheessa (aikaisintaan Teknisen määrittelyn valmistuttua).
Jokaisen testitapauksen hyväksynnästä päättää testitapauksen suorittanut testaaja. Viime kädessä päätös hyväksymisestä on kuitenkin testauspäälliköllä.
Koko testauksen hyväksynnästä päättää testauspäällikkö. Testauspäällikön hyväksynnän jälkeen projektipäälliköllä on valtuudet hyväksyä testaus lopullisesti tai hylätä testauksen, jolloin hän joutuu yksityiskohtaisesti perustelemaan miltä osin testaus ei ollut hyväksyttävää, ja tekemään suunnitelman toimenpiteistä, jotka pitää hoitaa, jotta testaus saisi myös projektipäällikön hyväksynnän.
[1] Tik-76.115 Projektisuunnitelma: Automatisoitu ohjelmiston etäpäivitys
Projektisuunnitelma.html
[2] Ilkka Haikala and Jukka Märijärvi: Ohjelmistotuotanto, Espoo, Suomen ATK-kustannus
Oy, 6. painos.
Projektisuunnitelma.html