Team Maranello. Laatusuunnitelma. Project Course. Sisällysluettolo. 1. Johdanto. Laatusuunnitelma - Agilefant.org

Transkriptio

1 1 Project Course Laatusuunnitelma Added by Roni Ström, last edited by Roni Ström on Dec 09, 2007 Labels: (None) Team Maranello (view change) Versio Pvm Tekijä Kuvaus Roni Ström Katselmointi Roni Ström Lisättiin informaatio siitä, että kapplaite 3-7 ei enää ylläpidetä Ilkka Lehto Katselmointi ja löytyneiden ongelmien korjaus Roni Ström Lisättiin referenssit ja hiottiin kirjoitusvirheitä Roni Ström Lisättiin johdanto Roni Ström Lisättiin jalkautus Roni Ström Lisättiin dokumentaatio Roni Ström Lisättiin mitä ei testata Roni Ström Lisättiin muut menetelmät Roni Ström Lisättiin laatupaletti Roni Ström Lisättiin loput testausmenetelmät Roni Ström Lisättiin yksikkö- ja integraatiotestaus Roni Ström Lisättiin ketterä prosessikuvaus Roni Ström Lisättiin tavoitteet Roni Ström Sivupohjan luonti Sisällysluettolo Team Maranello Sisällysluettolo 1. Johdanto 2. Laatutavoitteet 3. Ketterä ohjelmistokehitys 4. Testaus 5. Muut menetelmät 6. Mitä ei testata? 6. Dokumentaatio 7. Jalkautus 1. Johdanto John Oakland määrittelee laadun kirjassaan Statistical Process Control seuraavasti 1 : "Quality is meeting customer requirements."

2 2 Oaklandin määritelmä ohjaa tämän projektin laadunvarmistusta ja testausta. Emme kerää metriikoita tai tee testausta, joka ei tuota asiakkalle lisäarvoa. Keskitymme kaikessa tekemisessä täyttämään asiakkaan vaatimukset ja tavoitteet. Toiseksi, sen sijaan, että keskittyisimme kokonaisvaltaiseen tarkistukseen, testaukseen, katselmointiin ja mittaukseen iteraation lopussa, pyrimme tuomaan laadunvarmistuksen painopistettä iteraation alkuun ja keskivaiheille. Toisin sanoen sen sijaan, että keskittyisimme tarkistamaan olemmeko tehneet työn laadukkaasti, keskitymme tekemään työn laadukkaasti. Tämä myös tukee yleistä käsitystä siitä, että mitä myöhemmin bugit löydetään, sitä kalliimpaa niiden korjaaminen on. Asiat siis yritetään tehdä kerralla laadukkaasti. Tässä dokumentissa on kuvattu millä menetelmillä, käytännöillä ja työkaluilla täytämme asiakkaan laatutavoitteet. Lisäksi lampuilla ( ) on kuvattu linkkejä tämän dokumentin ulkopuolisiin lähteisiin kuten muihin wiki-sivuihin, joista löytyy kyseisestä aihealueesta lisää tietoa. 2. Laatutavoitteet Taulukko 1. Tärkeimmät laatutavoitteet. Nimi Kuvaus Verifiointi Lähde Visio Projektin visio täyttyy Projektin vision täyttymisestä saadaan palautetta ATMAN-projektin yhteistyöyrityksiltä ja Iteration X:ltä, joka käyttää Agilefanttia omassa projektissaan. Projektisuunnitelma Toiminnallisuus Sprinttien backlogitemit ja tavoitteet täyttyvät sen loppuun mennessä Tiimi seuraa edistymistä Agilefantin burndownkaaviosta. Asiakas tekee lopullisen verifioinnin sprintin lopussa pidettävässä demo-tilaisuudessa. Projektisuunnitelma Suorituskyky Järjestelmän suorituskyky ei huonone entisestään. Tehdään päivittäistä suorituskykytestausta, sekä asiakkaan käytössä olevaan Agilefanttiin, että tiimin kehitysversioon. Lisäksi jokaisen commitin jälkeen ajetaan automaattisesti suorituskykytestaus kehitysversioon, jolloin nähdään uuden toiminnallisuuden vaikutus suorituskykyyn. N1 Jatkokehitettävyys Kehityksessä huomioidaan järjestelmän jatkokehitettävyys. Jatkokehitettävyyttä arvioi asiakkaan teknisen yhteyshenkilön, Ville Heikkilän, lisäksi vertaisryhmä. N2 Käytettävyys Tehokäyttäjien käytettävyyttä on parannettava. Kerätään palautetta kaikilta Agilefantin tehokäyttäjiltä. N3 Käyttöönotto Järjestelmän käyttöönotto ei saa vaikeutua entisestään. Kerätään palautetta Iteration X-ryhmältä ja ATMANprojektin yhteistyöyrityksiltä. N4 Yhteensopivuus Järjestelmän on toimittava Linux- ja Windows-ympäristöissä Firefox selaimella. Testataan tutkivalla testauskella toimiiko järjestelmä tarkoituksenmukaisesti. N5 Taulukko 2. Laatupaletti, joka kuvaa käytettyjen menetelmien relaation laatutavoitteisiin. Laatutavoitte et Käytäntö / menetelmä Visio Toiminnallisu us Suoritusky ky Jatkokehitettäv yys Käytettävy ys Käyttöönot to Yhtensopivu us Ketterä ohjelmistokehitys x x x Yksikkö- ja integraatiotestaus x x Systeemitestaus x x x x

