Onko buginen järjestelmä IT-toimittajalle tosiaan rahasampo?

Pääsin eilen juttelemaan puhelimessa Tietoviikon toimittajan kanssa, joka varsin ilahduttavasti poimikin kommenttejani artikkeliinsa:
http://www.tietoviikko.fi/cio/buginen+jarjestelma+on+ittoimittajalle+rahasampo/a831331

Suoranaisista asiavirheistä en suinkaan valita, mutta muutama asia keskustelussamme oli jäänyt vähän erilaiseen lopputulemaan:
1. En suosittelisi "kolmatta osapuolta" tarkoittaen testaukseen erikoistunut firma
2. Suosittelisin sopimusvaiheessa nk. relational contract -mallia, jossa muodostetaan yhteinen rahasumma toimittajan bonuksesta, muutospyyntö ja virherahasta, ei vain virheistä

Halusin kuitenkin hieman pidemmin kirjoittaa kokemuksistani IT-projektien ihmeellisessä maailmassa.

Nykyinen työni on nk. tuotekehitystä. Se tarkoittaa, että testaajana olen sen organisaation palveluksessa, josta löytyy suora asiakas sekä toimittaja samoilta palkkalistoilta. Toiselle testaamistani järjestelmistä on ulkoisia loppukäyttäjiä, joiden näkökulmaa ja sielunelämää sovelluksen käytössä koitan ymmärtää. Suurien käyttäjämäärien myötä lokeistakin näkee, että massa tosiaan tekee kaiken mitä suinkin vain sovelluksella voi tehdä, ei kulje sitä meidän suunnittelemaa polkua eikä meidän suunnittelemaan tahtiin. Toinen testaamistani järjestelmistä on sisäiseen käyttöön, jolloin samalta palkkalistalta löytyvät vielä kaikki käyttäjätkin. Palaute käytävillä on raakaa ja välitöntä, ja kolleegaa halutaan auttaa erityisen vahvasti kun jokaisella käyttäjällä on kasvot.

Aloitin nykyisessä työssäni vasta huhtikuun alusta. Ensin mainitsemani järjestelmä on ollut tuotannossa jo ennen kuin minä työni tiimieni ensimmäisenä ja ainoana testaajana aloitin. Olisi minun silmilläni loukkaavaa väittää, ettei sovellusta ole ennen testattu. Kuitenkin tulokset tekemästäni testauksesta puhuvat täydennyksistä, näkökulmista joita ei testaukseen ole ajallisesti mahtunut ennen lisäpanostusta, tai jota ei ole osattu niillä voimavaroilla tehdä joita tiimin käytössä ennen minun mukaantuloani oli.

Arkipäiviini kuuluu ongelmien löytämistä - bugeja, niinkuin ammattikielellä sanotaan. Bugi on mitä tahansa mikä käyttäjää ärsyttää, haittaa, estää tai hidastaa. Bugit voivat olla puuttuvia keskeisiä toiminnallisuuksia. Ne voivat olla koodivirheitä. Ne voivat olla virheitä siinä miten meidän koodi ja muilta hankkimamme koodi yrittävät ratkoa yhdessä käyttötilannetta. Ne voivat olla virheitä siinä miten käyttäjä ohjelmaa tulkitsee käyttävänsä, missä järjestyksessä tai kuinka nopeasti. Olemme ihastuttavan yksimielisiä tiimini toteuttajien ja projektipäällikön kanssa siitä että olisi ajan tuhlausta jäädä pohtimaan koska bugi on syntynyt (onko se jo nyt asiakkaiden riesana tuotannossa), onko bugi virhe vai muutospyyntö jos samalla rajallisella ajalla sen korjaamme, tai onko kukaan osannut juuri oikeaan aikaan oppia ja tajuta että tämäkin asia oikeasti haittaa käyttäjiä merkittävästi. Tosiasia kuitenkin on, että jos emme saa ongelmasta käsitystä  jonka pohjalta myös toteuttaja ihan käytännön tasolla ymmärtää mikä ei toimi ja millä tapaa, korjaus vähintään menee jollain tapaa metsään. Ja testaajana tuotan lisäarvoa tiimissäni auttaen kehittäjäkolleegoitani löytämään virheitä ajoissa, ennen kuin sekin asiakassekmentti ilmaantuu jolle tämä asia on maailman pysäyttävä, ennen kuin meidän uutta asiaa tarvitsee ensi kertaa käyttäjille näyttää tai ennen kuin löytyy se asiakas, jolla tämä ongelma ylittää ärsyyntymiskynnyksen tuotteen laadun kanssa.

