Koskaan ei ole hyvä hetki

Yksi tärkeimmistä opetuksista, joka tarttui matkaani opinnoista TKK:lla, oli Esa Saarisen luennolta. Se kuului: jos odotat täydellistä hetkeä tarttuaksesi toimeen, et koskaan tule tekemään sitä mitä suunnittelet. Muutama vuosi sitten romaania kirjoittava ja taidenäyttelyä valmisteleva työkaverini muotoili saman ajatuksen hieman toisin: kun nainen tulee tiettyyn ikään, sitä ymmärtää että unelmien ei voi antaa enää odottaa jos ne joskus haluaa toteuttaa.

Tämän opin mukaan olen pyrkinyt elämään manageroidessani viisihenkisen perheeni aikatauluja ja sovitellessani siihen itselleni tärkeitä asioita. Koskaan ei ole täydellistä hetkeä, joten tärkeitä asioita on edistettävä aina kun siihen saa tilaisuuden.

Niinpä bussimatkani kuluvat kieliä opiskellen, kirjoja tai testausaiheisia artikkeleita lukien ja silloin tällöin myös blogia kirjoittaen. Tiskatessani saatan seurata youtubesta esim. BBST-luentoa. Kun valmistaudun puheeseen, harjoittelen sitä imuroidessani tai vaikka uidessani.

Moniajossa ja pätkittäin tekemisessä on tietysti huonotkin puolensa. Oppimateriaaleista saisi enemmän irti keskittymällä niihin täysillä. Kokonaisuudessaan aikaa menee enemmän tavoitteen saavuttamiseen kuin jos asian tekisi kerralla. Ja on asioita jotka eivät koskaan valmistu.

Kuitenkin, jos vaihtoehtona on olla tekemättä ollenkaan, oleellinen kysymys ei ole, oliko tämä paras tapa tehdä, vaan oliko tästä iloa.

Edes lopullisesti kesken jääminen ei aina ole pahasta. Esim. blogin kanssa ideaa täytyy alkaa jalostamaan tekstiksi ennen kuin voi tietää, tuleeko siitä jotain julkaisemisen arvoista. Ja se kirjoittamiseen liittyvä ajatustyö voi olla itselle arvokasta riippumatta siitä, julkaiseeko vai ei. Jos alkuperäiset tavoitteet eivät enää vaikuta mielekkäiltä, tavoitteet voi asettaa uudelleen.

Blogin kirjoittaminen ei vaadi erityistä nerokkuutta, se vaatii vain aloittamisen, ja sen että sinnikkäästi löytää hetkiä kirjoittamiseen. Eikä konferenssipuhujaksi tulla odottamalla täydellistä hetkeä ja täydellistä aihetta ja täydellistä uraa, vaan etsimällä aiheita jotka itse kokee jakamisen arvoisiksi ja tarjoamalla niistä puhetta tapahtumiin joihin haluaisi osallistua. Pahin, mitä yrittämisestä voi seurata, on että ei tule valituksi, ja silloinkin prosessista on voinut oppia jotakin.

Toinen pelottava skenaario on tietenkin, että tulee valituksi. Siksi onkin tärkeää valita aihe johon itse uskoo, ja johon ehtii käytettävissä olevan ajan puitteissa valmistautua. On myös tärkeää muistaa, että unelmia ei saavuteta muuten kuin yrittämällä uusia asioita, asioita jotka ovat oman mukavuusalueen ulkopuolella tai vähintään sen ulkoreunalla.

Jonglöörauksen keskellä on hyvä käyttää ajoittain hieman aikaa oman tekemisensä analysoimiseen. Tähän hyvän työkalun tarjoaa PROOF-malli, jota voi soveltaa tähän tapaan:

Past 

Kuinka käytit ajan, mitä teit ja edistikö se asiaa? Millaiset asiat ehkä häiritsivät keskittymistäsi?

Results

Mitä löysit tai sait aikaan? Voitko jakaa tämän jonkun kanssa jäsentääksesi ajatuksiasi aiheesta paremmin?

