Convergence of messaging

Tässä dokumentissa kuvataan viestien hallintaan suunnitellun Converge-järjestelmän testaussuunnitelma ja testaukseen liittyvät dokumentit.

Converge-järjestelmä on toteutettu Helsingin Yliopiston Ohjelmistotuotantoprojektina syksyllä 2002. Järjestelmä on tarkoitettu käyttäjän henkilökohtaisten viestien hallintaan. Käyttäjä voi luoda profiileita ja kontekstimalleja, joiden perusteella hänen viestejään käsitellään käyttäjän toivomalla tavalla. Järjestelmän prototyyppiin on toteutettu WWW-käyttöliittymä, jonka kautta järjestelmää käytetään.

Testaussuunnitelma ja ohjelmiston testaus toteutetaan osana Helsingin Yliopiston Tietojenkäsittelytieteen laitoksen Ohjelmistotuotantoprojektia. Testauksella pyritään varmistumaan siitä, että ohjelmisto toteuttaa määrittelydokumentin mukaisen toiminnallisuuden sekä ohjelmistolle asetetut implisiittiset laatuvaatimukset.

Testausryhmä

Testaukseen osallistuu koko projektiryhmä ainakin niiltä osin, että jokainen henkilö testaa itse tuottamansa luokat luokkatestauksella.

Testattavat ohjelman osat

Ohjelmisto pyritään testaamaan käyttöliittymätestauksella mahdollisimman kattavasti siltä osin kuin se on mahdollista. Ohjelmiston testauksessa pyritään kiinnittämään erityistä huomiota ryhmän toteuttamien osien testaukseen. Näitä osia ovat tiedonhakumoduuli, ydin sekä asiakasmoduuli. Lisäksi testataan asiakasohjelmiston käyttöliittymä.

Testaamatta jätettävät ohjelman osat

Projektiryhmä jättää testaamatta kolmannen osapuolen komponentit muilta osin kuin järjestelmätestauksen kautta. Näitä komponentteja ovat tiedonhakumodulissa JavaMail sekä tähän liittyvä Javabeans Activation Framework, ytimessä Xindice-tietokanta sekä Drools ja asiakasmoduulissa Webcore-palvelinohjelmisto.

Testausympäristö

Testauksessa käytetään Linux CSL2-ympäristöä ja Java-ajoympäristön versiota 1.4.1. Järjestelmätestaus suoritetaan käyttäen sekä yhtä, että useampaa tietokonetta yhtä aikaa. Koneissa on oltava WWW-selain ja riittävä suorituskyky. Asiakasohjelmiston testaus suoritetaan Mozilla-selaimella (versio 1.0.1 tai uudempi).

Testaustapa

Testauksessa pyritään löytämään virheitä tai puutteita ohjelman toimintalogiikasta tarkasteltuna määrittelydokumenttia vasten. Testauksella pyritään kattamaan mahdollisimman suuri osa ohjelmistosta. Testeissä ei tutkita ohjelman suorituskykyä, virhesietoisuutta tai muita vastaavia ominaisuuksia. Testauksessa ei käytetä apuna valmiita testaustyöhön tarkoitettuja ohjelmistoja.

Testaus suoritetaan ennalta laadittujen testitapausten mukaan. Testitapaukset laaditaan pääosin määrittelydokumentin pohjalta käyttäen myös JavaDocia sekä lähdekoodia. Testitapaukset tehdään ennen testauksen aloittamista. Testitapauksia voidaan myös lisätä kesken testauksen, mikäli tarvetta ilmenee. Yksittäinen testitapaus katsotaan hyväksyttävästi suoritetuksi kun testin suorituksen tulos on sama vastaavan testausdokumenttiin kirjatun testin odotettu tulos.

Löytyneet virheet raportoidaan testausdokumenttiin ja pyritään korjaamaan. Virheiden korjauksen jälkeen ne ohjelman osat, joihin muutokset vaikuttavat pyritään testaamaan uudelleen. Testaus katsotaan päättyneeksi, kun kaikki testitapaukset on käyty läpi, tai viimeistään 19.12.2002.

Testausvaiheet

Ohjelmiston testaus suoritetaan vaiheissa. Testaus alkaa yhden luokan toiminnallisuuden testaamisesta ja etenee isompiin kokonaisuuksiin. Lopuksi testataan koko ohjelmiston toiminta järjestelmätestaus-vaiheessa. Converge-järjestelmän testaamisessa moduulitestaus ja integraatiotestaus jäävät vähemmälle huomiolle ajan puutteen vuoksi.

Luokkatestaus

Luokkatestaus pyritään suorittamaan kullekin luokalle siinä vaiheessa, kun luokkaa toteutetaan. Luokkatestaus suoritetaan white-box -menetelmällä kirjoittamalla luokalle testiohjelma, joka testaa vähintään luokan tärkeimpien metodien toiminnan. Testejä ei tarvitse raportoida, vaan virheet korjataan havaittaessa.

Moduulitestaus