Elämä tuotekehityksessä ei ole helppoa, kun meillä kaikilla on yhtälailla haasteena ajan rajallisuus ja toiveiden monimuotoisuus, ja yritys ymmärtää sitä käyttäjien massaa ja monipuolisuutta sekä usein arvattuja tarpeita. Mutta verraten siihen mitä tein aiemmin, elämä on suorastaan ruusuilla tanssimista.

Olin välissä nelisen vuoden jakson koittamassa ymmärtää asiakas-toimittaja -projekteja ja niihin liittyvää testausta. Tein keikkaa toimittajaorganisaatioiden projekteissa, kunnes siirryin päivätöihin asiakasorganisaatioon tukemaan hyväksymistestausta sekä toimittajilta tilattavan testauksen määrittelyä. Näissä projekteissa on kummallisia ilmiöitä, joista todella monia tunnistan varsin kärjistetysti kirjoitetussa artikkelissa http://ohjelmistotestaus.fi/2012/08/tarinoita-it-hankkeiden-ihmemaasta/.

• Paljon aikaa ja energiaa menee 'hukkaan' kun  asiakas- ja toimittajaorganisaatio kilpaa todistelevat että ehdottomasti korjattava ongelma on virhe eikä muutospyyntö. Virheet sopimusteknisesti kuuluvat usein toimittajan vastuulle, kun taas muutospyynnöt asiakas maksaa erillisestä rahapussista. Tuntuu varsin uskomattomalta, että voidaan rakentaa tilauksesta eläkkeen laskentajärjestelmä, joka ei osaa laskea eläkettä, mutta toimii "määrittelyjensä mukaan". Toimivuudesta tarkoitukseensa maksetaan erikseen, koska vastuu asiantuntijuudesta on sovittu asiakasorganisaatiolle eikä siitä ole siis toimittajalle maksettukaan. Myös riskin otto nostaa projektin hintalappua. 
• Asiakkaan testausvaihe, "hyväksymistestaus", on usein ensimmäinen tuloksellinen testaus ja tapahtuu hyväksymisnäkökulman vuoksi jo alkuperäisessä viivästymisten vuoksi tiukennetusta aikataulusta irrallaankin liian lyhyessä aikavälissä liian pitkän heikkolaatuisen palautteen jälkeen. Hyväksymistestauksen pitäisi olla testaus-, ei korjausvaihe. Jotta tämä olisi mahdollista, on oltava samanlaatuista ja sisältöistä testausta, tai laajempaakin, aikataulussa ennen tätä. Jos aiempien testausvaiheiden sisältöä vielä rytmittää edellisessä pointissani mainitsemani määrittelyjen ylipalvonta, huomaamme lopuksi ennen lakimuutoksen pakottamaa tuotantoonsiirtopäivämäärää, ettei koko järjestelmä tee mitä sen tarvitsee, vaikka tekeekin mitä on määritelty. Ohjelmistokehityksessä monet asiat konkretisoituvat vasta kun järjestelmää pääsee käyttämään - testaamaan. 
• Vaikka virheet kuuluvat ehkä sopimuksen mukaan perushintaan, sopimukset harvoin huomioivat että testaaminen tavalla jolla virheet raportoidaan selkeästi ja korjaukset mahdollistavasti, ei välttämättä kuulukaan. Testauksen vaatiminen / tilaaminen on taitolaji. On täysi myytti, että testaamaton tarkoittaisi toimimatonta. On todistettavasti järjestelmiä, joilla ei ole erillisiä testaajia, joiden laatu on näitä "ammattitestaajien" testaamia parempi - yleensä taustalta löytyy ammattiylpeyttä ja yrittäjähenkeä. Testaus - kenen tahansa aikaa ja osaamista käyttävän toimesta - kuitenkin opettaa yllättävistä reunaehdoista, joista kaikkia ei parhaimpiinkaan suunnitelmiin saada mukaan. Ei siis riitä, että vaaditaan toimittajaa testaamaan. Pitää pystyä kertomaan ja sopimaan mitä ja miten, ja missä laajuudessa ja laadussa. Testausta se on huonolaatuinenkin testaus, ja jotkut kutsuvat sitäkin testaukseksi että painelee samoja nappeja käsin samassa järjestyksessä kymmeniä kertoja ilmaan mitään perustetta epäillä että juuri tätä asiaa nyt tarvitsisi tarkkailla. Samalla ajankäytöllä voisi tehdä edes pieniä muutoksia tekemiseensä, ja sitä kautta merkittävästi lisätä tehdyn testauksen laatua. Lisäksi todella monet asiakkaat tietoisesti ja tarkoituksella tilaavat projektinsa ilman testausta laskien hintalappua tyypillisesti 20-30 %. Tällöin sovitaan että asiakas hoitaa testauksen ja "hyväksymistestaukseen" kuuluukin yllättäen mahdollisesti täysin toimimattomalla ja aiemmin tarkastelemattomalla ohjelmistokokonaisuudella testaaminen. 
• Hintakilpailu toimittajien välillä tuo erikoisia sivuilmiöitä. Tarjouksista on todella vaikeaa saada vertailukelpoiset sisältyvältä laajuudeltaan, ja toimittajat omien malliensa nimissä tarjoavat selkeästi alihintaan projekteja, joissa varsinainen lypsylehmä on virheiden ja muutosten toteutus ensitoimituksen jälkeen. Ensitoimituksen kokoa projektin kuluessa aktiivisesti minimoidaan tiedostaen, että seuraavan täydentävän toimituksen kanssa on haastavaa siirtää kehitystä seuraavalle, ja vaikka tuntihintaa ei ehkä voi ylös hilatakaan (moni asiakas pyytää tarjouksessaan alkuun jo sitovat ylläpitohinnatkin), mikään ei aseta rajoja sille kuinka monta tuntia asian tekemiseen toimittajaorganisaatiossa menee. Ja tuntimäärää saadaan helposti nostettua, kun on erikseen henkilö joka juttelee asiakkaan kanssa (vaatimukset), joka keksii miten asiakkaan tarve ratkaistaan (määrittelyt), joka miettii tekniset rakenteet ratkaisuille (arkkitehtuuri), joka mietii mitä osia koodista viime kädessä muutetaan (tekninen suunnittelu), joka toteuttaa muutokset (koodaaja), joka testaa teknisesti (integraatiotestaaja), joka testaa osana järjestelmää (järjestelmätestaaja) ja joka juttelee aikatauluista asiakkaan kanssa (projektipäällikkö). Ja jos tehdään isompia asioita, joka ryhmällähän pitää tietysti olla vielä erillinen vetäjä. Välillä tulee mielikuva että ei voi ajatellakaan, että yksi kaveri tekisi näitä kaikkia, sehän laskisi laskutettujen tuntien määrää.
• Pelon ja epäluottamuksen ilmapiiri maksaa asiakkaalle moninkertaisesti. Ei suinkaan kelpaa, että toimittajaorganisaatio valvoisi itse omaa tekemistään ja esimerkiksi vastaisi siitä, että toimitukseen sisältyy tulevaa tukeva testiautomaatio (sen ohittamisella ensiprojektissa saadaan muuten upea määrä ylläpitotunteja laskutettavaksi!) vaan kyllä tilaajan pitää ehdottomasti laittaa omat edustajansa asialle vahtimaan. Ja testausfirmat vielä propagandamaisesti mielellään nostavat ammattimaisen edunvalvojan näkökulman esiin. Tehdessäni töitä testausfirmalle testauskonsulttina silloinen myyntiorganisaatio myi edelliselle työnantajalleni useita kavereita täysipäiväisesti tekemään testiautomaatiota hyväksymistestauksen tueksi. Testiautomaatio ei koskaan tuottanut muuta kuin lämpimän tunteen, sen ylläpitäminen maksoi maltaita sillä se hajosi jatkuvasti. Se ei myöskään elänyt kovin kauaa. Ja tässä asiakasorganisaatiossa työtä tehneenä tiedän melkoisen varmasti, että suurin tekijä epäonnistumiselle on etäisyys. Samasta asiasta samalla rahalla samalle toimittajalle kuin joka teki hyväksyttävää järjestelmää olisi saanut merkittävästi enemmän onnistumisen eväitä. En todellakaan ymmärrä että miksi pitäisi maksaa kahdesta "samansisältöisestä" testauskerroksesta vain epäluottamuksen nimissä. Luottamusta voi rakentaa ja sitä tukevia rakenteita tuoda sopimuksiin. Viime kädessä kahdenkin organisaation välisissä projekteissa ihmiset ja yhteistyö ovat ne avainsanat. Organisaatioiden etäisyys vain vaatii sopimusta tueksi tiukkoihin tilanteisiin, joissa liiketoimintojen reunaehdot eivät ehkä olekaan synkassa.
• Ulkoiset testausorganisaatiot usein pahentavat tilannetta. Jos kahdella organisaatiolla on jo erilaisia tavoitteita, kolmas testaukseen keskittyvä organisaatio ei välttämättä mitenkään helpota tilannetta. Kun testaajalle maksetaan testaustuloksista ja järjestelmätoimittaja menettää rahaa korjatessaan ilman lisämaksua ja molemmat toimittajat koittavat optimoida itselleen mahdollisimman suuren ja merkittävän osuuden kokonaisuudesta, saadaan aikaan lähinnä kaaosta ja taistelua.