Obstacles 

Tarvitsetko apua tai työkaluja? Uusien asioiden opetteluun voi löytyä mobiilisovelluksia tai online-kursseja. Blogin kirjoittamiseen on oppaita, puhumiseen kursseja, hakemusten tekemiseen mentorointia.

Outlook 

Miten tästä eteenpäin, mitä vielä pitäisi tehdä? Voiko ajanhallinnallisesti jatkaa näin, vai onko asioiden prioriteetteja tarkasteltava jotta tärkeimmät asiat tulisivat tehdyksi?

Feelings 

Oliko tämä mielekästä? Onko tästä hyötyä tai iloa? Uskotko tähän? Kun kymmenen vuoden kuluttua katsot elämääsi taaksepäin, ovatko nämä niitä asioita joista voit olla ylpeä? Asioita joilla olet muokannut itseäsi positiivisella tavalla, tai luonut jotain hyvää tähän maailmaan? Mitä pidemmän tähtäimen tavoitteita tämä palvelee? 

Elämä on liian lyhyt pelkkään ajelehtimiseen ja valittamiseen.

Priorisointia, tavoitteita ja tehtävänhallintaa

Joulukuu kului joulukiireissä, joten jäi blogin kirjoittaminen taas vähemmälle. Testaukseen liittyviä ajatuksia loppuvuosi herätteli työn lisäksi parinkin testaukseen liittyvän tilaisuuden tiimoilta.

Toinen näistä oli testausyhdistyksen järjestämä teemailta, jonka aiheena oli ajanhallinta. Teemu Vesalan ansiokkaan alustuksen pohjalta keskusteltiin erilaisista haasteista, joita oman työn aikatauluttamiseen liittyy.

Aihetta käsiteltiin monesta kulmasta, erityisesti haasteena nostettiin esiin mahdollisuudet uppoutua keskeytyksettä työhön ja toisaalta myös irtautua siitä. Keskustelu oli kiinnostavaa ja tarjosi hyviä uusia ajatuksia, vaikka monet näkökulmat muistuttivatkin minua lähinnä siitä, miksi olen nauttinut niin paljon mahdollisuudesta siirtyä isosta firmasta pieneen.

Minun ajankäytölliset haasteeni eivät tällä hetkellä liity siihen, että kalenterini täyttyisi turhista palavereista, joihin on vaellettava valtavan rakennuksen toisesta päästä toteamaan, että tapaamisen avainhenkilöt eivät ole edes tulossa paikalle. Työsähköpostini ei täyty kummoistakaan vauhtia, eivätkä työtäni rajoita byrokraattiset käytännöt, joista ei itse työn kannalta ole mitään hyötyä. Organisaation sisäisten siilojen väliset haasteet ovat muisto vain.

Sen sijaan haasteita syntyy ajankäytön priorisoinnista, tekemisen fokuksoimisesta ja tehtävänhallinnasta.


Kun on kiire saada valmista, tekemistä täytyy priorisoida. Se tarkoittaa sitä, että oleellisimmat asiat tehdään mahdollisimman hyvin, ja vähemmän tärkeät unohdetaan väliaikaisesti.

Tällaista toimintatapaa voi perustella useammallakin tavalla.

Ensiksikin, joskus deadlinet ovat ihan aitoja deadlineja. Jos ominaisuus X ei ole vielä ollenkaan käytettävissä kun sitä pitäisi esitellä messuvieraille, tai asiakkaan aikataulukriittinen asia Y pitäisi saada vietyä sillä läpi, aikataulua venyttävä pilkunviilailu tulee kalliiksi.

Toisekseen, joskus asiakkaasta on mahdotonta saada irti riittäviä tietoja jonkin toiminnallisuuden valmiiksisaattamiseksi ennen kuin hänet päästetään koekäyttämään sitä. Silloin ei välttämättä ole tarkoituksenmukaista tehdä sitä kovin pikkutarkasti heti ensimmäisellä kierroksella.

