Tehtyäni takinkäännön - edelleen uskollisena testaukselle - ohjelmistotuoteliiketoiminnasta omiin räätälöitäviin tilaustyönä hankittaviin järjestelmiin, olen jäänyt monesti pohtimaan odotuksia kohtuulliselle testaukselle.
Päivän listani on asioita jotka ovat minusta kovin kohtuullisia, mutta jättävät silti miettimään:
- Testaaminen asiakasnäkökulmasta
Tuoteliiketoiminnassa oli selvää, että järjestelmätestausporukka epäonnistuu pahasti, jos hyvin tehdyt vaatimusmäärittelyt otetaan liian kirjaimellisesti, eikä edes koiteta merkittävässä määrin huomioida asiakkaan / käyttäjän hiljaisia vaatimuksia sekä kaikkea sitä teknistä nippelinappelitietoa, joka voi jäädä vaatimusten ja määrittelyjen väliin. Räätälöitävien järjestelmien peruselementti tuntuisi olevan "vaatimusmäärittely" joka kuvaa tilatun järjestelmän, jota tarkennetaan ja jonka rivien väliin jääneet yksityiskohdat ovat aina muutospyyntöjä. Ja eivät löydy toimittajan testauksissa. Niinpä asiakkaan testaajien ja toimittajan testaajien välillä on kuilu, joka korostuu kahdenlaisessa hyväksymistestauksessa: on aivan eri asia suorittaa sopimushyväksymistestausta kuin tuotantoonhyväksymistestausta - valitettavasti.
- Näkyvyys ja raportointi projektiin testauksen kautta
Tuoteliiketoiminnassa tuntui varsin selkeältä katsoa tehtävää testausta kokonaisuutena mittarein. Työmäärän kulumisen lisäksi kiinnosti testauksella saatu lisäarvo, niin kattavuuden kuin tulostenkin osalta. Räätälöityjen maailmassa en pidä itsestään selvänä että testauksesta saisi mitään muuta raporttia kuin että budjetoidut tunnit nyt tuli käytettyä. Aiemmassa elämässä tästä minulla onkin ollut tosi ikäviä kokemuksia, ja toivon että ne kokemukset eivät päätyisi värittämään tulevaisuutta toistuvin kaavoin.
- Mallipohjan täyttäminen ajatuksella
Kun testaussuunnitelmassa pitää miettiä mallipohjan ohjauksella jotain, sitä jotenkin ajattelisi ja kuvittelisi että viime kädessä sisällöllä on merkitystä. Muoto on tärkeä kun luetaan rutiininomaisesti toistuvia suunnitelmia ja halutaan katsoa vastaavat teemat vastaavassa järjestyksessä, mutta silloinkin hyvän ja heikon suunnitelman erottaa ajattelu ja asioiden huomioiminen eikä vaan vakioliturgian kirjaaminen.
- Riskienhallinta - testauksen edellytykset voivat olla projektin tuho
Tuoteliiketoiminnan jälkeen on vaikeaa myös nähdä syitä siihen että testauksen on arvostussyistä oltava oma organisaationosansa tai että testaus pitää ehdottomasti projektoida omana kokonaisuutenaan, että saadaan kertoa realistista tilannetta kokeilluista ja ei-toimivista asioista. Minua ei henkilökohtaisesti yhtään lohduta että olin oikeassa kun sanoin että testaus voi voi tapahtua kahdessa viikossa jos testausympäristö ei toimi, jos siinä vaiheessa projekti on myöhässä eikä ole tullut edes ehdotettua vaihtoehtoista jonkinasteista lisäkustannusta toipumissuunnitelmaksi niille keskeisimmille riskeille.
Listan viimeistä pidän jo vähän edistyneempänä kamana, mutta muita ihan peruskaurana. Saas nähdä miten mieli vielä muuttuu...
Ei kommentteja:
Lähetä kommentti
Huomaa: vain tämän blogin jäsen voi lisätä kommentin.