Team Spider

Sisällysluettelo

1. Johdanto

Degree to which a set of inherent characteristic fulfills requirements

ISO 9000 -standardi määrittelee laadun ylläolevan lauseen mukaisesti määräytyvän siitä, kuinka hyvin ominaisuus täyttää sille määrätyt vaatimukset. Laadunvalvontamme perustuu tähän määritelmään.

Projektiamme hallitaan ketterällä Scrum-menetelmällä, jossa kehitystä tehdään lyhyissä sykleissä ja kukin ominaisuus tehdään nopeasti alusta loppuun. Ominaisuus ei ole valmis ennen kuin se on testattu, tarpeelliset automaattitestit laadittu, koodi on katselmoitu ja muut laadunvalvonnalliset toimenpiteet suoritettu. Näin testaamattomia alueita ei pääse kertymään. Tässä dokumentissa esitellään käytännöt, joihin tiimimme on sitoutunut ja joilla varmistetaan tuotteen korkea laatu.

2. Laatutavoitteet

Todo: Laatutavoitteiden määritys asiakkaan kanssa. Erityisesti tarkasti mitattavat kriteerit.

Prioriteetti määritellään kolmiportaisella asteikolla:

3. Testaus

Tietokoneohjelmistot ovat monimutkaisia ja niitä kehittäessä tehdään väistämättä virheitä. Järjestelmällisellä työskentelyllä ja prosesseja noudattamalla tehtävien virheiden määrää voidaan vähentää ja niiden löytämistä nopeuttaa. Aikaisessa vaiheessa löydetyt virheet ovat useimmiten paljon helpompia korjata, kuin tuotteeseen jäävät. Testauksella pyritään paljastamaan tuotteen heikkoudet ja näin minimoimaan siihen jäävien piilevien virheiden määrä. Testauksella löydetyt ongelmat kerätään raporteiksi, priorisoidaan, korjataan ja ongelmien toistumista tulevaisuudessa pyritään ehkäisemään prosesseja kehittämällä.

3.1. Testauksen tasot

3.1.1. Yksikkötestaus

Agilefantin kanssa on jo aiemmin käytetty automaattisia, jUnit-työkalua käyttäviä yksikkötestejä. Suuri osa järjestelmän logiikasta koostuu tietokannassa olevan tiedon muokkaamisesta ja muotoilemisesta näytettävään tilaan. Tietokannan käyttäminen yksikkötestauksessa on ongelmallista, joten yksikkötestauksessa käytetään myös EasyMock-kirjastoa, jolla voidaan luoda lähtödataa funktioiden testaukseen. Spider-ryhmä laatii automaattitestejä lisäämilleen yksiköille aina kun se ominaisuutta suunnitellessa katsotaan tarpeelliseksi. Yksikkötestejä voidaan hyödyntää monilla tavoin, muun muassa regressiotestauksessa ja Test-driven developmentissa. Näistä lisää alla.

Automaattisten testien kattavuutta on analysoitu Atlassian Clover -työkalulla ja tätä jatkamalla seurataan tilanteen kehitystä. Vaaditusta kattavuustasosta sovitaan asiakkaan kanssa.

3.1.2. Integraatiotestaus ja jatkuva integrointi

Integraatiotestauksessa varmistetaan uusien ominaisuuksien yhteistoiminta vanhojen kanssa ja järjestelmän osa-alueen toiminta muutosten jälkeen. Integraatiota testataan pääasiassa automaattisella, jatkuvalla integroinnilla ja jokaperjantaisilla tutkivan testauksen tilaisuuksilla.

Jatkuvalla integroinnilla tarkoitetaan jokaisen commitin jälkeen suoritettavaa kääntöä ja automaattitestien ajamista. Asiakas on järjestänyt tähän tarkoitukseen Atlassian Bamboo -ohjelmiston, joka huomauttaa ryhmän jäseniä välittömästi jos integraatio epäonnistuu. Tyypillinen syy tähän olisi kääntymättömän koodin lähettäminen versiohallintaan. Koska lähdekoodi on agiilin ryhmän ehdottomasti tärkein työkalu, sen kunnosta täytyy jatkuvasti pitää tarkkaa huolta. Sen takia toimimatonta koodia ei tulla hyväksymään versiohallintaan ja tästä pidetään huoli Bamboon avulla.

3.1.3. Tutkiva testaus (Exploratory Testing, ET)

Tutkivaa testausta suoritetaan etenkien testattaessa täyttävätkö uudet ja merkittävät toiminnallisuudet niille alunperin asetetut vaatimukset ja tavoitteet. Ennen testausta toteuttaja tekee ominaisuudestaan FreeMind-ohjelmalla charterin, jossa kerrotaan mistä tehdyt muutokset löytyvät käyttöliittymästä ja mitkä niiden suurimmat riskit ovat. Testauksen aikana charteria täydennetään siten, että testissä kuljetuista poluista ja testatuista arvoista syntyy yksikäsitteinen kuva.

Luodut ET-charterit löytyvät ET mindmaps-sivulta, niiden katsomiseen tarvitaan ilmainen FreeMind-ohjelma. Esimerkki charterista alla.

Kunkin mindmapin solmun tarkoitusta kuvataan graafisella symbolilla. Alla käyttämämme notaatio.

3.1.4. Testivetoinen kehitys (Test-Driven Development, TDD)

Testivetoisessa kehityksessä ominaisuutta kehitetään iteratiivisesti siten, että ensin tehdään automaatiset yksikkötestit tarvittaville toiminnallisuuksille ja ohjelmaa kehitetään vasta sen jälkeen siten, että se läpäisee tehdyt testit. Tätä jatketaan kunnes tehtävä ominaisuus on valmis.