Kolmanneksi, työtä voi sisäisessäkin kehityksessä tehdä ja jaksottaa eri tavoin. Yhden päivän aikana ei voi tehdä kaikkea, eikä testausta ole mielekästä lähestyä joka kerta täsmälleen samalla tavalla. Vain pieni osa tehtävistä on sellaisia, joissa pikaisesta vilkaisusta ennen seuraavaa kontekstin vaihtamista olisi minkäänlaista hyötyä, ja siksi työtä pitäisi saada tehdä riittävän pitkinä sessioina. Toisaalta usein tauon ottaminen on välttämätöntä uusien lähestymistapojen löytämiseksi, ja siksi myös mahdollisuus vaihdella tehtävien välillä on hyvä asia. 

Nämä kaikki asiat vaikuttavat siihen, että kaikkea ei tehdä kerralla täydellisesti, vaan tietyt polut ja tietyt piirteet jäävät perusarjessa vähäisemmälle huomiolle kuin toiset.

Priorisoinnissa on kuitenkin riskinsä.

Yksi riski on vääränlainen priorisointi, eli se että keskitytään kuitenkin vääriin asioihin, tai ainakin jotain tärkeää jää huomaamatta.

Toinen asia on jälkien siivoaminen deadlinen jälkeen. Jääkö tekemisen puutteista riittävät tiedot, että tekemätön työ on mahdollista muistaa dl:n jälkeen? Tuleeko se tehtyä? Onko olemassa jonkinlaista suunnitelmaa, miten epämääräiseksi jääneet asiat saadaan tarkentumaan? Onko analysoitu asiakkaan tarvetta käyttöönottoon liittyvään lähitukeen? Ymmärtävätkö kaikki, että vielä ei ole valmista, vaikka lyhyen tähtäimen tavoite saavutettiin?

Ajanhallinnan kannalta haasteellista on löytää tapa huolehtia aikataulukriittisten asioiden riittävän nopeasta etenemisestä pitäen samalla vähemmän kiireiset asiat aidosti työlistalla, niin että nekin tulevat hoidetuksi. Jatkuvalla kiireellä on tapana pitkällä aikavälillä kostautua. Teknisen velan lisäksi ongelmaksi saattaa muodostua se, että tuotteen kasvaessa pienen prioriteetin asioiden imagovaikutus voi käyttäjän silmissä kasvaa yllättävän merkitykselliseksi.

Samalla omaa tekemistä pitää osata arvioida kriittisesti. Tuliko työ tehtyä riittävän hyvin? Tuliko mieleen asioita, jotka olisi syytä lisätä backlogiin? Oliko tekeminen hyödyllistä? Mikä on oleellista siinä mitä teen, ja miten pian tätä on tarpeen arvioida uudelleen? Mikä minua juuri nyt häiritsee käsillä olevien tehtävien asettamien tavoitteiden ulkopuolella? Mitä minun juuri nyt olisi hyödyllistä opetella? Onko jotain mihin liittyen pitäisi pyytää apua?

Rutiinien keskellä on löydettävä tavat katsoa tilannetta konkreettisten tehtävien ulkopuolelta ja saada palautetta tekemästään työstä. Asettaa pidemmän tähtäimen tavoitteita ja etsiä uutta. Kyseenalaistaa.

Jotta tämä olisi mahdollista, on löydettävä säännöllisesti tilaisuuksia irtautua projektia suoraan edistävistä tehtävistä. Vähän päivittäin, ja silloin tällöin ihan kunnolla.

Näin ruuhkavuosirumban keskellä tuntuu välttämättömältä, että tähän voi varata myös ihan oikeaa työaikaa. Silti sen ajan ottaminen vaatii hieman itsekuria.


Minulle luontevin tapa jäsentää ajatuksiani on kirjoittaminen. Alkavan vuoden tavoitteisiin voisinkin asettaa aktiivisemman blogin kirjoittamisen. Aika näyttää, kuinka moni sepustukseni lopulta tulee julkaistua. Toivottavasti lopputuloksesta on iloa myös muille.

Löydä se mitä on vaikea nähdä