3 3 Hyväksymistestaus x x x x x x x Suorituskykytestaus x x Jatkuva integrointi x x x x Käytettävyystestaus x x Yhteensopivuustest aus x Tutkiva testaus x x x Ad-hoc testaus x x Test-driven development x 3. Ketterä ohjelmistokehitys Huomio! Kappaleita 3-7 ei enää päivitetä tähän dokumenttiin, vaan QA käytäntöjä hiotaan ja kommunikoidaan retrospektiiveissä. Tiimin merkittävin yksittäinen päätös liittyen asiakkaan laatutavoitteisiin pääsemiseksi on ketterien menetelmien käyttö omassa ohjelmistokehityksessä. Scrumin ja XP menetelmien avulla pyritään siihen, että ohjelmistokehitys on koko ajan laadukasta, eli täyttää asiakkaan vaatimukset ja tavoitteet Lyhyet iteraatiot Asiakkaalle tuotetaan säännöllisesti ja lyhyissä iteraatiossa (3 viikkoa) uutta toiminnallisuutta. Tämän ansiosta hän voi nopeasti antaa palautetta siitä, onko tiimi päässyt tavoitteisiin ja tarvittaessa voi vaihtaa tavoitteita. Lyhyistä iteraatioista seuraa, että yksittäisten työtehtävien (backlog-itemien) on oltava työmäärältään pienehköjä (max 30h), mikä helpottaa työmääräarvioita, katselmointeja ja testausta, sekä vähentää epävarmuutta Face-to-face kommunikaatio Face-to-face kommunikaatioon on panostettu dokumentaation kustannuksella. Viikottaisissa Scrum-tapaamisissa tuodaan läpinäkyvyyttä kehitystyöhän kertomalla, mitä kukakin tekee, ja minkälaisia ongelmia on tullut vastaan. Ongelmia ratkotaan yhdessä ja vaikeita backlogitemeitä ratkaistaan pariohjelmointina. Jos vaatimuksista tai tavotteista on epäselvyyksiä, kehittäjät voivat itse olla suoraan yhteydessä asiakkaaseen, joka tarvittaessa tulee paikan päälle antamaan lisäinformaatiota Vastuunjako Testauksen ja laadunvarmistuksen vastuu on koko tiimillä, mutta etenkin jokainen vastaa oman työnsä laadusta. Erillisiä testaajia tiimissämme ei ole, vaan QA-tiimin päätehtävänä on luoda hyvät puitteet laadukkaaseen ohjelmistokehitykseen, kouluttaa tiimiä, jalkauttaa laatusuunnitelma, sekä jatkokehittää prosessia ja menetelmiä. Tavoitteena on vähentää laadunvarmistukseen käytettävää työmäärää prosessin lopusta ja pyrkiä mm. TDD:tä apuna käyttäen tekemään jo ensimmäisellä koodauskerralla laadukasta työtä. Näin pyritään minimoimaan loppuvaiheessa löytyviä bugeja, joiden korjaaminen tulee kalliimmaksi mitä myöhemmin ne löydetään. Scrum Masterin tehtävänä on eliminoida ulkoisia häiriötekijöitä ja varmistaa kehittäjille työrauha ladukkaaseen työhön. Lisäksi hän valvoo, että aikataulua ei kiristetä eikä työmäärää kasvateta sprintin aikana, jolloin alkuperäisiin laatutavotteisin pääseminen pyritään varmistamaan Hajautettu vaatimusmäärittely

