Tag: Suomi

Edellisen blogi-tekstin keskustelussa pyöriteltiin jälleen testaajien ja kehittäjien välisen kommunikaation haasteita. Testaaja testaa ja raportoi Virheet koodareille. Periaatteessa kyse on softamaailmassa neutraalista termistä, mutta missä tahansa muualla Virheellä on negatiivinen sävy. Hoitovirhe, mittausvirhe tai virkavirhe sisältävät kaikki oletuksen siitä, että joku on tehnyt jotakin väärin.

Vaikka Virheen sävyn softa-alan ammattilaiset ymmärtävätkin, voisiko omasta koodista löydetty Virhe kaivaa alitajunnasta esille ne kouluaikojen laskuoppi- ja kielivirheet, joista opettaja antoi yleensä negatiivista palautetta. Hoitovirheen aiheuttajaksi ei meistä halua kukaan. Virheen tekeminen vitut… harmittaa.

Koska testaajan löytämä Virhe ei ole millään muotoa negatiivinen tai moittiva, niin miksi sillä pitäisi olla muilla elämänalueilla negatiiviseksi ja moittivaksi koettu termi. Jos Virhettä kutsuttaisiin joksikin muuksi, voisi koodarit tehdä rauhassa töitä ilman alitajunnasta puskevia epämiellyttäviä assosiaatioita.

LEIKKIMIELINEN TEHTÄVÄ: Keksi neutraali (tai peräti positiivinen) termi testaajan löytämälle vaatimusten vastaiselle toiminnalle, jota tällä hetkellä virheeksi kutsutaan. Kirjoita ehdotuksesi kommenttikenttään!

Katsotaan mitä saadaan aikaan.

Tulin aamulla bussilla töihin ja todistin n. kolmevuotiaan pojan ja oletettavasti isoäitinsä keskustelun. Tuntui olevan kyselyikä pojalla päällä, sen verran tanakasti kyselyitä tuli koko vartin matkan verran.

Onko tämä meidän pysäkki? -Ei ole vielä

Mikä on meidän pysäkki? -Toripakka

Milloin ollaan perillä? -Noin kymmenen minuutin päästä?

Miltä se pysäkki näyttää? -No, siinä on semmonen katos ja varmaankin paljon ihmisiä odottamassa

Miksi me ajetaan tällä bussilla? -Tällä pääsee kätevästi kaupunkiin

Mitä me sitten tehdään, kun ollaan päästy perille? -Mennään puistoon

Miksi me mennään puistoon? -Leikkimään ja syömään eväitä. Eikö se olisi sinusta mukavaa?

No on! Nyt taidetaan olla perillä, tuolla on katos ja ihmisiä! -No niin ollaan, nyt voidaan jäädä pois

Vierestä kuunnelleen kysymykset vaikuttivat vähän hassuilta. Toisaalta, mitenpä lapsi muuten olisi voinut mitään oppia? Pieni sälli hahmotti maailmansa kysymysten kautta, onhan selvää että bussilla matkustaminen ei ole vielä kovin tuttua. Kysymykset olivat kaikki oleellisia tulevien tapahtumien arvioinnissa.

Vastaavalla tavalla testaajan olisi hyvä varmistua siitä, että miksi jotakin tehdään ja kauanko siihen on aikaa. Lisäksi on hyvä miettiä määrittelyt sille, että milloin tiedetään releasen olevan julkaisukelpoinen. Lopuksi on hyvä vielä pohtia, että mitä releasen julkaisun jälkeen pitäisi tehdä. Näin suunta pysyy kirkkaana mielessä.

Jos et tiedä, älä oleta. Päästä sisäinen kyselyikäisesi valloilleen ja katsele maailmaa kolmevuotiaan silmin. Kysy, varmista ja kyseenalaista. Uusia näkökulmia testaukseen löytyy varmasti.

Vaikka Antti väitti taannoin, että heinäkuussa ollaan kesätauolla, niin tästä on pakko kirjoittaa.