Tiimillämme on pyrkimyksenä pitää kahden viikon välein retroja. Jokainen valitsee vuorollaan aihepiirin, jonka puitteissa laittaa muut täyttämään post-it-lappuja, joita ryhmitellään etsien työskentelyn kipukohtia.

Tällä viikolla pääsimme isojen kysymyksien äärelle etsimällä asioita, jotka eri vaiheissa prosessia tuottavat arvoa, hämmennystä tai ajanhukkaa. Iso tussitaulu peittyi post-it-lapuilla minulle ennennäkemättömällä tavalla.

Suurimmaksi ongelmaksi keskustelussa nousivat isot muutostyöt, joissa usein speksauskin on hieman epämääräinen. Niitä on vaikea edistää, ne vievät paljon aikaa, ja niissä on tavanomaista suurempi riski päätyä tekemään vääriä asioita.

Se, minkä itse koin erityisen mielenkiintoiseksi, oli että puhuimme tavallaan ihan samoista asioista, joilla vain pari viikkoa aikaisemmin olin perustellut testausstrategian luomista: hyödyllistä puuhasteltavaa riittää aina, joten ikäviin tai hankaliin hommiin ei välttämättä koskaan tule tartuttua ainakaan riittävällä tarmolla, jos ei ole tiettyä kurinalaisuutta omassa tekemisessä. 

Siinä missä minä testaajana tarvitsen strategista ajattelua edes nähdäkseni ne kokonaisuudet, jotka eivät mukavuusalueella pysytellen tule testatuksi, kehittäjä tarvitsee kurinalaisuutta ja strategista ajattelua jotta nuo isot ja vaikeat kokonaisuudet saataisiin pilkottua ja tehtyä pois alta. Vaihtoehto on, että niitä joko vältellään, tai edistetään vastahakoisesti mitenkuten milloin ehditään. Ja kun ympärillä tapahtuu koko ajan, rakennettava tuote saa jatkuvasti uusia ominisuuksia, pieniä parannuksia tai vähintään bugifiksejä, vältellen ja nitkutellen edistettävät kokonaisuudet helposti kasvavat, muuttuen yhä vaikeammiksi toteuttaa loppuun asti. 

Ja lopulta aika usein ne hankalimmin edistettävät asiat ovat kuitenkin tärkeitä.

Keskustelimme tavoista, joilla näiden isojen asioiden edistymistä voisi nopeuttaa, ja pohdimme syitä jotka ovat estäneet tässä onnistumista. (Ja vain pari päivää myöhemmin kävimmekin yhteistuumin pilkkomaan yhtä elefanttia.)

Jälkikäteen aloin muistella asioita, joita olen pitänyt testaajan urani suurimpina saavutuksina. Niistä lopulta aika harvat liittyvät tilanteisiin, joissa olen löytänyt bugin toteutetusta järjestelmästä. Parhaita ovat olleet hetket, kun olen keksinyt esittää kysymyksen, joka on paljastanut vältellyn aiheen. Usein ne ovat olleet asioita, jotka ovat selvästi vaivanneet kehittäjiä itseäänkin, mutta kissaa ei ole tullut nostettua pöydälle koska ei ole ollut pakko, ja muita, akuutimpia asioita on riittänyt enemmän kuin omiksi tarpeiksi. Joskus kyse on ollut asioista, jotka vain on ymmärretty eri tavoin, eikä kukaan ole pysähtynyt ajattelemaan asiaa huomatakseen ongelman laajuutta.

Kun puhutaan laadunvarmistuksesta, softan testaaminen on vain pieni osa kokonaisuutta. Vaikutuksiltaan merkittävintä on löytää niitä asioita, joita vältellään tai ei edes nähdä. Vaikeaa tästä tekee se, että testaajan näkökulmasta ne kaikki saattavat olla näkymättömiä. Kehittäjän taas voi olla vaikea nähdä juuri näiden asioiden esiin nostamista oleellisena, ne voivat tuntua joko vähäpätöisiltä tai kaikkien tuntemilta kollektiivisesti vaietuilta asioilta, mikäli niiden olemassaoloon edes kiinnitetään huomiota.