4 4 Kehittäjät osallistuvat aktiivisesti myös vaatimusten hankintaan ja analysointiin, jota tehdään ennen sprintin alkua ja sprintplanning kokouksessa. Tällä pyritään siihen, että koko tiimi ymmärtää, mitä vaatimuksia ja tavoitteita asiakkaalla on kehitettävän järjestelmän suhteen. 4. Testaus Testauksella pyritään varmistamaan, että tehty työ on ollut laadukasta eli vastaa asiakkaan vaatimuksia ja tavotteita. Lisäksi automatisoitu testaus tukee jatkokehitystä, koska ennen uuden toiminnallisuuden implementointia voidaan varmistaa, että se ei riko mitään aikaisemmin toteutettua toiminnallisuutta. Alla on kuvattu eri testauskäytännöt ja jokaisen kappaleen lopussa on kuvattu mitä työkaluja siihen liittyy ja milloin sitä suoritetaan Yksikkö- ja integraatiotestaus Yksikkö- ja integraatiotestit toteutetaan junitilla käyttäen apuna yhdessä asiakkaan teknisen yhteyhenkilön kanssa toteutettavaa testausympäristöä. Testausympäristöllä generoidaan testidata ja se ohjaa yhdenmukaisten automatisoitujen testien tekemiseen. Testien kattavuuteen ei ole asetettu tavoiterajaa, mutta ennen toiminnallisuuden implementointia tarkistetaan kattavuustyökalulla, että mitään oleellista ei ole jäänyt testaamatta. junit, Atlassian Clover Testit rohkaistaan kirjoittamaan ennen koodia, mutta ne on tehtävä viimeistään ennen implementointia. Yksikkötestaus Integraatiotestaus 4.2. Systeemitestaus Kattavempaa, lähes koko järjestelmään kohdistuvaa testausta, tehdään suurista toiminnallisuuksista kokonaisuuksista, kuten Daily Work ja Development Portfolio Management-näkymistä. Testausta varten suunnitellaan testitapaukset, joissa pyritään huomioimaan normaalia kattavemmin eri käyttö- ja poikkeustapaukset. Tällä täytetään myös yksi kurssin asettamista vaatimuksista testaukselle ja laadunvarmistukselle, että vähintään puolet tehtävästä toiminnallisuudesta tulee olla testitapauksilla suunniteltua. Systeemitestauksesta osa pyritään automatisoimaan junitilla ja osa tehdään tutkivana testauksena. junit, Atlassian Clover, FreeMind (ET lokia varten) Testitapauksen pyritään suunnittelemaan sprintin puoliväliin mennessä ja itse systeemitestit suoritetaan viimeistään freeze-pointin yhteydessä Hyväksymistestaus Asiakas tekee hyväksymistestausta pääasiassa sprintin päättyessä pidettävässä demo-kokouksessa. Tämän lisäksi uusin versio asennetaan asiakkaan palvelimelle, jolloin hyväksymistestaus jatkuu käytännössä myös seuraavan sprintin ajan. Kehitystiimin Agilefant, asiakkaan Agilefant Sprintin lopussa ja seuraavan sprintin aikana Suorituskykytestaus Suorituskykytestausta tehdään kahteen järjestelmään: asiakkaan ja tiimin Agilefanttin. Asiakkaan Agilefanttiin kohdistetaan automatisoitu suorituskykytestaus joka päivä klo 12. Tämän avulla pyritään saamaan ymmärrys kuinka nopea tämänhetkinen versio järjestelmästä on. Asennettaessa uusi versio asiakkaalle nähdään historiatietoon verrattaessa nopeutuuko vai hidastuuko järjestelmän käyttö uuden version myötä. Tiimin Agilefantin suorituskykytestaus on integroitu jatkuvaan integrointipalvelimeen, jolloin jokaisen commitin jälkee ajetaan suorituskykytestit. Näin voidaan seurata miten jokainen uusi toiminnallisus vaikuttaa järjestelmän suorituskykyyn ennen kuin se päätyy asiakkaan testattavaksi sprintin lopussa. jmeter, jchav, Atlassian Bamboo, asiakkaan Agilefant, tiimin Agilefant

