Tag: Suomi

Työ on hyödytöntä silloin kun kukaan ei tarvitse sen tuloksia. Joutavuuksien tekeminen haaskaa kallisarvoista aikaa ja lisäksi se harmittaa vietävästi. Siksi bugirapsan on parasta olla hyvä!

Tee työtä, jolla on tarkoitus

Tämä lausehan on erään tunnetun suomalaisen firman motto. Se kiteyttää erinomaisesti myös testaajan arkisen aherruksen. Testaustyön keskeisin tarkoitus on nimenomaan löytää virheitä. Erityisesti sellaisia virheitä, jotka läpipäästessään aiheuttavat sietämätöntä tuskastumista missä tahansa softan toimituksen vaiheessa. Kun testaaja raportoi virheitä, silloin työllä on konkreettisimmin tarkoitus. Mutta:

Olet mitä kirjoitat

James Bach kiteytti testaajan työn napakasti. Bugiraportithan ovat useimpien testaajien työn ensisijaisin tulos. Bugirapsat muovaavat lukijoiden asennetta testaajaa kohtaan. Ne voivat toimia myös testaajan maineen rakentajana. Toisaalta niiden kautta tulee myös helposti arvioitua testaajan ammattitaitoa.

Jos testaaja ei jaksa tai ei osaa panostaa riittävästi bugiraportin laatimiseen, silloin työn tarkoituskin heilahtaa harakoille!

Testaajan ensisijainen yleisö tietysti on devaajat. Vaikka esimiesasetelmaa ei ole, niin jokainen tehty bugiraportti on periaatteessa pyyntö devaajalle panostaa työaikaa bugin tutkimiseen ja mahdolliseen korjaamiseen. Huonosti ja huolimattomasti laadittu virheraportti ei kerro devaajalle riittävästi virheen toistamisesta tai sen vaikutuksista lopputuotteeseen. Silloin ihan jokaisen lukijan vuorollaan täytyy tutkia aihetta itse lisää. Se, jos mikä, on omiaan haaskaamaan myös devaajan työaikaa! Jos testaaja haaskaa riittävästi kavereiden työaikaa, alkavat kaverit automaattisesti välttämään yhteistyön tekemistä. Silloin mennään metsään pahasti.

Bugiraportin hyvyys vaikuttaa merkittävästi siihen mitkä virheet korjataan ja mitä ei. Hyvä virheraportti luonnollisesti kuvailee virheen tarkasti ja sisältää myös taustatutkimusta ja vaikutusten analysointia. Hyvä virheraportti antaa lukijalle pelimerkit päätösten tekemiseen niin tuotteen kuin bisneksenkin kannalta. Kannattaa laittaa tämä korvan taakse:

Testaajan rooli on devauksen lisäksi myös bisneksen ja myyntiprosessien tukeminen.

Siksi bugiraportti on testaajan paras käyntikortti. Se edustaa testaajaa silloinkin kun hän ei ole itse paikalla.

Yksilön oma etu toimii yhteisön edun hyväksi. Väitteen esitti nykyaikaisen taloustieteen isäksikin tituleerattu Adam Smith jo 1700-luvulla. Samankaltaisilla linjoilla oli myös meidän Chydenius aikanaan.

Mainitun periaatteen Smith esitti vertauskuvalla “näkymätön käsi“. Homman nimi on siinä että järkevät, omaa etuaan ajavat ihmiset hyödyttävät kaikkia pidemmällä aikavälillä. Periaatteen mukaan homma toimii silloin kun ihmiset eivät saa pakottaa toisia vaan voivat hyötyä näistä vain tarjoamalla vastapalveluksia (*). Näkymätön käsi on siis vapaassa taloudessa ihmisten toimintaa ohjaava voima. Päätökset ja tekeminen hyödyttävät kaikkia osapuolia.

Softakehityksessä sama periaate näkyy nyt entistä selvemmin. Parhaisiin tuloksiin pääsevät organisaatiot ovat yleensä rakenteeltaan hyvin matalia. Niissä korostuu työntekemisen malli, jossa tehdyt ratkaisut ovat kaikille hyväksi. Esimerkiksi työkaluvalinnat eivät synny managementtipäätöksillä vaan itse tekijöiden tarpeista. Managementti hyötyy kun tulosta syntyy nopeammin, työntekijä hyötyy kun työkaluksi valitaan hänelle helpoin ratkaisu. Tällaisissa organisaatioissa johtajuutta ei usein anneta vaan se on myös ansaittava.