Tässä mielessä retrot ovat loistavia. Loistavia ovat myös hetket, kun löytää paljastavia kysymyksiä. Hyvä alku ovat "miten tämän voi testata", "kuka tätä käyttää", "mihin tämä vaikuttaa" ja "miksi tämä asia ei ole edennyt".

Testaajien ja kehittäjien välillä on joskus melko voimakastakin vastakkainasettelua. Itse pidän enemmän yhteistyömeiningistä. Toivon, että kehittäjät voivat nähdä minun ongelmani yhteisinä ongelminamme. Tämän viikkoinen retro konkretisoi itselleni myös sitä sinänsä aika itsestäänselvää asiaa, että myös kehittäjien ongelmat ovat minun ongelmiani. Lopultahan ne testaajan turhauttavimmat pulmat liittyvät usein juuri asioihin, joista myös kehittäjä on ollut epävarma. Meistä jokainen tekee osansa löytääkseen ja selkiyttääkseen epämääräisiä asioita. Myös minun tehtäväni on tarttua tähän työhön mahdollisimman varhaisessa vaiheessa.

Ninjakin tarvitsee mestaria

Testaus on käsityöläisammatti, jonka oppimiseen on vain yksi tie: harjoitus. Työn tekeminen ja tulosten kriittinen analysointi ovat edellytys sille, että voi osata testausta.

Käsityöläisammatit eivät kuitenkaan ole kehittyneet vain yksittäisten ihmisten kekseliäisyyden varassa. Ammattilaiseksi kehitytään mestarin ohjauksessa, ja mestareista parhaat ovat hakeneet oppia useammaltakin mestarilta, tyypillisesti myös ulkomailta.

Tavallaan testausta voidaan verrata myös kamppailulajien harjoittelemiseen. Opetellaan uusia tekniikoita, hiotaan niitä, opetellaan tunnistamaan tilanteita joissa niitä käytetään, ja opetellaan käyttämään niitä tehokkaasti. Hyvät harjoitukset rakennetaan vastaamaan mahdollisimman realistisia todellisia tilanteita.

Myös jokaisella dojolla on oma mestarinsa, jonka oppeja seurataan, vaikka opetuksesta tyypillisesti huolehtiikin joku muu.

Nykypäivänä emme ole täysin suullisen tiedon varassa. Kirjastoista ja netistä löytää tietoa niin käsitöistä, kamppailulajeista kuin testauksestakin. Pyörää ei tarvitse keksiä kokonaan itse, vaikka ei mestarin ohjauksesta saisikaan nauttia.

Silti, ilman ohjausta voi olla vaikea löytää tietään parhaan tiedon luo. Tarvitaan myös mahdollisuuksia kysymiseen ja keskustelemiseen. Näihinkin netti tarjoaa onneksi mahdollisuuksia.

Netin kautta mestari ei kuitenkaan voi korjata virheellistä ranteen asentoa tai jalan väärää liikerataa. Tekniikan hioutumiseen on mahdollisuuksia vain siellä, missä oppija itse näkee tarpeen kehittymiselle.

Voiko myöskään testauksessa koskaan toteuttaa täyttä potentiaaliaan, jos ei saa tilaisuuksia harjoitella yhdessä mestarin kanssa?

Testaaja - koodarin vihollinen vai puolustaja?

Testaajien ja kehittäjien yhteistyö ei ole aina ihan kitkatonta.

Kun testaajan eteen tuodaan jotain valmiiksi väitettyä, jonka testaaminen on hidasta koska koko ajan löytyy raportoitavaa, on haasteellista tuoda löydöksiä esiin tavalla, jota hiukankin herkkähipiäinen kehittäjä ei kokisi osin henkilökohtaisuuksiin menevänä nipottamisena. Aikataulu- ja budjettipaineet kiristävät molempien pinnaa, samoin kaikenlaiset "tyhmät" virheet.