Tämmönen uutinen osui eilen silmään Tietoviikosta. Uutinen kertoo, että USAn armeijan SAP-projekti on vuosia myöhässä. Projekti on alkanut vuonna 2005, sen piti olla valmis vuonna 2007, jolloin uusi valmistumistavoite asetettiin vuoteen 2010. Tämän hetken arvaus on, että uusi ERP olisi käytössä tämän vuoden joulukuussa.

Muutama mehukas poiminta jutusta:

Uusi SAP-järjestelmä korvaa valmistuessaan yli 140 erillistä vanhaa järjestelmää. Uudella erpillä hallinnoidaan 140 miljardin dollarin vuosibudjettia, ja se palvelee 80 000 käyttäjää. Noin 15 500 ihmistä käyttää jo nyt järjestelmää.

Vau, projekti on neljä vuotta myöhässä alkuperäisestä suunnitelmasta, ja vajaa viidesosa käyttäjistä käyttää järjestelmää!

Vuodesta 2005 käynnissä olleessa projektissa ei ole vieläkään tunnistettu kaikkia vaatimuksia ja kuluja. Myös tarkastajien vuonna 2008 antamasta 16 suosituksesta seitsemän on edelleen toteuttamatta.

Yhtäkkiä tuo arvio käyttöönotosta tämän vuoden joulukuussa alkaa kuulostaa kovasti optimistiselta.

Tilintarkastajien mukaan projekti on tullut jo yli 53 miljoonaa dollaria budjetoitua kalliimmaksi. Vaarana on myös se, ettei järjestelmä valmistuessaan palvele alkuperäisiä tavoitteitaan.

Yhdysvaltain armeija ei tarkastajien raportin mukaan ole itse yhtä huolissaan projektin tulevaisuudesta vaan toteaa, että esitetyt riskit ovat hallittavissa eivätkä ne vaikuta hankkeen kustannuksiin tai aikatauluun.

Anteeksi mitä täh häh? “Ei vaikuta kustannuksiin tai aikatauluun”? Kuinkahan paljon projektin pitäisi olla myöhässä, että se vaikuttaisi aikatauluun. Melko varma olen siitä, että armeijan päälliköt eivät tee tuota projektia omilla rahoillaan.

Älyttömän tarinan lopussa on kuitenkin jotakin järkevääkin.

Amerikkalaisen konsulttifirma Asuretin toimitusjohtaja Michael Krigsman muistuttaa, että kaikissa suurissa erp-projekteissa vaikuttaa aina kolme tekijää: ohjelmistotoimittaja, järjestelmäintegraattori ja asiakas. Jotta hanke onnistuu, kaikkien täytyy hoitaa oma roolinsa hyvin.

Eittämättä tässä tilanteessa asiakas, USAn armeija, ei ole vahtinut toimittajien perään riittävästi. Miksi pitäisikään, koska riskit ovat hallittavissa eikä aikatauluongelmia ole.

Yritykselläsi ei ole rahaa yhtä paljon kuin USAn armeijalla. Ennen toimitussopimuksen allekirjoittamista valitse itsellesi puolueeton kumppani, joka auttaa yritystäsi pitämään toimittaja aikataulussa.

Juhannus tuli ja meni. Minä aloitin Juhannusvapaat istuskelemalla rantakivillä rakkaassa mökkirannassa. Hetki oli otollinen haaveilulle, sillä kevyt aalto löi rantaan ja miellyttävä merituuli puhalsi myös hyttyset tiehensä. Tuuli taisi olla sopiva, sillä myös lomapurjehtijat olivat lähteneet liikenteeseen.