Projektissa tullaan kokeilemaan TDD:tä sopiviin, haastaviin ja riskialttiisiin tehtäviin. Pääosassa kehitystä TDD:tä ei luultavasti kuitenkaan käytetä, ellei se osoittaudu erityisen hyväksi tarkoituksiimme.

3.1.5. Järjestelmätestaus

Suuri, järjestelmällinen järjestelmätestaus suoritetaan kurssin lopuksi kun tuntiraportointiominaisuus on valmis. Sprinttien pääteeksi järjestettävä testaus on enemmänkin integraatiotestausta, jossa uusien ominaisuuksien toimiminen vanhojen kanssa varmistetaan. Kurssin kiivas tahti estää useammat massiiviset systeemitestaussessiot. Tässä lopputestauksessa voidaan käyttää vanhoja testichartereita ja varmistaa, että vanhat ongelmat eivät ole palanneet. Näin testausta voidaan kohdistaa riskialtiimpiin paikkoihin. Järjestelmätestaus suoritetaan tutkivalla testauksella.

3.1.6. Hyväksymistestaus

Asiakas testaa ryhmän tekemiä muutoksia jokaisen sprintin päätyttyä kun järjestelmästä tuotetaan uusi julkaisu. Lopullinen hyväksymistestaus tapahtuu ennen viimeistä, lyhyttä sprinttiä. Tällöin löydetyt puutteet korjataan loppustabiloinnissa viimeisessä sprintissä.

3.2. Testityypit

3.2.1. Funktionaalinen

Funktionaalisessa testauksessa testataan laadittujen ominaisuuksien vaatimustenmukainen toiminta. ISO 9000 -standardin mukaisesti tuote on laadukas, mikäli se täyttää sille määrätyt vaatimukset. Näin testausta voidaan pitää riittävänä jos sillä voidaan taata tämä.

3.2.2. Laadullinen

Laadullisessa testauksessa testataan esimerkiksi suorituskykyä tai turvallisuutta. Tämä on usein funktionaalista testausta haastavampaa ja vaatii omat kriteerit. Laadullinen testauksemme varmistaa, että julkaisemamme versiot Agilefantista täyttävät sille kappaleessa 2 määrätyt vaatimukset.

4. Laatukäytännöt

4.1 Koodikatselmointi (Code review)

Periaatteenamme on, että kaiken kirjoitetun koodin lukevat vähintään kaksi ihmistä. Mikäli tehtävää ei ole kirjoitettu pariohjelmoiden, täytyy siitä järjestää koodikatselmointi, jossa ohjelmoija esittelee kirjoittamansa koodin ja muut kommentoivat muun muassa muotoilua ja varmistavat, että koodauskäytäntöjä on noudatettu. Ohjelmoijan täytyy korjata katselmoinnissa havaitut puutteet ennen kuin voi merkitä tehtävän tehdyksi.

4.2. Formaali koodikatselmus (Code inspection)

Ryhmä järjestää jollekin dokumentille tai jonkun ominaisuuden koodille formaalimman katselmoinnin. Tässä laatija esittelee tuotostaan ja sitä käydään läpi ryhmän voimin rivi kerrallaan. Formaalia katselmointia ei käytetä kaikkeen, sillä se vie runsaasti aikaa useilta osanottajilta.

5. Käytettävät ohjelmistot ja laitteet

5.1 jUnit

jUnit on yksikkötestaukseen käytettävä kehys, joka helpottaa automaattisten testien laatimista ja ajamista yksittäisille funktioille. Agilefantin yksikkötestit on rakennettu tälle alustalle ja ryhmä tulee jatkamaan sen käyttöä. Kaikki automaattiset testit rakennetaan sen päälle.

6. Laadunvalvontaa tukevat dokumentit

6.1. Testitapaukset

Testitapauksia tehdään oppimistarkoituksessa muutamalle ominaisuudelle. Ne perustuvat näistä ominaisuuksista laadittuihin vaatimusmäärittelyihin ja käyttötapauksiin. Ne auttavat laadunvarmistuksessa näiden ominaisuuksien osalta, muiden laatu varmistetaan muilla tässä dokumentissa esitetyillä tavoilla.

7. Testauksessa syntyvät dokumentit

7.1 Bugiseuranta

7.1.1. Ryhmän aiheuttamat bugit

Kiireelliset korjataan heti, muut lisätään sprintin backlogiin, missä ne priorisoidaan mahdollisimman nopeasti product ownerin kanssa ja korjataan prioriteetin mukaisesti.

7.1.2. Löydetyt vanhat bugit

Vanhat bugit lisätään Spider-projektin backlogiin, missä product owner priorisoi ne ja niiden korjauksesta päätetään sprintinsuunnittelutapaamisessa. Sekä ryhmän että muiden löytämät bugit laitetaan samaan paikkaan.

7.2. ET-charterit

ET-charterit kuvaavat tutkivan testauksen kulkua ja tuloksia. Luodut charterit löytyvät ET mindmaps-sivulta, niiden katsomiseen tarvitaan ilmainen FreeMind-ohjelma.

7.3. Testitapausten suorittamisloki

Muutamista testitapauksistamme tehdään taulukko ja niiden suorittamisessa tehdyt havainnot merkitään siihen. Pohjana käytetään kurssilla tarjottavaa pohjaa.

8. Laadunseurannan tulosten hyödyntäminen ja esittely

Viikottaisessa demoon luodaan laadunvalvonnan metriikat ja tulokset esitellään asiakkaalle. Tällöin näytetään tilastoja muun muassa automaattitestauksen kattavuudesta, löydetyistä bugeista ja laadunvalvontaan käytetystä ajasta.

Lähteet

EasyMock. online. viitattu 22.5.2008 Saatavilla: http://www.easymock.org/