Erityisesti kun kyse on valmisohjelmistoon tehtävistä muutoksista, vastaan voi myös tulla vanhaan koodiin liittyviä ongelmia, joiden kiertämisen haasteellisuus siirtää helposti keskustelun korjaustavan etsinnästä bugin merkityksen vähäisyyden perusteluun. Näissä tilanteissa osapuolten voi olla vaikea nähdä tekevänsä yhteistyötä, ennemminkin tuntemukset molemmin puolin risteilevät ärtymyksessä, miksi muutenkin niukkaa aikaa on käytettävä johonkin näin turhauttavaan.

Testaajan tehtävä ei kuitenkaan ole mollata kehittäjää väärin tehdystä työstä, vaan auttaa tätä tekemään työnsä hyvin.

Erityisesti silloin kun testauksesta puhutaan laadunvarmistuksena, testaajan tehtävä on merkittäviä virheitä löytäessään viedä projektin johtoon viestiä, että kehittäjien mahdollisuudet tehdä työnsä hyvin on taattava.

Laatua kun on vaikea saada aikaan, jos sen tekijöillä ei ole tarpeeksi aikaa, tarpeeksi mahdollisuuksia keskittyä, tai tarpeeksi ohjausta.

Harva koodari tekee ihan vaan piittaamattomuuttaan virheitä, ja kokonaisuuden kannalta edullisinta olisi, jos mahdollisimman moni toimintalogiikkaan liittyvä tai muuten merkittävä virhe jäisi kiinni jo silloin kun niitä ollaan kirjoittamassa.

Tässä mielessä olisi myös hienoa, jos testausta ei nähtäisi vain valmiin tuotteen toiminnan verifiointina.

Testaaja voi auttaa ehkäisemään virheitä mm. katselmoimalla määritys- ja suunnitteludokumentteja, esittämällä kysymyksiä sprinttipalavereissa, keskustelemalla rakenteilla olevasta toiminnallisuudesta kehittäjien kanssa, käymällä kehittäjän kanssa demoluonteisesti läpi toteutettua toiminnallisuutta, ja testaamalla hyvinkin keskeneräistä (kunhan hänellä on tieto siitä, mitä voi testata ja minkä ei ole tarkoituskaan vielä toimia). Tärkeää on löytää yhteinen tavoite tekemiselle.

Laatu ei parane testaamalla, vaan tekemällä paremmin.

Mitä bugille tapahtuu?

Kaikki tietävät, mitä ensin tapahtuu. Testaaja lähtee käymään läpi testitapauksia, hetken päästä prosessi katkeaa. Tilanne dokumentoidaan tekstein, kuvakaappauksin, nauhoittein, miten milloinkin, kuitenkin mahdollisimman yksityiskohtaisesti. Sitten se tallennetaan bugitietokantaan ja jäädään odottamaan korjausta.

Mutta mitä sitten tapahtuu?

Testaaminen on välttämätöntä toimintavarman ohjelmiston rakentamiseksi. Joskus voi kuitenkin käydä niin, että testaus tuottaa bugeja paljon nopeammin kuin niitä ehditään korjaamaan. Yksikin testaaja saattaa raportoida kymmeniäkin bugeja päivässä, ja samaan aikaan kehittäjät ovat ehkä kiinni uusien ominaisuuksien kehittämisessä tai jopa muissa projekteissa. Tai jos bugeja korjataankin, yksittäinen korjaus saattaa avata testaajalle tien löytää monta uutta bugia. Muutamassa päivässä bugitietokanta saadaan niin täyteen, että sen perkaaminen käy työstä. Ja todella se perkaaminen vie myös aikaa. Bugien korjaamista ohjataan käymällä listaa läpi, delegoimalla ja priorisoimalla. Kehittäjät etsivät itselleen mielekkäitä kokonaisuuksia korjattaviksi. Testaaja kahlaa läpi aktiivisten bugiraporttien listaa tarkistaakseen, muistiko eilen raportoida sen yhden kummallisen bugin, jonka selvittely jäi kesken, tai etsii viime viikolla löytyneen bugin täydentääkseen sen kuvausta uudella tilanteella, jossa sama ongelma toistuu. Kenties muukin projektihenkilöstö raportoi löytämiään bugeja joko suoraan samaan tietokantaan luoden duplikaatteja, tai kyselemällä sähköpostitse testaajalta, joko olet huomannut tämän ja tämän asian. Kehittäjien tehdessä uutta toiminnallisuudet saattavat myös muuttua tavalla, jonka myötä vaivalla dokumentoituja bugeja ei enää saada toistumaan, ja niiden moniportainen käsittely vie turhaan aikaa niin kehittäjiltä kuin testaajilta.