Online-pelit ovat mielestäni mainio esimerkki tästä. World of Warcraftissa kaikki pelaajat aloittavat yksin, mutta suurimmat tavoitteet voidaan saavuttaa ainoastaan toimivina tiimeinä. WoWissa kykenevimmät yksilöt valitaan johtajiksi tarveperusteisesti. Johtajuus on kestävää ainoastaa siinä tapauksessa että se hyödyttää tiimin kaikkia jäseniä.

Muinoin johtajat valikoivat seuraajiaan. Uhkaajat pudotettiin pelistä teloittamalla tai karkottamalla maasta. Siis pakottamisella ja pelolla. Nykyisin ihmiset valitsevat ketä haluavat seurata. Nämä valinnat palvelevat aina jollakin tavalla omaa etua. Käytännöllisin esimerkki on Twitter, jossa Lady Gagaa seuraa lähes 8 miljoonaa ihmistä. Barack Obamalla seuraajia on yli 6 miljoonaa ja minulla alle 10. Vielä on siis vähän tekemistä 🙂

No. Homman pointti lienee kuitenkin selvä. Twitterissä yksilöt hyötyvät seuraamisesta ainakin sosiaalisesti, Twitter.com hyötyy valtavista käyttäjämääristä taloudellisesti, Lady Gaga ja Barack Obama taas hyötyvät hommasta vähintäänkin PR-mielessä.

Hyvä asiakas. Tavoittele avoimesti omaa etuasi. Niin minäkin teen. Se on lopulta kaikkien etu!

* Vastapalvelukset voivat olla oikeasti palvelua, hyödykkeitä tai vaikkapa rahaa.

Kun vuoden vaihde painoi hetki sitten päälle, niin testaajan työkuorma kasvoi aivan yllättäen. Softakehityksestä hävisi järki totaalisesti. Testaajasta tuli syyllinen, kun tulosta ei syntynyt deadlineen mennessä. Mitä siis tapahtui?

Homman nimi on siinä, että testausta käytetään tuotekehityksen tukena. Tietysti se on hieno ja toimiva ajatus, paitsi jouluna.

1. Kysymys testaajalle: Miksi meidän regressiotestissä on vieläkin niin paljon faileja?
2. Ohjeistus testipäällikkölle: Kannustahan vähän sitä testitiimiä, että saadaan vihreä palkki nousemaan!
3. Case katselmoinnin agenda: Miten testitapauksia pitäisi korjata, että pass rateksi saataisiin 98%?
4. Toimittaja testaajalle: Eeeei tuo ole defekti, pistä case vihreeksi vaan!
5. Pitääkö palkata lisää testaajia?

Testausta käytetään häikäilemättömästi hyväksi nimenomaan silloin kun on bonukset pelissä. Silloin tarvitaan hopeareunustettua totuutta että tavoitteet saavutetaan. Helpoimmin se käy, kun testataan softa kuntoon. Näin testaajat painavat täysin turhaa työtä koko loppuvuoden. Devaajat ovat tyytyväisiä, kun kaikki näyttää hyvältä. Managementti vain hymyilee ja rahaa kuluu vielä lisäksi uskomaton määrä perusteettomiin bonuksiin.

Minun on pakko vastata edellisiin kohtiin:

1. Siksi kun softa on vieläkin ihan romuna
2. Just joo! Testaamallahan ne virheet korjaantuu
3. Heitän pallon takaisin: Miten softaa pitäisi korjata, että pass rateksi saadaan 98%?
4. Kyllä se on defekti, jos loppukäyttäjää ***uttaa armottomasti
5. Ei varmaankaan. Näyttää siltä että nyt tehdään vääriä asioita!

Se on oikeasti kallis tikki, jos et uskalla ottaa kantaa näihin jouluhullutuksiin tänäkään vuonna!


Testausalalle vihkiytyneenä ihmisenä automaattinen vastaukseni tähän kysymykseen on “ehdottomasti kyllä!”. Vastaus on hyvä yleisesti ajateltuna, mutta entäs sitten talous- ja mainenäkökulmasta katsottuna. Tältä kannalta virheen vakavuus ja sen toistettavuus näyttelevät pääroolia. Heitän esimerkkinä kaksi skenaariota:

1. Conan Barbaarin uudenkarhea kahden käden miekka osoittautuukin tylsäksi. Valmistusvirhe on selkeä ja toistettavissa jokaisella käden heilautuksella. Conan Barbaarin taistelutaitoihin tämä tuskin vaikuttaa, mutta tavallisen tusinataistelijan käsissä miekka koituu käyttäjänsä kuolemaksi.

2. He-Manin juuri pakasta vedetty yhden käden miekka on terävä ja leikkaa lihaa todella huonosti vain tietyssä osumakulmassa. He-Man on myöskin Conanin veroinen miekkamies, jonka taistelutaktista näkemystä yksittäiset huonot viillot eivät juuri horjuta, mutta se yksikin huono osuma voi muuttaa taistelun suunnan täysin odottamattomaan.

Conanin ja He-Manin yhteisellä miekanvalmistajalla on valinta edessä. Jatkaako tuotantoa samanlaisena vai korjatako virheet? Bisnesmiehenä miekanvalmistaja punnitsee valmistusvirheiden vakavuudet tarkoin ja päätyy korjaamaan Conanin tylsän miekan mutta jatkaa He-Manin terävän miekan tuotantoa normaaliin tapaan. Miekanvalmistajan mielestä korjauskustannukset ovat joskus huomattavasti suuremmat kuin kyseisestä virheestä aiheutuvat kustannukset.

Oikean elämän esimerkki tästä valinnasta on Joulupukin Hiace-reen viimeisin otsikoissa ollut valmistusvirhe SUA (sudden unintended acceleration). Virheen kuvaus lyhyesti: Petteri on käynyt salilla liian usein. Kysymys kuuluu onko rekivalmistajalla ollut kyseinen virhe tiedossa, kun reet ovat päästetty tuotantoon? Virheen esiintymismäärä eli toistettavuus on hyvin pieni verrattuna myytyihin rekiin. Tämän kaltaisten virheiden korjauskustannukset ovat lähes varmasti suuremmat kuin virheestä suoraan aiheutuvat kustannukset. Virheestä epäsuorasti aiheutuvat kustannukset ovat kuitenkin asia erikseen. Henkilövahinkoihin ja kuolemantapauksiin johtavat virheet nostavat sataprosenttisella varmuudella kunnon mediamylläkän, jonka seurauksena ihmiset eivät välttämättä enää luotakaan Joulupukkiin kuten ennen.

Olisiko sittenkin kannattanut korjata se mitättömän kokoinen pieni bugi?

Testausgurut toivottavat virheetöntä joulua ja kustannustehokasta uutta vuotta kaikille tasapuolisesti!

David Devaaja paukuttelee koodia projektissa yhdessä Kari Koodarin kanssa. Parin viikon Sprinttiä on nyt painettu viimeiset päivät pitkillä ylitöillä. Kun poikien työ lopulta valmistuu, heivataan softa ja juuri valmistunut featurepaketti Tiina Testaajan käsittelyyn. Aika usein sitä sanotaan Agileksi.

Hirveän usein firmat kertovat tekevänsä softaa ketterästi. Siitä huolimatta tarkempi pureutuminen softakehityksen ytimeen paljastaa edellä kuvatun tilanteen. Yleensä kyseessä onkin inkrementaalinen tai iteratiivinen (IID) tapa tehdä softaa. Siinä devaajat vetäytyvät rakentamaan kierrokselle sovittujen vaatimusten näköistä softaa ja valmis setti testataan. Äkkiä Agileksi väitetty työ vaikuttaakin sarjalta pieniä vesiputouksia.

Speksaus-devaus-testaus,

speksaus-devaus-testaus,

speksaus-devaus-testaus.

Tämä ajatusmaailmaero aiheutti keskustelua myös Oulussa järjestetyssä TestausOSY:n Agile-seminaarissa. Inkrementaalinen softakehitys ei nimittäin ole automaattisesti Agilea. Agile sen sijaan on luonteeltaan inkrementaalista.

Keskeisimmät erot tulevat tiimityön luonteesta ja nopean palautteen merkityksestä. Palaute ei ole nopeaa, jos työ tehdään vaiheissa ensin devaus, sitten testaus. Silloin ei myöskään ole kysymys tiimityöstä vaan kahden tiimin yhteistyöstä. Hämmentävää, eikö totta?

Minusta Agilen ero perinteiseen inkrementaaliseen softakehitykseen tiivistyy seuraaviin kohtiin:

1. Tiimi on itseorganisoitu: ei managereita, ei pakotettuja prosesseja
2. Palaute on aina nopeaa: testaajalta devaajalle, asiakkaalta tiimille
3. Työ mukautuu pintautuviin vaatimuksiin: ei pitkiä inkrementtiplaneja
4. Työkalut auttavat tavoitteen saavuttamisessa: ne eivät määrää miten se saavutetaan

Jotta inkrementaalisesta saadaan oikeasti Agilea, ihmisten täytyy oppia päästämään irti vanhasta ajatusmaailmasta “hyvin suunniteltu on puoliksi tehty”. Täytyy lopettaa yritykset ennakoida onnistumista mittaroinnilla tai spekseillä. Täytyy oppia hyväksymään epävarmuutta ja ennakoimattomuuta. Asiat eivät aina mene kuten etukäteen oli suunniteltu. Ennen kaikkea ihmisten täytyy uskaltaa!

Työkalut ja prosessit tulevat ja menevät. Pääasia on, että tulosta syntyy ja softa toimii!

ISEB, ISTQB, CSQA, CSTE, CQIA, CTM, SSBB ja CSTP. No huh huh sanon minä. Testausalan sertifikaatteja on moneen junaan, mutta mitä ne oikeasti opettavat?

Tietysti sertifioinnista jää kouraan todistus. Todistus kertoo siitä että tietty testausosaamisen ja terminologian perustaso on saavutettu. Se kertoo että tentistä on päästy läpi ja kysymyksiin löytyi oikeat vastaukset.

Which of the following would you not use when choosing test techniques?

1. Level and type of risk
2. Time and budget
3. Regulatory standards
4. Recommendations from developers

Edellä on esimerkki ISEB serfitioinnin tenttikysymyksestä. Jos omaa edes vähän käytännön kokemusta muuttuu tähän tehtävään vastaaminen vaikeaksi ellei aivan mahdottomaksi(*). Testaustekniikoita valitessa on tietysti tärkeää miettiä riskejä, resursseja, lakeja ja standardeja. Ihan yhtälailla tärkeää on keskustella devaajien kanssa. Yksikään tiimi ei toimi jos joku sooloilee. Vastaavanlaisia, ristiriitaisia tunteita herättäviä kysymyksiä ovat kaikki sertifiointitentit pullollaan.

Ehkä juuri siksi minusta onkin pitkään tuntunut, että sertifikaatit eivät yksinkertaisesti sovellu nykyaikaiseen testaukseen. Niitä ei voi pitää testauksen hyvyyden mittarina, sillä ne yrittävät hieroa testaajat samaan ajatusmaailmaan ja muottiin. Kuitenkin parhaat tulokset testaustyöstä saavutetaan aina kun samaa asiaa katsotaan yhtä aikaa useammasta näkökulmasta. Erilaiset ihmiset eri suunnilta. Katvealueita jää vähemmän.

Sertifikaattikoulutukset ovat kuitenkin yleensä varsin asiallisia. Niissä on liikkumatilaa keskustelulle, kritiikille ja käytännön kokemuksellekin. Juuri siksi uskon, että sertifikaatit kaikesta huolimatta kertovat sen, mitä testaajan voi olettaa vähintäänkin tietävän. Tärkeimmän ne kuitenkin jättävät aina kertomatta.

Sertifikaatti jättää kertomatta sen, mitä testaaja oikeasti osaa.

(*) ISEB:in mukaan ainoa oikea vastaus tehtävään olisi ollut tuo viimeinen kohta 4.

Ecofin antoi kesäkuussa toimeksi EU:n laajuisen stressitestin tekemisen pankkisektorille. Testauksen tarkoituksena oli selvittää, miten eurooppalaiset pankit pystyisivät kohtaamaan odotettua merkittävästi heikomman talouskehityksen. Yhteensä 91 pankkia EU-alueelta valittiin testattavaksi. Kattavuus testeillä oli 65% EU:n pankkisektorin yhteenlasketusta taseesta.

Testit suoritettiin vauhdikkaasti kunnes heinäkuun lopulla testaajat julkistivat tulokset. Pass-rate oli varsin hyvä. Noin 92%. Vain seitsemän pankkia Espanjasta, Saksasta ja Kreikasta reputti testeissä. Lisäksi testaajat olivat vakuuttuneita testien luotettavuudesta ja ankaruudesta. Kunnon stressitestausta siis.

Yksikään irlantilainen pankki ei kuitenkaan saanut hylsyä kesällä järjestetyissä testeissä. Mitä ihmettä?? Näin testaajan näkökulmasta katsottuna pistää kyllä miettimään.