Tuulen yltyessä purjehtiminen käy aina haastavammaksi hommaksi. Kyyti kyllä kovenee, mutta myös kapteenin taidot pääsevät koetukselle. Purjeella ajaessa tuulen voimistuminen kallistaa venettä reippaasti. Lisäksi veneen osiin, kuten mastoon ja takilaan kohdistuvat voimat kasvavat. Purje saattaa venyä tai pahimmassa tapauksessa kärsiä jopa vahinkoa, ellei valveutunut kapteeni ymmärrä tilannetta.

Reivauksen tarkoitus on pienentää purjeen pinta-alaa. Homma hoidetaan esimerkiksi laskemalla isopurjetta alaspäin ja kiinnittämällä se matalammalta puomiin kiinni. Pienentämällä purjeen alaa voidaan edellä mainittuja ongelmia välttää ja matkanteosta saadaa turvallisempaa. Lisäksi nopeus vastatuuleen luoviessa kasvaa.

Mutta mistä kapteeni tietää milloin on syytä reivata?

Edellisen tekstin lukeneet saattavatkin jo arvata vastauksen. Kyse on fiiliksestä. Ruorin takana voi toki olla mittarit kallistuskulmalle ja tuulen tosinopeudelle, mutta oikeat päätökset syntyvät kokemuksen ja tuntuman perusteella.

Suosittelen lämpimästi pientä itsetutkiskelun hetkeä kaikille softa-alalla oleville. Helpointa se on rannassa tai retkinuotiolla.

Milloin viimeksi dokumentoit lomallesi tai harrastuksillesi vaatimukset? Oletko koskaan tehnyt yksityiskohtaista lomaplaniä? Oletko tehnyt vapaa-ajallesi laatuvaatimuksia tai testitapauksia? Mittaatko onnistumisia jollakin tavalla?

Ainakin itselläni alkaa ahdistaa pelkkä ajatuskin näistä. Kyllä harrastukset ja lomat yleensä onnistuvat oikein hyvin ilman mitään mainituista. Kesäpohdinnan paikka onkin siinä, voisiko vapaa-ajan toimintatavoista oikeasti olla hyötyä myös ammattikäytössä?

Hyvää ja rentouttavaa kesälomaa kaikille. Ohjelmistotestaus.fi palaa aalloille jälleen elokuun alussa.

Kauhukahvasta ei voi ohjata. Siitä pidetään kiinni rystyset valkoisena kun tie yllättäen käy kuoppaiseksi.

Istuin alkuviikosta kartturina matkalla lounaalle. Tehtäväni oli kertoa mistä käännytään matkalla kiinalaiseen ravintolaan. Istun autossa harvoin muualla kuin ratin takana ja siksi matka oli opettavainen. Minulle se opetti paljon testaajan elämästä ohjelmistoprojektissa.

Kartturin saappaissa näin tietysti jatkuvasti kaiken mitä liikenteessä tapahtui ja ketä muita tien päällä liikkui. Saatoin jatkuvasti tuntea jos nopeus olisi ollut liian kova tai ehkä liian hidas. Tunsin tietysti senkin oliko matka kuoppainen ja kuinka jyrkkiä hidasteet olivat. Kuskin jarrutukset ja kiihdytykset olivat minulle päivänselvä juttu. Ne olisin havainnut vaikka silmät kiinni. Näin myös jatkuvasti onko takana tuleva liian lähellä. Osasin myös arvioida näyttääkö tien pinta sateen jälkeen vaaralliselta. Eikä huomioiden tekeminen siihen loppunut. Listaa voisi jatkaa loputtomiin.

Kaiken tämän informaation pystyin keräämään pelkästään tilanteen seuraamisesta ja tuntemisesta. Niin varmasti kuskikin teki. Ja menestyksellähän ei ollut mitään tekemistä auton mittareiden kanssa. Ajatelkaapa jos olisimme kuskin kanssa molemmat tuijotelleet koko matkan nopeus-, kierros-, kulutus- ja matkamittareita, kuten softaprojekteissa niin usein on tapana. Äkkiä olisimme löytäneet itsemme ojasta.