Ei kuulosta ihan hirveän tehokkaalta.

Soppa saadaan kasvamaan entisestään, kun kirjataan bugeina kaikki testaushavainnot, ja oletetaan, että ne hoituvat kehittäjien ja testaajien välisellä pingiksellä.

Testaaja ei kuitenkaan yleensä ole projektipäällikkö, ei suorassa yhteydessä asiakkaaseen eikä vastuussa määrityksestä tai vaikkapa käyttöliittymäsuunnittelusta. Tarkentavat kysymykset, joiden oleellinen sisältö on "pitääks tää oikeesti tehdä?" tai "mitä tää määrityksen kohta oikeesti tarkoittaa?" pitäisi ohjata jonnekin muualle. Esimerkiksi suoraan asiakkaalle. Testaaja kun ei voi yksinään antaa kehittäjälle lupaa oikaista.

Miten tilanteen sitten saisi pysymään hanskassa?

Bugien löydettävyyttä parannetaan paitsi hyvällä nimeämisellä myös linkityksillä (esim. käyttötapauksiin) ja luokitteluilla (esim. mihin toiminnallisuuteen liittyy). Sotkun syntymistä voi vähentää myös niin, että sovitaan tarkkaan testauksen tavoitteet, ja vain niihin liittyviä bugeja raportoidaan. Jätetään se kaikesta jännästä nipottaminen vähän myöhempään, kun keskeisimmät asiat toimivat. (Tämä toki tarkoittaa, että testaukseen on oltava käytettävissä riittävästi kalenteriaikaa, eli testaus on aloitettava heti kun toteutus on siinä vaiheessa, että testaaminen on mielekästä.) Voidaan myös jakaa testaushavainnot esim. bugeihin, keskeneräisiin toiminnallisuuksiin ja lähdemateriaalien ongelmiin, ja sopia näille toisistaan poikkeavat käsittelytavat. Kunhan projektissa mietitään, mitä testaukselta aikuisten oikeasti halutaan, ja miten organisoimalla se saadaan mahdollisimman hyvin tukemaan ja mahdollisimman vähän tukkimaan kehitystä.

Jos kaikki oikeasti tietävät, ettei olla vielä stabilointivaiheessa, on hyvä jos testaaja voi työskennellä kehittäjien lähellä, jolloin tieto kulkee myös ilman bugitietokantaa. Kysymyksiä on silloin helppo pallotella suullisesti, ja arvioida yhdessä, miten paljon testauspanoksia kannattaa laittaa mihinkin toiminnallisuuteen juuri nyt. Tätä keskustelua on toki mahdollista käydä sähköisestikin, jos vain kaikki osapuolet ymmärtävät sen olevan yhteinen etu.

Lopulta tärkeää on myös se, ettei pelätä nostaa kissaa pöydälle. Jos toteutuksen ja testauksen lähdemateriaaleissa kuten määrityksessä on ongelmia, joiden takia ei ole mielekästä jatkaa, tieto tästä pitää saada mahdollisimman pian etenemään sinne, missä asioista päätetään. Ongelmien raportoiminen ei koskaan saa hilpeää vastaanottoa, mutta tämä asia ei yleensä odottamalla parane.Näiden maton alle lakaistujen asioiden esiin nostaminen on yksi testauksen tärkeimmistä tehtävistä, ja niiden edistämiseen onkin löydyttävä kanavat, joita käyttäen ongelmat myös ratkotaan.