Pitkän vuodatuksen jälkeen haluan vielä kertoa, että olen kokenut myös jotain hyvää. Edellisen työnantajani palveluksessa yhdessä projektissa (ehdin tehdä 2,5 vuoteen viittä projektia tuotantoon saakka) teimme erittäin ammattimaisen 30 päivän hyväksymistestauksen ja teimme kaikkemme löytääksemme virheitä ja muutospyyntöjä. Emme onnistuneet. Järjestelmä meni tuotantoon edellä aikataulustaan ja alle sovitun budjettinsa. Avain onnistumiseen, väittäisin, oli erinomainen yhteistyö asiakkaan eri roolien sekä toimittajan eri roolien välillä. Testauksen yhteisissä viikkopalavereissa käytettiin 30 minuuttia viikossa erittäin avoimeen vuorovaikutukseen ja pieleen menevien asioiden veikkailuun, joilla asiakkaan tukemana toimittajan toteuttajat tekivät erinomaisen järjestelmämuutoksen, toimittajan testaajat testasivat ja korjauttivat rajoitteet suhteessa tarpeeseen ja viestivät erinomaisesti toteuttajien kanssa teknisellä tasolla. Taustalla onnistumisessa oli mielestäni puitteet: projekti myytiin meille hinnalla, joka ei ollut toimittajalle kuristuspanta. Rinnakkaisprojekti, joka oli laajuudeltaan karkeasti kaksinkertainen myytiin 2/3 tämän onnistuneen projektin hinnasta. Tarinasta lienee selvää, että tämä alihinnoiteltu projekti oli molemmin puolin paljon työllistävämpi ja työilmapiiri ei koskaan saavuttanut samaa hyvää tasoa. Testaustaidoissa ja neuvottelutaidoissa oli toimittajaorganisaation nimetyissä henkilöissä myös suuri ero.

