1.2.2012

Scrum ja jäljitettävyys

Jäljitettävyys vaatimuksista versionhallintaan
Lupasin kirjoittaa Scrumin taipumisesta lääkintälaitteiden kehittämisessä vaadittavaan jäljitettävyyteen. Meillä on oltava vaatimustenhallinta-, riskinhallinta-, muutoksenhallinta-, versionhallinta- ja testauskäytännöt, joiden tuotokset on linkitettävä toisiinsa standardien ja viranomaisvaatimusten mukaisesti. Tärkeimmät jäljitettävyystyökalumme ovat DOORS, ClearQuest ja Subversion.

Kuvittelin tässä aiheessa olevan enemmän pureskeltavaa, mutta oikeastaan Scrum ei ole toistaiseksi muuttanut jäljitettävyysketjujamme miksikään, vaan vain tuonut niiden hallintaan uutta selkeyttä: vaatimuksia on päivitettävä sprintin tehtävälistan mukaan, ja ketjujen on oltava kunnossa joka sprintissä. Scrumin teemat ja käyttäjätarinatkin mäppäytyivät aika mukavasti vanhan muutostietokantamme kaksitasoiseen rakenteeseen.

Isoin haaste puhtaalle iteratiivisuudelle tuntuu olevan lääkintälaitealan mallien mukainen lopullisen tuotteen testaus. Sprinttien aikana testaamme tietenkin kaikki muutokset, mutta hankkeissamme on käytännössä pakko olla erillinen julkaisusprintti, jonka aikana periaatteessa julkaisuvalmis tuote käy vielä läpi kattavan regressiotestauksen. Onkohan kukaan lukijoistani (sikäli kuin teitä on :) löytänyt tähän kevyitä ratkaisuja? Testauksen automatisointi voi tietysti keventää taakkaa, mutta kaikkea emme pysty automatisoimaan.

3 kommenttia:

  1. Moi,

    Mielenkiintoiselta kuulostaa Scrumin virittely lääketieteellisiin sulautettuihin järjestelmiin..

    Päätit blogautuksesi mietteisiin lopputestauksen (hyväksymistestauksen?) hankaluudesta.

    Jostain kumman syystä olen nyt itse päätynyt Robot Framework -nimisen Open Source testiautomaatiotyökalun core-kehitystiimiin :) ja nämä hyväksymistestausjutut ovat hyvin pitkälti pyörineet tässä mukana.

    Jotain osviittaa meidän lähestymistavastamme hyväksymistestauslähtöinenkehitys (Acceptance Test Driven Development - ATDD) saa Gojkon kirjoista ( Specification By Example http://www.specificationbyexample.com/ ja Bridging the Communication Gap http://www.acceptancetesting.info/the-book/ ).

    Perusajatus on esittää vaatimuksien sijaan / ohessa konkreettisia esimerkkejä, jotka voidaan automatisoida kehityksen aikana. Näin ollen vaatimus linkitetään näiden automatisoitujen testien avulla rakennettavaan tuotteeseen. Ja toisaalta se myös konkretisoidaan kaikille samanlailla ymmärrettäväksi kyseisen esimerkin avulla.

    Lähestymistavan tehokkuus perustuu käytännössä kahteen ajatukseen:
    1) Esimerkki tuo esille mahdolliset yllätykset ennen kuin uutta ominaisuutta ruvetaan sprintin aikana koodaamaan -- säästää tekemästä vääriä asioita
    2) Esimerkin automatisointi linkittää dokumentaation ja tuotteen siten, että nämä eivät pääse eroamaan toisistaan -- dokumentaatio ei vanhene tai unohdu vaikka henkilöt unohtaisivat tai vaihtuisivat

    VastaaPoista
  2. Emme ole tosiaan vielä muuttaneet perinteistä vaatimustenhallintaamme, vaan Product Backlog toimii vaatimusten lähteenä. Varmaan arvioimme uudestaan myös vaatimustenhallintaa, kunhan kerkiämme...

    Viranomaisilla on odotuksena se, että valmis tuote käy läpi kattavan järjestelmätestauksen eikä sitä enää sen jälkeen muuteta (lukuun ottamatta mahdollisia bugikorjauksia). Tästä näkökulmasta sprinttien aikainen testaus on luonteeltaan vain täydentävää eikä yksinään riittävää.

    VastaaPoista
  3. Omasta mielestäni testauksen varsinainen arvo tulee sen vaikutuksista ohjelmistokehityksen ohjauksessa oikeiden asioiden ratkaisemiseen.

    Tämän takia pitkälle viety testiautomaatio on mielestäni se tapa, jolla regressiotestaus ja viimeisenä (paitsi tietenkään ei viimeisenä, koska tulee uusia versioita kuitenkin) hyväksymistestaus tulisi hoitaa.

    Mikäli hyväksymistestiä ei pystytä kokonaan oikeata järjestelmää vasten automatisoida, voisi sen silti pyrkiä automatisoimaan vasten järjestelmää, jossa osa oikeista komponenteista on korvattu simulaattoreilla. - Näin hyväksymistestin saa lopullisen näköisenä osaksi automaattisia regressiotestejä.

    Sitten kun viimein järjestelmän lopullinen hyväksymistestaus suoritetaan, pystytään tuo kyseinen testi suorittamaan vaikka manuaalisesti oikeata järjestelmää vasten. - Näin ollen hyväksymistesti pysyy kokoajan suoritettavassa kunnossa (mikä mielestäni on yksi ongelmista, jos testi on suunniteltu kauan ennen kuin sitä oikeasti ruvetaan/pystytään suorittamaan) ja järjestelmä ainakin suurelta osin sellaisena, että testi on aina läpäistävissä.

    Lukisin mielelläni lisää Scrum-transformaatiostanne, joten toivottavasti blogauttelet vielä aiheesta!

    VastaaPoista