Testaaja, kuten kartturikaan eivät pysty suoraan vaikuttamaan matkantekoon. Oikeanlainen kommunikaatio on kaiken a ja o.

Tämä reissu oli siksi onnellinen, että pystyin todella vaikuttamaan matkantekoon. Kuski oli fiksu ja hän ymmärsi ohjeet mainiosti. Meillä oli myös ennalta sovittu yhteinen tavoite mielessä. Kommunikaatio pelasi erinomaisesti molempiin suuntiin.

Kartturina yritin tietysti antaa ohjeet rakentavasti ja hyvissä ajoin. Ilmeisesti myös onnistuin siinä, koska kiinalaista saimme lounaaksi ja vielä molemmat samassa paikassa. Mutta mitäpä olisikaan tapahtunut, jos olisin vain viisastellut ja kuittaillut “tuosta olisi pitänyt jo kääntyä”? Veikkaan, että omalta osaltani matkanteko olisi jatkunut jalan.

Minusta mittarit ovat oivallinen apuväline matkan tekoon. Pääpaino oikeiden ratkaisuiden tekemisessä ei kuitenkaan voi ikinä olla niissä. Kysmys on lähes aina perstuntumasta ja oikeasta keskustelutavasta. Kysymys on fiiliksestä. Jotkut kutsuvat sitä intuitioksi, toiset taas kokemukseksi. Homman nimi on kuitenkin aina sama niin autoilussa, kuin softakehityksessäkin.

Faktat, mittarit ja numerot ovat oivallinen apuväline, mutta todelliset ratkaisut ja onnistumiset rakennetaan aina lopulta tunnepohjalta. Luottamuspula tunteisiin on päätöksen pahin vihollinen.

P.S. Tällä matkalla kauhukahvaan ei tarvinnut tarttua. Kyyti oli mukava ja tiimi toimi!

Quality Assurance, QA tai Laadunvarmistus. Kuulostaa hienolta ja näyttää kovalta käyntikortissa. Harmi vain, että sillä on hyvin vähän tekemistä testauksen kanssa.

Työskentelin taannoin eräässä isomman mittaluokan projektissa testaajana. Minä metsästin bugeja. Tittelinä meillä testauksen ammattilaisilla oli “QA engineer”. Asiakkaan kanssa keskustelimme aina QA-asioista ja QA:ta puski tuutin täydeltä ja joka suunnalta.

Kun projektia oli painettu vuoden verran alkoi näyttää selvältä, että eihän tästä saada ikinä valmista tuotetta. Me ymmärsimme sen tehtyämme töitä noin 9 kk ja me uskalsimme jopa sanoa sen ääneen. Tuotteen omistaja ymmärsi sen haaskattuaan rahoitusta vielä 8 kk lisää. Tuo viimeinen 8 kk oli ehkä urani opettavaisinta aikaa. Silloin seulottiin armottomasti ongelmia ja koitettiin löytää ratkaisuja. Harmi vain, että ratkomista yritettiin täysin väärästä päästä. Kaikki nimittäin lähti liikkeelle testauksesta, eli meidän projektissamme laadunvarmistuksesta.

Teidän tehtävänne on varmistaa laatu. Tehän olette laadunvarmistajia! Miksi tässä projektissa kaikki menee metsään?

Niinpä. Tästä asetelmasta lähtee hämmästyttävän monen testaajan arkipäiväisimmät ongelmat. Testaajan kuvitellaan olevan vastuussa laadusta, vaikka todellisuus on täysin toinen.

1. Testaajalla ei ole valtaa tehdä muutoksia koodiin
2. Testaajalla ei ole valtaa tehdä päätöksiä releaseista
3. Testaajalla ei ole valtaa tehdä päätöksiä projektijohtamisesta
4. Testaajalla ei ole valtaa päättää aikatauluista

Saman kysymyksen ilmaan heitti myös Michael Bolton Rapid Software Testing -kurssillaan.