Buginen järjestelmä voi olla toimittajalle rahasampo, ja minun silmiini monet suurien toimittajien menetelmistöistä optimoivat tätä. Mutta vikaa on myös asiakkaissa. Mitä jos asiakkaat tyytyisivät time-and-material -sopimukseen, siihen että riskiä ei lopulta voikaan siirtää ilman merkittävää omaa lisäkustannusta toimittajalle ja laittaisivat tarkistuspisteitä kalenteriin useammin. Ja se ei silti estä sopimasta tavoitehintaa ja palkkio/riskisummaa, jolla projektin joustot hoidetaan. Niin, kuulostaa uhkaavasti suositukselta ketterien menetelmien suuntaan - etenkin yhdistettynä tuohon roolipohjaisen siiloutumisen naurettavuuteen jossa kahden töihin tarvitaan kymmenen spesialistia välttelemään vastuita.

Joulukalenteritestausta muuttuvassa ympäristössä

Intouduin tänään testitapauksia kouluttaessani uuteen vertauskuvaan selittäessäni testauksen haasteita ja dynamiikkaa. Joulunajan uhkaavasti lähestyessä meidän perheessä on alettu kovasti himoitsemaan joulukalenteria hyvissä ajoin. Kokemus taas muistuttaa, että meidän perheessä on pahoja tapoja muuttaa hyvissä ajoin hankitun suklaajoulukalenterin tarkoitettua tilaa niin että jotenkin kummasti osasta luukkuja katoaa se suklaapala, luukku sulkeutuu mahdollisimman huomiota herättämättömästi ja pettymys kadonneesta suklaasta iskee sitten joinain joulukuun päivinä.

Tälläisen kevyesti rosmotun suklaakalenterin tilanteen selvittelyssä on paljon yhtymäkohtia testaukseen. Minua oikeastaan kiinnostaisi osua vain niihin luukkuihin joista suklaa on kadonnut, mutta kun sitä ei ulkopuolelle huomaa. Kun luukkuja on katettavaksi vain 24, kaikkien avaaminen on tietysti mahdollista. Asiaa kuitenkin voisi lähestyä myös riskipohjaisesti, koittaen tunnistaa vääntyneitä kulmia tai helposti avattavia luukkuja.