Kaikesta mediahuomiosta huolimatta juuri kukaan ei kysy, että mikä testeissä meni pieleen? Se on olennaisin kysymys arvioidessa testauksen hyvyyttä. Se on olennaisin kysymys jos tosiaan halutaan parantaa testauksen luotettavuutta.

On kuitenkin tärkeää huomata, että tuo kysymys kysytään vain jos uskotaan testien epäonnistuneen. Siksi minusta tuntuu, että pieleen menikin testauksen tavoitteiden asettelu. Testien tulos oli täsmälleen se mitä niiden haluttiinkin olevan!

• Gaining confidence
• Finding defects

Kumman tavoitteen sinä olisit asettanut europankkien stressitesteille?

“Sun tarttee varoo mitä sä haluut, koska sä saatat saada sen” – Andy McCoy

“Hyvä idea!” tuumasi Päivi Projektipäällikkö. Tuotekehityksen budjettihan on ilman muuta järkevää jakaa siten että testaus ostetaan palveluna sitten kun sitä tarvitaan. Tehdään ensin testauskierros ensimmäiselle release kandidaatille. Tulosten perusteella korjataan virheet ja toisella kierroksella veridioidaan, että kaikki meni putkeen. Kaksi kierrosta riittää!

Päivin tyylillä toimii hämmästyttävän moni softaprojekteja ja -tuotteita tekevä yritys. Lähestyminenhän on ihan huippujärkevä niin kauan kun

• Uusia testejä/käyttötapauksia ei enää tule,
• Tuote ei muutu millään tavalla muuten kuin bugikorjausten osalta ja
• Bugikorjaukset eivät koskaan riko muita toiminnallisuuksia

Tällaisissa projekteissa käy lähes poikkeuksetta niin että aikataulu kusee testauksen astuessa kuvaan. Alkuperäiset odotukset nimittäin ovat hyvin epärealistiset. Virheitä löytyy aina odottamattoman suuri määrä jo ensimmäisellä kierroksella. Deadlinet paukkuvat, koska korjaaminen vie odottamattoman paljon aikaa. Yleensä ensimmäisellä kierroksella kuvaan astuvat myös testit joille lyödään “cannot run” -leima. Tämä johtuu siitä että osa virheistä estää niiden takaa löytyvän toiminnallisuuden luotettavan testaamisen.

Verifiointikierroksella löytyy jälleen lisää virheitä pelkästään jo sen takia että tuote on tullut tutummaksi testaajille. Lisäksi todennäköisyys sille, että koodaajat saavat virheettömästi korjattua kaikki oleelliset ongelmat, on oikeasti häviävän pieni. Päivin tyylillä myös yksi testauksen keskeisimmistä vahvuuksista jää saavuttamatta koko tiimillä. Se on oppiminen.

Älä siis pilaa hyvää projektia epärealistisilla laatufantasioilla.

Olet hankkimassa kännykkää tai vaikkapa uutta televisiota. Saatat olla myös tilaamassa yrityksellesi uutta CRM:ää tai vaihtamassa läppärimerkkiä. Oletko koskaan miettinyt miten ostopäätöksesi syntyvät?

Ennen bisnestä tehtiin kasvotusten. Keskustelemalla asiantuntijan, eli myyjän kanssa. Myyjän tiedolla oli painoarvoa hankinnoissa. Myyjään myös luotettiin hankintapäätöksissä. Hintojen ja tuotteiden vertaileminen oli hankalaa ja se jos mikä on tuotebisneksen tekijän kannalta unelmatilanne. Jos hyvin kävi, oli harkinnan alainen tuote arvosteltu alan julkaisussa tai joku tuttu oli jo ehtinyt sitä kokeilemaan aikaisemmin. Ostopäätöksiin vaikutti myös melko vahvasti mainonta ja markkinointi. Nimenomaan se perinteinen tapa houkutella asiakkaita.

Nykyään bisnes syntyy täysin erilaisista lähtökohdista. Mitä asiakas tekee?

• Tarkastelee tuotteiden hintoja palveluissa: hintaseuranta.fi tai vertaa.fi.
• Vertailee tuotteiden ominaisuuksia toisaalla: puhelinvertailu.com.
• Lukee muiden kokemuksia foorumeilla: hopeinenomena.net.
• Seuraa muutamaa alan sivustoa ja blogia: Gizmodoa tai Engadgettiä.
• Uskoo alan rupelihattuja, kuten Lasse Pulkkista Twitterissä.
• Katsoo kiinnostavan unboxing-videon Youtubessa.
• Keskustelee ominaisuuksista ja kokemuksista kavereiden kanssa Facebookissa.