5 5 Asiakkaan Agilefanttiin joka päivä klo 12, tiimin agilefanttiin jokaisen commitin jälkeen. Suorituskykytestaus 4.5. Jatkuva integrointi Jokaisen commitin jälkeen ajetaan kaikki järjestelmän automatisoidut junit-testit ja päivitetään uusin kehitysversio tiimin palvelimeen. Jos tässä vaiheessa esiintyy ongelmia, järjestelmä lähettää koko tiimille hälytyssähköpostit, josta selviää, että nykyinen buildi on rikki. Tällä pyritään ehkäisemään rikkinäisen koodin jatkokehitys. Atlassian Bamboo, Ant, Svn, tiimin Agilefant Jokaisen commitin jälkeen Käytettävyystestaus Järjestelmän käytettävyydestä kerätään palautetta kaikilta projektin sidosryhmiltä. Kehitysideat lisätään asiakkaan Agilefantin product-backlogiin ja niiden implementoinnista keskustellaan yhdessä asiakkaan kanssa. Ensisijaisesti pyritään parantamaan tehokäyttäjien näkökulmasta käytettävyyttä tarvittaessa käyttöliittymän opittavuuden ja noviisikäyttäjien kustannuksella. Tiimi testaa myös käytettävyyttä uusien toiminnallisuuksien osalta tutkivalla testauksella sprinttien freezepointtien yhteydessä. Agilefant, FreeMind Palautteen kerääminen jatkuvaa, tutkiva testaus sprintin freeze-pointin yhteydessä Yhteensopivuustestaus Järjestelmän yhteensopivuutta Linux-käyttöjärjestelmään ja Firefox-selaimeen testataan jatkuvasti, sekä tiimin että asiakkaan puolesta. Lisäksi kaksi kehittäjää tekevät ohjelmistokehitystä ja testausta Windows-ympäristössä. Yhteensopivuustestin merkitys kasvaa aina otettaessa käyttöön jotakin uusia ohjelmistoja tai kirjastoja, jotka ovat testattava tapauskohtaisesti molemmissa käyttöjärjestelmissä ennen niiden implementointia järjestelmään. Agilefant Jatkuvaa tekemistä Tutkiva testaus Tutkivaa testausta suoritetaan etenkien testattaessa täyttävätkö uudet ja merkittävät toiminnallisuudet niille alunperin asetetut vaatimukset ja tavoitteet. Testausta ennen siitä tehdään charteri, jossa määritellään tarkaan testausken tavoitteet. Testauksen aikana pidetään FreeMind-ohjelmalla lokia testin kulusta. Tutkivaa testausta käytetään mahdollisesti myös testattaessa vertaisryhmän tuotetta. Agilefant, FreeMind Ennen merkittävien toiminnallisuuksien implementointia, vertaisryhmätestauksessa Ad-hoc-testaus Ad-hoc-testaamisella tarkoitetaan satunnaista ja juuri tilanteeseen sopivaa testasta, mutta jota ei suunnitella eikä kirjata kuten tutkivaa testausta. Tämä voidana laskea myös osaksi kehitystyötä ja se tukee varsinkin eri toteutusvaihtoehtojen vertaamista. Ad-hoc-testaus voi esimerkiksi tarkoittaa käyttöliittymän kautta tehtävää testausta, suorituskykytestausta tai integraatiotestausta. Tilanteeseen sopiva. Aina tarvittaessa.