Kun luukkuja availee, luukun avaaminen vie sen oman lyhyen aikansa. Kun luukunavaustesti onnistuu löytämään bugin, setvimiseen liittyvät toimet vievät merkittävästi enempi. Korjauksen jälkeen pitää vielä vahdata että korjaus on toiminut ja pysyy toimineena - tilanne kun meidän kalentereissa on varsin dynaaminen.

Jos testauksessa varaa aikaa 24 * avaamisaika, taustaolettama on ettei setvittävää löydy tai toistotarvetta ole. Kuitenkin bugeja etsiessä testausbudjettiin on laskettava virheen raportointiaika (että muutkin tietää mistä se suklaa puuttui) ja uudelleentestaus virheen korjauksen jälkeen. Jos kaikki palat olisivat kadoksissa - näin pahaa tilannetta ei vielä ole tullut vastaan - testaus veisi 48 avaamisaikayksikköä ja 24 raportointiaikayksikköä.

Kun kattavuus näin yksiulotteisesti voidaan kuvata, elämä on vielä testausta paljon helpompaa. Niin että testaukseen verratessa voisi sitten vielä ajatella että kyseessä on monikerroksinen kalenteri, jossa suklaapala voi olla kadoksissa mistä vaan suunnalta, ja että aika kaikkien luukkujen avaamiseen ei vain riitä, joten jollain riskipohjaisella periaatteella asiaa voi haarukoida.

Poimimani opit IIR:n Testing Forumista

Jaoin erilaisten pienten porukoiden kanssa sähköpostilla poimintojani ja tulkintojani IIR:n Testing Forum -seminaarista viime viikolta. Pitkät piuhat, tajusin julkisissa liikennevälineissä ikkunasta tuijotellessani (luovia hetkiä...) että voisi sen tietysti ilman enempää selitystä jakaa näinkin.

Samat saatesanat kuin muillekin joille sen pienessä piirissä laitoin: saa kysyä että mitä ihmettä jollain tarkotan. Tulkintavirheet ovat omiani, saatan kuulla mitä sattuu kun sille päälle satun.

Pirkko Lankinen, TeliaSonera: Best in Class IT
- laitettu laatumenetelmistöä järjestykseen merkittävällä investoinnilla, erityisesti roolimäärittelyjä ja incident/problem/change management –rajapintoja.
- Accenture ollut arvioimassa kypsyyttä, mielenkiintoinen lähinnä esitetty vertailu jossa Banking & Finance –sektori oli varsin heikko organisaatiolleen tarjoaman tuen kypsyydessä
- merkittävänä motivaattorina kaukoulkoistus, josta saatu kustannussäästöjä

Vasco Duarte, Nokia: How Testing Can Revolutionize our R&D organizations?
- Hauskasti tuotu esiin suomen ja kiinan kustannusero: 9.4 kertaa kalliimpaa suomessa
- Tarvittava tuottavuusparannus (10x) mahdollinen paradigmamuutoksella --> ketterät menetelmät vaikkei sanaa kertaakaan mainittu esityksessä
- Havainnollisti hienosti hiljaisen tiedon siirtämisen tärkeyttä ohjelmistoprojekteissa - ”handover loses implicit knowledge”
- Perusteli ensimmäisen puhujan kumoon sanomatta sitä suoraan: roolipohjaisuus luo handovereita, kun jokainen hoitaa omaa tonttiaan.
- Testaus ei ole sama kuin tarkastaminen. Testaus tuottaa myös uutta tietoa, vaatimuksia.
- Määrittely ei ole tulos (output), se on muistin tuki (refresher)

Jani Haapio, NSN: Miten karsia turha testaus pois, ja löytää testauksen ydinkohdat?
- Siirrytty 1,5 vuotta sitten ketteriin menetelmiin, suuria muutoksia testauksen organisoinnille
- Lyhennetty, aikarajattu kokonaisuuden testaus pakottanut priorisointikäytäntöihin joita olisi tarvittu ennenkin. Priorisointi 3 kk välein yhdessä asiakkaan kanssa.
- 3000 toimintotestiä, 200 järjestelmätestiä. Priorisointi testitapauksille ja painotukset laatukriteereille.
- Tutkiva testitapaussuunnittelu: testit syntyvät lopuksi tulevalle muistin tueksi, motivaationa erityisesti työn siirtely useiden paikkakuntien/maiden välillä ja vastuu tukemisesta siirron jälkeen jos ei dokumentointia riittävästi. ”Kysymyksiä vanhasta työstä ei budjetoida”
- Valmiin määritelmälle Intian kehitystiimien kanssa vaadittu että dokumentaatio on sovitussa paikassa, helposti unohtunut levynkulmalle josta ei löydy pyydettäessä