Why on earth would you call it quality assurance, when people doing it have no control over the quality?

Laadunvarmistus on hieno sana, mutta yleensä se on täyttä huuhaata. Ainakin minulla tulee laadunvarmistuksesta mieleen, että nyt testaajan on varmistettava tuotteen laatu. Näin testaajan työn oikeasti hyödylliset tavoitteet voidaan heivata heti romukoppaan. Sana laadunvarmistus asettaa ajatusmaailman väärille raiteille jo ennen kuin työtä on edes aloitettu.

Testaajan todellinen tehtävä ei ole rakentaa luottamusta tuotteen toimivuudesta. Testaajan todellinen tehtävä on tuhota väärin perusteltu luottamus. Silloin ei ole kyse laadunvarmistuksesta, silloin on kyse testauksesta.

P.S. Jatkossa tagilla “bolton” merkityt tekstit ovat matkaeväitä, jotka kirjailin ylös Michael Boltonin Rapid Software Testing -kurssilla Helsingissä.

Sucker Punch oli hyvä leffa. Uskallan sen sanoa, vaikka eriäviä mielipiteitä sataa kaatamalla. Päällimmäisenä koko elämyksestä minulla jäi mieleen uskomattoman osuva lainaus:

You have all the weapons you need… now fight!

Tuo kohtaus pysäytti minut. Se pysäytti siksi, että sain itseni kiinni mitä typerimmästä ajatusmaailmasta. Olen kai aina ajatellut, että tuloksen aikaansaamiseksi tarvitaan työkaluja. Aseita, joilla homma hoituu aina tehokkaasti ja mutkattomasti.

Kun suomalaista miestä kohtaa ongelma, pihalamppu on palanut tai toimiston wc-istuin on rikki, mies lähtee rautakauppaan. Reissulta tarttuu mukaan uskomattoman tarpeellinen joukko uusia työkaluja, joita ilman ei takuuvarmasti olisi tullut toimeen. Joskus siinä hässäkässä saattaa unohtua jopa itse asia, eli se pihalamppu tai istuin.

Sama ongelma lyö päivittäin kapuloita rattaisiin lukuisissa softaprojekteissa ympäri maailman. Tuskallisen luovan työn ja hommiin ryhtymisen sijasta ihmiset etsivät mitä hienoimpia työvälineitä netistä, virittelevät niitä toimintaan ja saattavat jopa maksaa niistä mansikoita. Kuitenkin lähes poikkeuksetta nämä työvälinehankinnat ovat tuloksen aikaansaamisen pahin este.

Testauksenhallintajärjestelmä on yksi näistä vehkeistä. Useimmiten niitä otetaan isolla tohinalla käyttöön ja aletaan paiskimaan kunnolla töitä työkalun täyttämiseksi dokumentaatiolla. Suomeksi sanottuna siis testitapauksilla, vaatimuksilla ja testien toistokierroksilla. Oikeasti samat testaustyön tulokset olisi voinut saavuttaa hyödyntämällä järkevästi vain 10% järjestelmän ominaisuuksista. Tai kokonaan ilmankin!

Tieturin Testaus 2011 -seminaarista minulle jäi elävimmin mieleen Elisa Puoskarin puheenvuoro Sulakkeen toimintatavoista. Sulakkeella sprintit ovat päivän mittaisia. Sulakkeella on heitetty myös virhetietokantajärjestelmät mäkeen. Projektihuoneen seinällä komeilee taulu post-it lappuja, yksi erroria kohti. Sillä ei voi haaskata aikaa rautakaupassa norkoiluun, konffaukseen, servereihin, tietohallintoon eikä käyttäjäoikeuksiinkaan.

Työkaluihin keskittymisen sijaan Sulakkeella on ymmärretty se, mitä Sucker Punch yritti sanoa.

Lopeta joutava esteiden, ongelmien tai syyllisten etsintä ulkopuolelta ja pysähdy hetkeksi miettimään. Sinulla on jo kaikki työkalut, mitkä onnistumiseen tarvitset. Älä pelkää käyttää niitä!