6 Test-driven development Testien kijoittamiseen ennen varsinaista koodia rohkaistaan, mutta sen käyttöä ei pakoteta. TDD:llä pyritään etenkin siihen, että kehittäjä kiinittäisi huomiota laadunvarmistukseen jo mahdollisimman varhaisessa vaiheessa, jolloin todennäköisyys bugien löytymiselle myöhemmin on pienempi. junit Ennen varsinaisen koodin kirjoitusta. 5. Muut menetelmät 5.1 Koodayskäytännöt Kuvattu projektisuunnitelmassa luvussa Koodauskäytännöt Bugienseuranta Kuvattu projektisuunnitelmassa luvussa Bugiseuranta Dokumenttikatselmoinnit Kuvattu projektisuunnitelmassa luvussa Dokumentointi Tilaseuranta Kuluvan sprintin tilaa voi seurata lähes reaaliajassa Agilefantista, josta selviää jokaisen backlogitemin alkuperäinen työmääräarvio, jäljellä oleva työmääräarvio, sekä tila. Sprintistä saa lisäksi kokonaiskuvan katsomalla burndown-kaaviota. Done-kriteerit Agilefant 6. Mitä ei testata? Asiakkan toivomuksesta järjestelmän ns. legacy-koodiin, joka on toteutettu aiemmin, ei kiinnitetä testauksessa ja laadunvarmistuksessa huomiota. Kuitenkin, jos uutta toiminnallisuutta implementoidessa tarvitsee muuttaa legacykoodia niin samalla sitä refaktoroidaan ja kommentoidaan. Myös rikkoutuneet legacy-testit korjataan. Asiakkaan toivomuksesta järjestelmän toimivuutta ei testata muilla selaimilla kuin Firefoxilla. Asikkaan toivomuksesta järjestelmän yhtensopivustestaus painottuu Linuxille Windowsin kustannuksella. Tehokäyttäjien käytettävyyteen kiinnitetään huomiota käyttöliittymän opittavuuden ja noviisikäyttäjien kustannuksella. Tästä syystä ei myöskään tehdä käyttöliittymätestausta muilla kuin järjestelmän tehokäyttäjillä. Järjestelmän soveltuvutta muuhun käyttöön kuin ohjelmistokehitykseen ei testata. Järjestelmän soveltuvuutta muuhun prosessimalliin kuin Cycles of Controlliin ei lähtökohtaisesti testata. 6. Dokumentaatio 6.1. Bugiraportointi Kuvattu projektisuunnitelmassa luvussa Bugiseuranta Testitapausmatriisi Tesitapausmatriisissa on kuvattu testitapaukset ja niiden suoritusloki.