Jouni Koivuneva, VR-yhtymä: Miten laadunvarmistus toimii, kun mukana on useita rajapintoja ja toimittajia
- Case, jossa kiinnitettynä lyhyt aikataulu suhteessa muutosten laajuuteen. Muutokset websivujen ulkoasuun: kuvat, värit, fontit, ei sisältömuutoksia.
- Oppeina tiukat rajaukset mitä ei saa tehdä ja yksilön sankarillinen suoritus
- Huvittavia tarinoita: Toimittajan suuresta työmäärästä katosi merkittävä osuus haastamalla että itse tekee jonkin osan. Puhujalla ajatus siitä että toimittajalla työmäärät määräytyvät asiakkaan maksukyvyn, eikä tehtävän työn perusteella
- Keskeisin oppi: aikataulua pitää laskea lopusta päin ja karsia laajuutta ajoissa.

Erkki Pöyhönen, Tieto: Hyväksymistestauksen haasteita
- Erilaisia organisointitapoja, joskus toimittaja hoitaa hyväksymistestauksen, joskus asiakas testaa toimittajan testitapauksilla.
- Keskusteltiin kovasti toimittajien etiikasta jos ei ohjaa asiakasta oikeaan ja tarkoituksenmukaiseen suuntaan

Tuula Pääkkönen, Nokia: Pohdintoja testaajan ammattitaidon kehittämisestä ja testausverkostoista
- Testaukseen päädytään monenlaisesta suunnasta, ja kasvutarpeet ovat yhtä moninaisia
- Sertifiointimalleja on paljon. Koulutustakin on saatavilla yhä enemmän, jopa osana perustutkintoja.

Olli-Pekka Puolitaival, VTT: Mallipohjainen testaus
- Piirretään kuvia siitä miten ohjelmistoa käytetään, ja luodaan automaattisesti testitapaukset, vältetään testien kirjoittaminen yksityiskohtaisesti
- Ylläpidon etuja korostettiin: mallin muuttaminen helpompaa kuin skriptien

Mika Katara, TTY: Älypuhelinsovellusten mallipohjainen käyttöliittymätestaus
- Testattu useita markkinoilla olevia puhelinsovelluksia, joista löydetty merkittäviä virheitä määrällisesti ja sisällöllisesti – testaus käyttöliittymän kautta
- Yhdistetty loki kameralla otettuun kuvaan tekstityksellä: pitkien ketjujen analysointi vaatii tukea joka ei pakota suorittamaan testiä uudelleen
- Löytää erityisesti toiminnallisuuksien rinnakkaisuuden ongelmia pitkäkestoisessa käytössä (luotettavuustestaus)
- Työkalusetti avoimen lähdekoodin tarttumattomalla lisenssillä saatavilla, hakevat myös yrityskumppaneita
- Omia pohdintoja:
o mallinnuksessa jatkokäytön arvon oltava hidastumista suurempi
--> dokumentointi, todisteet – tarvitaanko oikeasti?
--> bugien toistaminen
--> uudet virheet (pitkäkestoinen käyttö, rinnakkaisuus)
o mallinnuksen vaatima analysointi vaikuttaa eri tavalla eri ihmisiin
--> fokuksen supistuminen
--> kurinalaisuuden lisääntyminen, tavoitteellisuus
--> tekniikkaan ”hukkuminen”, ongelmat työkalujen kanssa

Tero Vuorenmaa, Softability & Matti Antila, Microsoft: Testaus ja laadunvarmistus osana tuotteen elinkaaren hallintaa Visual Studio ja Team Foundation Server –ratkaisussa
- Microsoftilla on nyt myös testaajan työkalut, vastaavat kuin Quality Center
- Elinkaaren hallinta tarkoittaa sitä että muistetaan että ensimmäinen projekti on vasta alku järjestelmän olemassaololle, kustannuksista suuri osa nk. ylläpitovaiheessa

Elina Partanen, Aktia: Tietoturvan huomioiminen verkkopalveluiden testausvaiheissa
- Hyödynnetty eri rooleja tietoturvatestaamiseen oman organisaation rajallisuus huomioiden: testaajat huomioivat toiminnallisuutta, toteuttajat rakentavat ja testaavat sovituin pelisäännöin tietoturvaa osana yksikkötestejä, ammattimainen tietoturva-auditointi kerran vuodessa
- haasteena ollut erityisesti ylläpito ja pienkehitys, joissa helposti unohtunut perushyökkäysten huomiointi
- Tykästyneet Burbsuiteen, pitäisi varmaan joskus huvikseen vilkuilla
- Vaadittua toimintaa tuetaan ohjein ja koulutuksin: asiakas tilaa toimittajan jokaisen kehittäjän kustannuksellaan koulutukseen ja maksaa koulutustunneista (4 h / hlö)

