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.
keskiviikko 9. marraskuuta 2011
keskiviikko 1. syyskuuta 2010
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ö)
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ö)
tiistai 31. elokuuta 2010
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.
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.
torstai 26. elokuuta 2010
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.
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.
torstai 3. kesäkuuta 2010
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.
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.
sunnuntai 30. toukokuuta 2010
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.
- 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.
perjantai 21. toukokuuta 2010
Hyväksymistestauksen dokumentaation jakaminen toimittajalle
Keväällä IIR:n seminaarissa muutamassakin puheenvuorossa pohdittiin hyväksymistestauspuheenvuorojen osalta periaatetta dokumentaation jakelussa toimittajalle.
Testitapausten osalta silloin taisi vallitseva käsitys olla, että parempi olla antamatta. Syyt olivat kaiketi:
- Huoli siitä että toimittaja testaa vain näillä testeillä ja kokonaisuutena saadaan huonompaa laatua
- Riippuvuudet asiakkaan materiaaleihin aikataulullisesti sovittuina aiheuttavat tarpeettomia paineita asiakaspäässä materiaalin viimeistelyyn
- Asiakkaan materiaalin odottaminen antaa epävirallisen luvan luovuttaa oman testauksen valmistelun yrityksen kanssa ja vähentää vastuunottoa
Testitapausten osalta olen edelleen eri mieltä. Minusta ne kannattaa antaa. Parempi että edes ne toimivat, kuin että viimeisen hyväksymistestin aikana tarvitsee niistäkin huomata etteivät toimi. Kun lähtökohtaisesti lähtee siitä että testi ei ole äärimmäisen toistettava vaan lähinnä muistilistan omainen, näkisin että riskiä siitä että toimittaja kuvittelee vastuun testisuunnittelusta siirtyneen asiakaspäähän olisi hallittavissa. Ja korostetusti kannattaa varata oikeus ja mahdollisuus tutkivaan testaukseen, joka vielä entisestään täydentää suunniteltua kokonaisuutta.
Testaussuunnitelmat ovat minusta paljon haastavampi kysymys. Erityisesti nykymaailmassa missä lähestulkoon järjestelmä kuin järjestelmä koostuu eri tekijöiden osista, en aina ole ihan vakuuttunut että haluaisin avata kaikille osapuolille kaikki näkökulmat riskeihin, mitä osana hyväksymistestausta pitää pohtia. Jotkut asiat kun ovat vaan meidän organisaatiolle. Ja ainakaan minua ei kiinnosta tästä syystä että kirjaan suunnitelmaani nk. arkaluonteisia asioita ja arvioita pohjana riskiarvioilleni, kirjoittaa toista "siistittyä" suunnitelmaa. Sen osalta minusta saa riittää, että testaamme. Jos siinä on jotain minkä kertominen auttaa viestintää, pidän aiheesta mielellään silmäkkäin session. Ja sekin on tietysti lähestulkoon aina.
Testitapausten osalta silloin taisi vallitseva käsitys olla, että parempi olla antamatta. Syyt olivat kaiketi:
- Huoli siitä että toimittaja testaa vain näillä testeillä ja kokonaisuutena saadaan huonompaa laatua
- Riippuvuudet asiakkaan materiaaleihin aikataulullisesti sovittuina aiheuttavat tarpeettomia paineita asiakaspäässä materiaalin viimeistelyyn
- Asiakkaan materiaalin odottaminen antaa epävirallisen luvan luovuttaa oman testauksen valmistelun yrityksen kanssa ja vähentää vastuunottoa
Testitapausten osalta olen edelleen eri mieltä. Minusta ne kannattaa antaa. Parempi että edes ne toimivat, kuin että viimeisen hyväksymistestin aikana tarvitsee niistäkin huomata etteivät toimi. Kun lähtökohtaisesti lähtee siitä että testi ei ole äärimmäisen toistettava vaan lähinnä muistilistan omainen, näkisin että riskiä siitä että toimittaja kuvittelee vastuun testisuunnittelusta siirtyneen asiakaspäähän olisi hallittavissa. Ja korostetusti kannattaa varata oikeus ja mahdollisuus tutkivaan testaukseen, joka vielä entisestään täydentää suunniteltua kokonaisuutta.
Testaussuunnitelmat ovat minusta paljon haastavampi kysymys. Erityisesti nykymaailmassa missä lähestulkoon järjestelmä kuin järjestelmä koostuu eri tekijöiden osista, en aina ole ihan vakuuttunut että haluaisin avata kaikille osapuolille kaikki näkökulmat riskeihin, mitä osana hyväksymistestausta pitää pohtia. Jotkut asiat kun ovat vaan meidän organisaatiolle. Ja ainakaan minua ei kiinnosta tästä syystä että kirjaan suunnitelmaani nk. arkaluonteisia asioita ja arvioita pohjana riskiarvioilleni, kirjoittaa toista "siistittyä" suunnitelmaa. Sen osalta minusta saa riittää, että testaamme. Jos siinä on jotain minkä kertominen auttaa viestintää, pidän aiheesta mielellään silmäkkäin session. Ja sekin on tietysti lähestulkoon aina.
Tilaa:
Blogitekstit (Atom)