7 7 Lisätietoa wikissä: Testitapausmatriisi 6.3. Testiympäristö Testausta tehdään MotorHomessa ja kehittäjien omilla koneilla. Kehitys- ja testausympäristöt ovat lähes identtiset asiakkaan Agilefant-ympäristön kanssa. Tämän lisäksi kehittäjät testaavat tekemäänsä uutta toiminnallisuutta aina myös ns. "oikealla datalla", joka haetaan mysqldump-ohjelmalla asiakkaan tietokannasta Testitapaukset Testitapaukset suunnitellaan normaalia kattavammin Daily Work- ja Development Portfolio Management-näkymistä. Testitapauksista koostetaan lyhyt kuvaus testitapausmatriisiin ja tarvittaessa kattavempi kuvaus wikiin. Lisäksi suoritetuista teisteistä pidetään lokia. 7. Jalkautus 7.1. Koulutus Wikin, koodiesimerkkien, koulutuspäivien ja pariohjelmoinnin avulla pyritään kouluttamaan toinen toisiamme. Isona apuna on yhteiset toimitilat Innopolissa, jossa ongelmanratkaisua tiimin kesken harjoitetaan lähes päivittäin. Lisäksi tehdään erilaisia checklistoja wikiin esimerkiksi tutkivasta teustauksesta, done-kriteereistä, integraatiotestauksesta, joista on nopea tarkistaa onko kaikki tiettyyn prosessivaiheeseen liittyvät tehtävät huomioitu Vastuunjako Roni kouluttaa laatusuunnitelman sisällön Rekolle, Hannekselle, Ilkalle ja Villelle. Reko ja Hannes kouluttavat laatusuunnitelman edelleen neljälle muulle kehittäjälle eli Mikalle, Mikolle, Aleksille ja Teemulle. Tämän lisäksi ainain Ilkka ja Ville katselmoivat laatusuunnitelman, että se täyttää sille asetetut vaatimukset. Referenssit 1 Oakland, John S. Statistical Process Control, Fifth Edition Paperback Mentorin kommentit: Moi, Katsoin QA planin läpi. Kaikenkaikkiaan hyvää tavaraa. Asiat tuli dokumentissanne kerrottua ilman turhaa jaarittelua. Voisitteko vielä tarkentaa seuraavia asioita: Kuka on vastuussa testitapausten ja testichartereiden suunnittelusta? Mihin suunnittelutyö ajoittuu? Kummallekkaan tehtävälle ei ole allokoitu iteraatiosuunnitelman mukaan aikaa eikä laadunvarmistussuunnitelma ota asiaan juurikaan kantaa. Regressiotestauksesta ei mainittu suunnitelmassa mitään. Epäilemättä jatkuvan integroinnin ja yksikkötestien avulla saatte kyseistä funktiota hoidettua. Meinaatteko tehdä manuaalista regressiotestausta tämän lisäksi ja miten meinaatte asiaa hoitaa? Koska regressiotestaus ja testaus ylipäätään lepää ketterässä projektissa paljon automaattisen testauksen päällä niin suunnitelmat esim. yksikkötestauskäytäntöjen jalkauttamiseen pitää olla hyvät. Itselleni ei ainakaan kirjallisen suunnitelman perusteella välittynyt suurta uskottavuudentuntua, että kaikki projektissanne oikeasti kirjoittavat testejä saati sitten tekevät TDD:tä. Kokemusteni mukaan harva T projekti onnistuu oikeasti jalkauttamaan näitä käytäntöjä. Totuus voi tietenkin teidän kohdalla olla jotain aivan muuta, mutta kiinnittäkää silti asiaan huomiota. Yleensä homma menee metsään, koska ei käytetä TDD:tä koska ei ylipäätään ole kokemusta junit testien kirjoittamisesta jonka jälkeen testien kirjoittaminen on vaikeaa ja aikaavievää jälkikäteen. Suunnitelma ei maininnut koodikatselmuksen järjestämisestä mitään vaikka kurssivaatimukset listaavat sen pakollisena

8 8 Lisäksi voisitteko kertoa mitä alla oleva lause tarkoittaa: "Testien kattavuuteen ei ole asetettu tavoiterajaa, mutta ennen toiminnallisuuden implementointia tarkistetaan kattavuustyökalulla, että mitään oleellista ei ole jäänyt testaamatta." Yritin laittaa nämä kommentit wikiin, mutta en onnistunut. Lokkauduin sisään omilla tunnareilla, mutta en löytänyt edit nappia mistään. Onkohan mulla jotkut mopo-tunnarit tuonne? terveisin, seppo Posted by Roni Ström at Nov 06, :14 Site running on a free Atlassian Confluence Open Source Project License granted to Agilefant. Evaluate Confluence today. Powered by Atlassian Confluence, the Enterprise Wiki. (Version: Build:#807 May 20, 2007) - Bug/feature request - Contact Administrators