Blogin kirjoituksen haasteista

Kirjoitteluni aiheet tuntuvat pyörivän erilaisten kriisinpoikasten ympärillä... Tällä kertaa inspiraationa aiempaan kirjoitelmaani tullut kommentti siitä että eikös blogeja enää lueta ja kommentoida.

Keräsin alkuvuodesta listan suomenkielisiä testausblogeja. Olen säännöllisen epäsäännöllisesti surffailut näitä läpi, ja huomannut että enimmäksen trendi tuntuu olevan että alkuun jaksetaan ja sitten kadotaan. Toki löytyy ajatonta tekstiä, josta voisi jatkaa keskustelua vaikka kuinka pitkään alustuksen tai aloituksen jälkeen. Toisaalta taas asioista jotenkin ajattelee keskusteltavan tuoreeltaan.

Huvittavaa sinänsä, mutta minun bloggaamisestani hävisi sekin vähä energia ja aika kun ensin kirjoittelin hetken testausOSYn linkedin-palstalla ja sitten hurahdin kevyesti twitteriin. Tosiasia kuitenkin on että ajan ollessa rajallinen luonnonvara 160 merkkiä testauksesta päivässä on aika paljon helpompaa kuin oikeasti jonkin tarinan kirjoittaminen.

Lisäksi olisi yksinkertaisesti helpompaa, jos useampi kirjoittaisi samaan blogiin, niin ei tarttisi surffailla ihan niin moneen suuntaan.

Pienenä huvittavana yksityiskohtana: minulla on parikymmentä aloitettua blogijuttua, joita en ole suoriutunut kirjoittamaan otsikkoa ja paria riviä pidemmälle... Joskus vielä - ihan kohta. Mutta ensin, vielä muutama hyvä tiivistelmä testisuunnittelun erityispiirteistä uudelle lempitestaussektorilleni.

Testauspäällikkökriisi

Huomaan toistuvasti palaavani pienen turhautumisen tunteen kanssa nykyiseen titteliini: "testauspäällikkö". Kirjoittelin aiemmin siitä kuinka kierolta tuntuu, että testaajasta tulee testauspäällikkö ja toteuttajasta arkkitehti. Edelleen päällikkyys tuntuu tarpeettomalta ja väärään suuntaan ohjaavalta.

Muistan lukeneeni jotain trendilistaa lempiguruiltani, jossa yhtenä trendinä mainittiin että projektinhallinta ja testauksenhallinta yhdistyvät tulevaisuudessa. Testaus jää erikseen, eriytyy, ehkä jopa löytää paikkansa - näin ainakin itse ajattelen.

Testauspäällikkönä minun odotetaan - ulkopuolelta - olevan hallinnollisesti suuntautunut. Minun odotetaan suunnittelevan, ohjaavan, tuottavan mittareita. Ja joku muu onnekas saa tehdä lempityötäni, testausta. Voin mentoroida, opastaa, valmentaa ja kannustaa. Rohkaista ja antaa vinkkejä. Voin vähän tehdä itsekin, mutta odotukset ovat vahvasti muualla.

Sanojen ei pitäisi sitoa, eikä vaivata. Koen silti että jopa aivan samalla työkuvalla, olisin aina mieluummin "testausasiantuntija" kuin päällikkö.

Minun kolleegani, projektipäälliköt tiimissäni, ovat loistavia. Selviäisivät testausasioista siinä kuin mistä tahansa muustakin. Jostain syystä testauspäällikön olemassa olo vaikuttaa enemmän jopa itsetuntoa alentavasti, kun eivät sitten ihan samalla tasolla osaa jokaista detaljia testauksesta.

Odotan innolla ensi viikkoa - saan kolleegan, jolta odotan tukea pohdinnassa tulevasta testauspäällikköroolista.

Kuilu vaatimusten ja toimivan välillä

Vietin taas pari päivää opastaen mukavaa porukkaa testitapausten suunnittelussa. Tästä porukasta ja keskusteluista minulle jäi erityisesti pohdittavaksi, että kuinka yleistä lopulta on, että vaatimukset rajaavat testausta kohtuuttomalla tavalla.

Cem Kanerin materiaaleja muistinvaraisesti lainaten, vaatimukset ovat fiktiota. Parhaimmillaan ne ovat käyttökelpoisia, hyödyllisiä, avuksi.