Hyvin hankalaksi, on oikea vastaus. Sain asiakaspalvelukokemuksen siivittämänä ajatuksen kirjoittaa juuri sattuneesta tapahtumasta. Tapahtuman kulku on seuraavanlainen:

Kävin ostamassa Anttilasta uudenkarhean ja laadultaan peruskäyttöön välttävän Samsungin dvd-soittimen. Soittimessa ilmeni yllättäen selkeästi käyttäjästä riippumaton virhe: soitettaessa dvd-(tai cd-)levyn trackit saattavat välillä hypätä kokonaan seuraavalle kesken trackin toiston.

Tästä pienestä ja satunnaisesti toistuvasta viasta johtuen kiikutin soittimen takaisin Anttilaan vaatien takuukorjausta. Vähäpätöisesti asiakkaaseen suhtautuen tekniikan osaston myyjä yritti vääntää kättä viimeiseen asti, että kyseessä olisikin vain käyttäjän naarmuinen cd-levy. Yllättävän kovan kädenväännön jälkeen vedin viimeisen kortin hihasta ja kerroin myyjälle: “Olen tietotekniikan diplomi-insinööri ja ammatiltani ohjelmistotestaaja. Olen vakuuttunut, että vika on laitteessa.” Ääni muuttui nopeasti kellossa ja laite otettiin korjaukseen. Liekkö ensimmäinen kerta historiassa kun diplomi-insinöörin tutkinnosta on konkreettista hyötyä? 😉

Reilun kuukauden päästä olin jo lähes unohtanut omistavani dvd-soittimen, kun Anttilasta kilahti tekstiviesti Nokialaiseen. “Tuotteenne on saapunut korjauksesta ja valmis noudettavaksi.” Hain soittimen ja kotona avasin korjaussaatteen sisällön: Firmware päivitetty. Ajattelin OK, saattaahan moinen virhe korjaantuakkin firmwaren päivityksellä. Aloin heti koestamaan soitinta niin eiköhän se taas muutamien Pink floydin rallattelujen jälkeen pompannut seuraavalle trackille kesken hyvän fiilistelyn! Liekköhän Infocaren (Oulun Anttila ulkoistaa tuotekorjauksensa nähtävästi sinne) pojat eteläisessä Suomessa olivat edes testanneet virheen toistuvuutta. Eikun takaisin Anttilaan laite kainalossa. Tällä kertaa soitin otettiin mukisematta korjaukseen.

Parin viikon kuluttua Nokialaiseen kilahti tekstiviesti, jossa pyydettiin asiakasta lähettämään mallilevy Infocarelle, jotta virhe saataisiin toistettua. Viestissä ei ollut minkään valtakunnan tietoja postitusosoitteesta, sähköpostiosoitteesta tai asiaa käsittelevän henkilön nimestä. Viestin loppuun ladattiin vielä ultimaattum: mikäli asiakas ei lähetä mallilevyä 7 päivän kuluessa laite postitetaan takaisin siten, että asiakas maksaa kustannusarviomaksun ja lähetyskulut. Kovin asiakasläheistä toimintaa!

Tapahtuman kulku on tänään viestin saapumispäivänä edelleen auki.

Äkkiä aiheesta herää kysymyksiä. Kuinka perinpohjaisesti Infocaren pojat ovat eteläisessä Suomessa yrittäneet varmistaa virheen oikeellisuutta? Millä logiikalla on halvempaa lähettää laite korjaukseen Oulusta Helsinkiin kuukauden ajaksi, jotta siihen tehtäisiin ainoastaan 5 minuutin firmwaren päivitys? Onko todellakin valmistajan, myyjän tai korjausfirman etu, että asiakasta uhkaillaan postikuluilla, kun kaikki olisivat selvinneet helpommalla vain antamalla toinen laite tilalle?