Markkinointi ei ole enää perinteistä luukuttamista medioissa tuotteiden erinomaisuudesta. Nykyaikaista markkinointia on huolehtia että tuotteet tosiaan ovat erinomaisia. Tuotteiden tulee taata käyttäjille hyviä osto- ja käyttökokemuksia. Käyttäjät täytyy saada itse levittämään onnistumisen ilosanomaa.

Mitäpä luulet: Voiko nykyisin syntyä menestyvää bisnestä jos tuote on huonolaatuinen? Olisiko sittenkin syytä panostaa vähän enemmän testaukseen?

Edisteen Jari Parantainen palautti minut jälleen perusasioiden äärelle. Yksinkertaisen kysymyksen voima nimittäin on murskaava. Sen sai huomata myös Yhdysvaltojen presidentin pallia havitellut Ted Kennedy. Kennedyn matka tyssäsi esivaaleissa yksinkertaiseen kysymykseen.

Miksi haluat presidentiksi?

Yksinkertaisilla kysymyksillä on taipumus palauttaa vastaajan jalat maahan. Yksinkertainen kysymys vaatii yksinkertaista vastausta.

Yleensä softaprojekteissa tehdään pirusti töitä ja useimmiten on myös kova kiire. On kiire istumaan suunnittelupalaveriin, on kiire saada raportit pakettiin, on kiire katselmoida virheidenhallintaprosessi, on kiire laatia testispeksit. Kiire on jatkuvaa. Mutta miksi?

Minä väitän että siinä on kysymys nimenomaan yksinkertaisten kysymysten puuttumisesta. Kaikki keskittyvät näyttämään ahkeralta ja tuottavalta. Kukaan ei ymmärrä pysähtyä pohtimaan tekemisen syitä tai tavoitteita. Kukaan ei esitä kysymyksiä.

Palaverit. Niissä istuu usein paljon ihmisiä ja niitä saattaa olla kalenteri täynnä. Niissä keskustellaan paljon ja tehdään paljon memoja. Joskus tehdään myös päätöksiä. Useimmiten kuitenkin suurin osa palaverissa istujista voisi olla jossain muualla – tekemässä jotain muuta. Palavereissa istuu paljon vääriä ihmisiä. Kun ensikerralla aloitatte palaverin, kysy jokaiselta osallistujalta: Miksi olet täällä? Passita töihin ne jotka eivät osaa vastata.

Prosessit. Niitä määritellään innokkaasti projektin alussa. Aikaa käytetään niiden dokumentointiin. Niiden tiimoilta järjestetään palavereita tai jopa koulutuksia. Lopulta kun aletaan töihin, niin prosessikuvaukset unohtuvat. Tiimi löytää oikopolkuja ja skippaa vaiheita. Yleensä oikeat työskentelytavat löytyvät vasta kun aletaan oikeasti tekemään. Kun ensikerralla aloitatte prosessien suunnittelun, kysy ensin: Miksi näin?

Dokumentit. Niitä tuotetaan valtavia määriä. Niiden kirjoittamiseen menee pirusti aikaa ja vielä enemmän aikaa kuluu niiden katselmointiin. Katselmoijilta pitää yleensä karhuta kommentteja ja yhteisen katselmointipalaveriajankohdan sopiminen on yhtä tuskaa. Sitten kun määrämuotoinen dokumentti on paketissa, kukaan ei lue sitä ja se unohtuu versionhallintaan kunnes parasta ennen -päiväys on mennyt. Kun ensikerralla päätätte kirjoittaa dokumentin…

Niinpäniin. Kyllä se yksinkertainen kysymys sieltä löytyy kun vähän mietiskelee!

Yksinkertaiseen kysymykseen voi myös olla helppoa löytää vastaus. Silloin on todennäköistä että tekeminenkin on järkevää, tuottavaa ja hyödyllistä. Jos taas vastaaminen käy kuten Kennedyllä, on hyvin todennäköistä että nyt ollaan tekemässä vääriä asioita.

Nyt sinulla on hyvä sauma pysähtyä miettimään se ensimmäinen yksinkertainen vastaus:

Miksi teillä testataan?