Jäin pohtimaan, että onko tämä yksi niitä keskeisiä eroja tuoteliiketoiminnan ja projektiliiketoiminnan välillä. Suppealla otoksella kummastakin ei tietysti halua vetää liian pitkälle meneviä johtopäätöksiä, mutta tuntuma on, että projektien tilaamisessa ja toimittamisessa on jotain, joka ohjaa tarpeettomassa määrin siihen, että asiakkaan tarpeita ei koiteta täyttää, vaan vain asioita joita on "vaadittu". Testaajaa jopa kielletään testaamasta mitään muuta kuin vaatimuksissa mainittuja asioita. Muita asioita testataan sitten kun tämän toimituksen osalta ollaan turvassa (aikataulussa / luvatussa laajuudessa), ja asiakas tajuaa että ei saanutkaan täytettyä tarvettaan, mutta vielä uskoo siihen että oma vikahan se toki oli kun ei osannut vaatia.

Jokseenkin hahmotan, että tokihan jokaisesta tunnista pitää saada laskuttaa. Mitta sitä en hahmota, että voidaanko ihan vakavissaan lähteä siitä, että tehtäisiin projekti, joka täyttää vaatimukset ilman väliä siitä millaista tarvetta vaatimukset olivat kuvaavinaan. Kai se on sinänsä luonnollinen vastareaktio muodissa oleville kiinteähintaisille toimituksille.

Viksumman testaamisen hidasteita asiakas-toimittajamaailmassa

Olen viime aikoina miettinyt varsin paljon taas tutkivaa testausta, asiakas-toimittajaprojektien näkökulmasta. Matkalla voi olla muutamia hidasteita:

- suunnittelun ja testaamisen erilainen hinnoittelu. Jos sattuu olemaan tilanne, jossa testaustyötä hinnoitellaan eri lailla riippuen sen vaativuudesta ja on luokiteltu, että suunnittelu on vaativaa ja testaaminen ei, tiessä on kyllä pieni kuoppa. Osittain tämä luokittelu kerjää sitä että tehtävät annetaan eri henkilöille, osittain sitä että valmistaudutaan mahdollisimman paljon, jopa yli sen hyödyllisen ja oikeasti tarpeellisen. Erityisesti haasteelliseksi muodostuu se että haluaisin sen halvemmalla hinnalla tehtävän työn sisältävän merkittävässä määrin nk. kalliimman hinnan töitä. Oikeasti noissa tilanteissa kyllä sanotaan että 100 tuntia testaukseen liittyvää työtä olisi keskimäärin jotain kahden hinnan väliltä.

- vaatimukset. Elisabeth Hendricksonilla oli jossain esityksessään oivaltava kommentti siitä, että lähes jokainen bugi on lopulta - toteuttajansa näkökulmasta - muutos vaatimuksiin. Jos ei ole ajateltu yllättävää vuorovaikutusta käyttöliittymän kanssa, vääränlaista syötettä naapuriohjelmalta tai että joku voisi joskus käydä kahvilla kesken tekemisen ja ohjelma ei tässä tilanteessa toimi, onhan se jollain tapaa perusteltua sanoa, että pyydetään uusia asioita. Mitä tarkempaan vaatimusdetaljiin mennään - jopa pseudokoodaukseen - sitä sidotummaksi suhteessa vaatimuksiin muuttuvat myös testaajan kädet.

- suojautumistarve. Varsin monesti sopimukseen ja projektisuunnitelmiin on osattu kirjata, että testit toimitetaan ennakkoon, ja toimittaja varaa luonnollisesti itsekin aikaa varmistaakseen, että luovutuksen tai hyväksynnän testit läpäistään. Se on paljon helpompaa toimittajan näkökulmassa, jos kerrotaan mahdollisimman täsmällisesti mitä aiotaan kokeilla ja miten. Niinpä asiakkaita tulee helposti ohjattu pois tutkivasta testauksesta, enemmän ennakkoon kirjattuun tyyliin.

- ajoitukset. Kun jostain on sovittu hankinnan alkuun, tuntuu että muuttaminen on tuskallista. Prosesseja pitäisi kehittää projektien ulkopuolella, erillisissä projekteissa, etteivät sotkisi tämän suunnitelmia ja työmääriä. Ja kun testausta tupataan valmistelemaan vasta kun projektin puitteet muuten on sovittu, aika on harvoin suoraan oikea.

Hidasteita, ei esteitä. Taidan alkaa miettiä seuraavaksi hyväksymistestausprosessia, ja siihen rakenteita, jotka sallivat ja tukevat fiksua testaamista.