Kun asiaa ajattelee tuotteen valmistajan Samsungin kannalta tuntuu pahalta. Virheen hinta pääsee moninkertaistumaan näin älyttömän ja tehottoman takuukorjausmenettelyn ansiosta. Kulujen karsimiseksi tulee mieleen kaksi vaihtoehtoa. Ottaa bugit kiinni jo tuotekehityksessä tai alkaa runnomaan korjausputkea paremmaksi.

Koko tarina kiteytyy vinkiksi valmistajalle:

Käyttäjä voi olla tuotteesi parissa 24/7. Et voi olettaa, että yksittäinen korjaaja pystyy havaitsemaan satunnaisesti tapahtuvan virheen parin minuutin (tai tunninkaan aikana). Virhettä ei kannata asettaa lyhyen tarkastelun jälkeen ignored-tilaan mikäli se toistuu vain satunnaisesti. Välinpitämättömyys kostautuu kalliisti.

Kun testaus puuttuu tai se ei toimi, ongelman myöntäminen on yhtä tuskaa. Yleensä se paljastuu vasta kun tavara on jo osunut tuulettimeen. Edelleenkin liian usein puhelin soi meidän toimistolla kun huonot on jo housussa.

Meiltä puuttuu toimiva testaus. Miten tässä nyt kannattaa toimia?

Koska epävarmuus niin usein kalvaa toimivan testauksen rakentajaa, ne ensiaskelet jäävät ottamatta. Vasta pakko pistää liikettä niveliin. Silloin asiakas hengittää jo niskaan ja softakehittäjän aika palaakin yllättäen virheiden korjailuun.

Me päätimme tarjota ilmaisen opetuksen siitä, miten toimiva testaus voidaan rakentaa sopivan pienistä rakennuspalikoista.

1. Kehitä: Rakenna softakehittäjien kanssa säännöllinen elämänrytmi. Jotain testattavaa on tultava tuutista ulos usein. Ilman tätä ei ole mitään järkeä investoida testaukseen.
2. Resurssoi: Palkkaa riittävän kokenut testausosaaja tai osta palvelu partnerilta. Pääasia on, että tyyppi on oikeasti testaaja, eikä vain huono devaaja!
3. Testaa: Polkaise hommat käyntiin tutkivan testauksen menetelmällä. Asiakkaasi elämään vaikuttavien vikojen löytyminen mahdollisimman aikaisin on oikeasti se, mihin kannattaa investoida heti!
4. Rakenna: Tuo mukaan uusia työkaluja. Paranna testauksen- ja virheidenhallintaa. Rakenna systemaattinen tapa toimia esimerkiksi tarkistuslistoilla. Voit pohtia myös automaatiota.
5. Tiivistä: Tiivistä kuilua kehityksen ja testauksen välillä. Tähtää testauksessa pitkistä vesiputouksista lyhyisiin tai Agileen.
6. Mittaa: Rakenna enintään kolme helppokäyttöistä mittaria softan laadun arviointiin. Meidän mittarimme perustuvat kaikki virhetietoihin.
7. Optimoi: Säädä testauksen määrää asteittain kunnes optimaalinen taso on löytynyt.

Hoitamalla yhden asian kerrallaan pääsee softakehityksessä jo pitkälle. Näiden askelmerkkien avulla on mahdollista rakentaa täysin uusi ja laadukas näkökulma ohjelmistojen rakentamiseen alle kuukaudessa.

Voit rakentaa toimivan testauksen pienistä osatavoitteista. Sinun on vain otettava härkää sarvista ja ryhdyttävä toimeen!

P.S. Jos alkuun pääseminen tuntuu vinkeistä huolimatta hankalalta, voit tilata meiltä Kick-offin. Me hoidamme kohdat 1.-4. pois kuleksimasta vain kahdessa viikossa! Sinun ei tarvitse osallistua kuin aloitustapaamiseen ja loppukatselmointiin.