Moduulitestauksessa testauksen kohteena on yksittäinen moduuli, jonka toimintaa verrataan suunnitteludokumentissa sille asetettuihin vaatimuksiin. Moduulin testaa sen toteuttanut henkilö tai henkilöt. Converge-järjestelmässä testataan seuraavat moduulit: tiedonhakumoduuli, ydin ja asiakasmoduuli, joka pitää sisällään myös asiakasohjelmiston. Moduulitestauksen suorittavat kyseisen moduulin vastuuhenkilöt luokkatestauksen yhteydessä. Moduulitestauksen testitapauksia ja tuloksia ei dokumentoida, vaan virheet korjataan havaittaessa.

Integraatiotestaus

Integrointitestauksessa yhdistellään yhteen moduuleita tai moduuliryhmiä. Testaamalla pyritään selvittämään erityisesti, että moduulin tarjoama rajapinta toimii, kuten suunnitteludokumentissa on määritelty. Integrointitestaus voidaan tarvittaessa toteuttaa rinnakkain moduulitestauksen kanssa.
Integraatiotestausta ei ajanpuutteen vuoksi toteuteta. Kuitenkin kunkin moduulin testausvaiheessa on testattu myös moduuleiden tarjoamat rajapinnat.

Järjestelmätestaus

Järjestelmätestauksessa ohjelmistoa tarkastellaan kokonaisuutena, pyrkimyksenä varmistua siitä, että ohjelmisto vastaa määrittelydokumentissa asetettuja vaatimuksia.
Järjestelmätestaus suoritetaan black-box -menetelmällä käyttäen asiakasohjelmiston WWW-käyttöliittymää.

Tuotettavat dokumentit

Tämän dokumentin lisäksi tuotetaan testausdokumenttti, joka pitää sisällään testitapaukset sekä niiden tulokset ja mahdollisesti löydetyt puutteet. Testausdokumenttiin ei kirjata luokkatestauksen testitapauksia eikä testituloksia.

Testitapaukset kirjataan testausdokumenttiin ennen testauksen aloittamista. Kuhunkin testitapaukseen kirjataan myös odotettu tulos. Testitapauksien suorittamisen jälkeen testin tulos kirjataan testausdokumenttiin.
Testausdokumentissa testitapaukset on luokiteltu testattavan toiminnon mukaisesti liittämällä järjestelmätestausvaiheen tunnuksen J perään testitapauksen numero. Virheet löytäneet testit suoritetaan virheiden korjauksen jälkeen uudelleen ja dokumentoidaan liittämällä testin alkuperäisen tunnuksen perään tunnus, joka ilmaisee, monettako kertaa testi suoritetaan, esimerkiksi J20-II.

Testauksen aikataulu

Vaihe	Valmis	Vastuuhenkilö
Testaussuunnitelma valmis	11.12.2002	Tea
Testitapaukset valmiit	12.12.2002	Tea
Moduulitestaus valmis	12.12.2002	Moduulin kirjoittaja
Järjestelmätestaus valmis	19.12.2002	Ryhmä
Testausdokumentti valmis	20.12.2002	Tea

Testauksen riskianalyysi

Ajan puutteen vuoksi on olemassa erityisen suuri riski testauksessa epäonnistumiselle. Tämän vuoksi ryhmä kiinnittää erityisen suurta huomiota testauksen aikatauluun. Tämän lisäksi juuri testauksen kannalta olennaisia riskejä on pyritty listaamaan alle.

Työn viivästyminen

Riskinä aikataulutuksesta huolimatta työn viivästyminen.
Riskin toteutuminen olisi projektin valmistumisen kannalta kriittinen. Riskiä pyritään vähentämään jakamalla työtä sopivasti. Tarvittaessa testitapauksille määritellään prioriteetit ja mietitään, mitkä testitapaukset voitaisiin jättää suorittamatta.

Ryhmän jäsenen sairastuminen

Riskinä ryhmän jäsenten sairastumiset, loukkaantumset tai muut syyt, jotka estävät henkilön osallistumisen työhön, joka taas saattaa aiheuttaa muille enemmän työtä ja sitä kautta johtaa aikataulun viivästymiseen.
Ryhmän jäsenet eivät pysty hallitsemaan riskiä. Riskin toteutuessa estynyt henkilö pyrkii mahdollisuuksien mukaan jatkamaan työskentelyään kotoa käsin.

Laitteisto- tai järjestelmäongelmat

Riskinä laitteistojen tai käyttöjärjestelmäympäristöjen toimimattomuus tai Tietojenkäsittelytieteen laitokselle pääsyn estyminen.
Riskiä toteutuessa jatketaan työtä toisella tietokoneella tai tarvittaessa toisena ajankohtana, kuitenkin niin, että jokainen saa suoritettua oman osansa työstä. Myös mahdollisia järjestelmän käyttökatkoja pyritään ennakoimaan seuraamalla laitoksen uutisia.

Tästä dokumentista ...

Tämä dokumentti tehtiin ohjelmistolla LaTeX2HTML translator Version 2002 (1.62)