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ö)
keskiviikko 1. syyskuuta 2010
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.
tiistai 20. huhtikuuta 2010
Paljonko testauksen pitää tuottaa hyötyä?
Vuodet testaushommissa ovat opettaneet, että testaajan tuottama lisäarvo ei ole lainkaan niin suoraviivaista, että testitapausten suunnittelun, suorituksen tai virhemäärien mittaamisella saataisiin kiinni sen tuottamasta arvosta. Testausnäkökulmalla ja testauksella on arvoa, se on hyödyllistä - usein.
Tämä ei kuitenkaan ole itsestäänselvyys. Olen aistivinani että testaus on tullut muotiin erityisesti asiakas-toimittajasuhteissa jopa siinä määrin, että koen että näissä tilanteissa vastaan on osunut kohtia, joissa testausotsikon alla tehty työ ei ehkä tuotakaan kovasti lisäarvoa.
Jos testauksessa käytetään varsin mittava työmäärä, tuotetaan kertakäyttötestitapauksia ko. projektin näkökulmaan ja katselmoidaan niitä suurella panoksella ja lopulta ei juurikaan löydetä ongelmia, voi minusta jo perustellusti miettiä että olikohan panokset oikein asetetut. Etenkin, jos jälkeen tulevat testausvaiheet osoittavat, että löydettävää kuitenkin olisi ollut.
Jos kohdalle osuu projekti, jonka osalta on perusteltua sanoa ettei se testaamalla juurikaan parane erilaisten reunaehtojen vuoksi, onko enää järkevää suositella että kuitenkin testaukseen panostetaan, ja vielä suuremmassa määrin. Vai voisiko testausihminen suositella jopa testaajien poistamista ja muiden ratkaisijoiden lisäämistä? Voisiko otos olla kattavuutta parempi tavoite hyötyjä ajatellen?
Välillä jää sellainen fiilis kaivertamaan, että erityisesti testauspalveluja tarjoavat osaoptimoivat testauksen, eivätkä ajattele testausta osana arvoketjua. Samoja tavoitteita voisi edistää halvemmilla ja tehokkaammilla keinoilla. Vai onko testausasiantuntijan kädet tosiaan niin sidottu ettei lähimaailmaa saa nytkäytettyä lähemmäs raiteita? En usko.
Tämä ei kuitenkaan ole itsestäänselvyys. Olen aistivinani että testaus on tullut muotiin erityisesti asiakas-toimittajasuhteissa jopa siinä määrin, että koen että näissä tilanteissa vastaan on osunut kohtia, joissa testausotsikon alla tehty työ ei ehkä tuotakaan kovasti lisäarvoa.
Jos testauksessa käytetään varsin mittava työmäärä, tuotetaan kertakäyttötestitapauksia ko. projektin näkökulmaan ja katselmoidaan niitä suurella panoksella ja lopulta ei juurikaan löydetä ongelmia, voi minusta jo perustellusti miettiä että olikohan panokset oikein asetetut. Etenkin, jos jälkeen tulevat testausvaiheet osoittavat, että löydettävää kuitenkin olisi ollut.
Jos kohdalle osuu projekti, jonka osalta on perusteltua sanoa ettei se testaamalla juurikaan parane erilaisten reunaehtojen vuoksi, onko enää järkevää suositella että kuitenkin testaukseen panostetaan, ja vielä suuremmassa määrin. Vai voisiko testausihminen suositella jopa testaajien poistamista ja muiden ratkaisijoiden lisäämistä? Voisiko otos olla kattavuutta parempi tavoite hyötyjä ajatellen?
Välillä jää sellainen fiilis kaivertamaan, että erityisesti testauspalveluja tarjoavat osaoptimoivat testauksen, eivätkä ajattele testausta osana arvoketjua. Samoja tavoitteita voisi edistää halvemmilla ja tehokkaammilla keinoilla. Vai onko testausasiantuntijan kädet tosiaan niin sidottu ettei lähimaailmaa saa nytkäytettyä lähemmäs raiteita? En usko.
keskiviikko 3. maaliskuuta 2010
Me ollaan testaajia kaikki
Jossain verkossa surffaillessani GoogleAds päätti näyttää minulle kohdistetusti mainoksen, jossa Reaktor etsi "koodaavaa pääarkkitehtiä". Paikka ei ole kyllä missään määrin minulle kohdistettu, mutta termiin liittyvä teema sattui olemaan testauspuolelta juuri pohdiskelun alla.
Jos mietitään karkeasti ohjelmistokehityksen rooleja, niitä olisi kaiketi kolme: vaatimuskaveri, toteutuskaveri ja testauskaveri. Näistä kuka vaan voisi nk. edetä urallaan hallintovaihteelle ja ryhtyä vaikka projektipäälliköksi. Toteutuskaverista tulee kuitenkin omalla vaihteellaan edetessään arkkitehti, ja testauskaverista testauspäällikkö.
Erityisesti olen ihmetellyt viime aikoina sitä, että toteuttaja joka pomppaa projektipäälliköksi ei yleensä enää kuvaa itseään koodaajana. Testaaja joka siirtyy testauspäälliköksi on hyvinkin vahvasti edelleen testaaja. Erityisesti tämä jäi minua mietityttämään sen vuoksi, että olen ollut huomaavinani, että varsin monet testausasiantuntijat eivät olekaan henkilökohtaisesti vuosikausiin testanneet. Toiset, kuten minä, testaavat kepoisasti silloin tällöin, nauttien pinnallisista mutta silti korjauskelpoisista virheistä joita rajatussa ajassa voi löytää. Koen tiettyä tuskaa, kun niin suuri osa ajasta kuluu ohjatessa, neuvotellessa, mittareita kehitellessä ja nauttien katsoessa kun toiset tekevät rakastamaani työtä hyvin. Kai se on jonkinasteista kateutta. :)
Olen vakuuttunut, että testaus on sekä taito että ajatusmalli. Taito katoaa jos työtä ei harjoita. Ajatusmalli säilyy. Taitopuolella etääntyminen on liian helppoa, kuvaten työtä edelleen kuitenkin samalla sanalla - me ollaan testaajia kaikki, nekin meistä jotka eivät ehdi muilta testaustöiltään testaamaan.
Jos mietitään karkeasti ohjelmistokehityksen rooleja, niitä olisi kaiketi kolme: vaatimuskaveri, toteutuskaveri ja testauskaveri. Näistä kuka vaan voisi nk. edetä urallaan hallintovaihteelle ja ryhtyä vaikka projektipäälliköksi. Toteutuskaverista tulee kuitenkin omalla vaihteellaan edetessään arkkitehti, ja testauskaverista testauspäällikkö.
Erityisesti olen ihmetellyt viime aikoina sitä, että toteuttaja joka pomppaa projektipäälliköksi ei yleensä enää kuvaa itseään koodaajana. Testaaja joka siirtyy testauspäälliköksi on hyvinkin vahvasti edelleen testaaja. Erityisesti tämä jäi minua mietityttämään sen vuoksi, että olen ollut huomaavinani, että varsin monet testausasiantuntijat eivät olekaan henkilökohtaisesti vuosikausiin testanneet. Toiset, kuten minä, testaavat kepoisasti silloin tällöin, nauttien pinnallisista mutta silti korjauskelpoisista virheistä joita rajatussa ajassa voi löytää. Koen tiettyä tuskaa, kun niin suuri osa ajasta kuluu ohjatessa, neuvotellessa, mittareita kehitellessä ja nauttien katsoessa kun toiset tekevät rakastamaani työtä hyvin. Kai se on jonkinasteista kateutta. :)
Olen vakuuttunut, että testaus on sekä taito että ajatusmalli. Taito katoaa jos työtä ei harjoita. Ajatusmalli säilyy. Taitopuolella etääntyminen on liian helppoa, kuvaten työtä edelleen kuitenkin samalla sanalla - me ollaan testaajia kaikki, nekin meistä jotka eivät ehdi muilta testaustöiltään testaamaan.
keskiviikko 24. helmikuuta 2010
Testauksen opettaminen - onko kaikki vaan peruskursseja?
Tieturin testausseminaarissa Tieturin testauskouluttaja Teppo Heikurinen kertoi puheenvuorossaan testaajien erilaisista profiileista ja tarpeista. Osana puheenvuoroaan Teppo esitti myös varsin vahvan väitteen siitä että kaikki testauskoulutus Suomessa on vain peruskursseja, joka luonnollisesti särähti omaan testauskouluttajakorvaani. Mitä ovat perusasiat ja mikä on edistyneempää testauksessa.
James Bach on mielestäni upeasti kuvannut suuren osan testauskurssisisällöistä termillä "testing folklore" - testauksen kansantiedettä. Kerromme kursseilla tarinoita testauksesta, opimmekin tarinoiden perusteella. Itse näkisin että opimme sekä perusasioita, että syvemmälle meneviä.
Toinen suuntaus testauskursseissa on sitten yritys opettaa testaamaan, eikä vain sujuvasti puhumaan testauksesta. Tässä suuntauksessa yleensä lähdetään siitä että testaus ei tapahtu paperiopetuksella, vaan testaukselle tarvitaan asennettu kohde. Ja niiltä osin kuin opetus tapahtuu luokkahuoneessa ilman konetta, harjoituspainotteisuus kuvista ja teksteistä analysoiden on vahvoilla.
Mikä on siis peruskurssi? Mitä ovat "testauksen perusteet"? Uskoisin pääseväni ISTQB-sertifikaattia syvemmälle, ja tuntuu pahalta ajatella että koulutan 20 päivää perusteita silti asioita suuressa määrin toistamatta. Niinkin toki voi olla.
Luin Cem Kanerin materiaalia tutkivasta testausautomaatiosta (exploratory test automation). Materiaalissa johdantona oli erinomainen jäsennys siitä että lähtien taidottomasta, edeten pikkukikkojen kautta tuottavaan ja lopulta oikeasti testausta osaavaan vaatii aikalailla erilaista koulutusta. Suhteessa tähän tunnustan: opetukseni taso on edelleen pikkukikkojen (quicktests, techniques) tasolla. Kuten Cem Kaner asian muotoili: "There are generically useful approaches to test design, like quicktests and tours and other basic techniques, but I think we add our greatest value when we apply a deeper understanding of the application. Testing instructors don’t teach this well because it takes so long to build a classroom-wide understanding of an application that is complex enough to be interesting."
Perusteissa siis mennään. Ja perusteissakin on eroja. :)
James Bach on mielestäni upeasti kuvannut suuren osan testauskurssisisällöistä termillä "testing folklore" - testauksen kansantiedettä. Kerromme kursseilla tarinoita testauksesta, opimmekin tarinoiden perusteella. Itse näkisin että opimme sekä perusasioita, että syvemmälle meneviä.
Toinen suuntaus testauskursseissa on sitten yritys opettaa testaamaan, eikä vain sujuvasti puhumaan testauksesta. Tässä suuntauksessa yleensä lähdetään siitä että testaus ei tapahtu paperiopetuksella, vaan testaukselle tarvitaan asennettu kohde. Ja niiltä osin kuin opetus tapahtuu luokkahuoneessa ilman konetta, harjoituspainotteisuus kuvista ja teksteistä analysoiden on vahvoilla.
Mikä on siis peruskurssi? Mitä ovat "testauksen perusteet"? Uskoisin pääseväni ISTQB-sertifikaattia syvemmälle, ja tuntuu pahalta ajatella että koulutan 20 päivää perusteita silti asioita suuressa määrin toistamatta. Niinkin toki voi olla.
Luin Cem Kanerin materiaalia tutkivasta testausautomaatiosta (exploratory test automation). Materiaalissa johdantona oli erinomainen jäsennys siitä että lähtien taidottomasta, edeten pikkukikkojen kautta tuottavaan ja lopulta oikeasti testausta osaavaan vaatii aikalailla erilaista koulutusta. Suhteessa tähän tunnustan: opetukseni taso on edelleen pikkukikkojen (quicktests, techniques) tasolla. Kuten Cem Kaner asian muotoili: "There are generically useful approaches to test design, like quicktests and tours and other basic techniques, but I think we add our greatest value when we apply a deeper understanding of the application. Testing instructors don’t teach this well because it takes so long to build a classroom-wide understanding of an application that is complex enough to be interesting."
Perusteissa siis mennään. Ja perusteissakin on eroja. :)
Oppeja testitapauksia vastaan
Olin viime vuonna lukenut nopeasti James Bachin esitysmateriaalin testitapauksia vastaan, ja eksyin siihen enemmän ajatuksella siivotessani kirjanmerkkejäni. Alkuperäisteos jota jäin pohtimaan löytyy täältä:
http://www.satisfice.com/presentations/againsttestcases.pdf
Erityisen viehättävä osa materiaalissa oli testauspandemiasanaleikit, 3 * OCD:
- Obsessive Case Disorder. Pakonomainen tarve uskoa ja antaa muiden uskoa että testitapausten suunnittelu on niin keskeinen aktiviteetti, että se sisältää kaiken testausajattelun ja suoritus on sitten mekaanista. Yleensähän annamme uskoa, kun ei vaan joka kerta jaksa selittää. On helpompaa sanoa että aikaa on varattava testitapausten suunnittelulle, eikä koittaa selittää että aikaa on itse asiassa varattava siihen että ehditään perehtyä vaatimusdokumentaatioon kirjattuihin lupauksiin ja olettamiin.
- Obsessive Counting Disorder. Pakonomainen tarve laskea testitapauksia, joiden laskemisella ei oikeasti ole niin suurta merkitystä. Pieni määrä ei korreloi huonon testauksen kanssa. Mutta, itse ainakin taas tänään totesin, että testitapausten laskeminen suhteessa jonkinlaiseen ideaan kattavuuskriteeristä antaa edes jonkinlaisen tuntuman siihen minkä verran lisää pitäisi vielä suunnitella / kirjata. Tarpeellista ja hyödyllistä tällä tasolla vain kun ei ole oikein vakuuttunut tekemisen otteesta muutenkaan.
- Overspecified Cases Disease. Epäjohdonmukainen pakkomielle kohdella ihmisiä automaatiorobotteina aivan liian tarkan dokumentaation myötä. Muodostuu usein sitten myös itseään toteuttavaksi ennusteeksi, suunnittelu oli jonkun muun nakki ja minä vaan kliksuttelen ja katson mitä käskettiin...
Pandemia - maailmanlaajuinen vitsaus - sinänsä ainakin minulle kolkuttelee jotain tosi tuttua...
Erinomaisia korostuksia myös siitä miksi testitapausten lukumäärään pitäisi aina suhtautua varauksella:
- eri suoritusaika muuttaa testitapausta: jos samaa asiaa katsoo kolmatta kertaa, ei varmasti tee samaa testiä, saattaa tehdä suppeampaa tai laajempaa
- testien suunnittelu on subjektiivista: vaikka sovittaisiin yhteinen muoto ja määrä, silti on vaihtelua, koska testauksen kohteet ovat erilaisia
- testaajat eivät edes noudata testitapauksia: monestihan testitapauksia kuittaillaan suoritetuksi sitten kun "tähän liittyvät vapaat tarkastelut on ehkä jo riittävässä määrin tehty". Olen joskus itsekin ihmetellyt kun viiden minuutin tarkistus kesti testaajalla kaksi viikkoa, ympärillä oli vaan aika monta asiaa jotka tähän tehtävään piti mahduttaa.
- sama testi automaation ja ihmisen suorittamana ei ole sama testi. Ihmisen päässä tapahtuu asioita joita ei voida siirtää automaatioon, mutta joskus se ei haittaa - jos se vain tiedostetaan.
Itse kirjoitan testitapauksia, periaatteella muistilistaa testattavien asioiden monipuolisuudesta. Minua vaivaa ainakin aika vahvasti tuo OCD v.2 jossa lasketaan asioita, mutta laskemisesta haen puitteita enkä absoluuttista totuutta. Ja tilanteesta riippuen tulisi laskettua vähän eri asioita, riippuen paljolti siitä mitä voi laskea puitteiden vuoksi. Testitapaukset on helpoimmasta päästä laskettavia asioita testauksessa.
http://www.satisfice.com/presentations/againsttestcases.pdf
Erityisen viehättävä osa materiaalissa oli testauspandemiasanaleikit, 3 * OCD:
- Obsessive Case Disorder. Pakonomainen tarve uskoa ja antaa muiden uskoa että testitapausten suunnittelu on niin keskeinen aktiviteetti, että se sisältää kaiken testausajattelun ja suoritus on sitten mekaanista. Yleensähän annamme uskoa, kun ei vaan joka kerta jaksa selittää. On helpompaa sanoa että aikaa on varattava testitapausten suunnittelulle, eikä koittaa selittää että aikaa on itse asiassa varattava siihen että ehditään perehtyä vaatimusdokumentaatioon kirjattuihin lupauksiin ja olettamiin.
- Obsessive Counting Disorder. Pakonomainen tarve laskea testitapauksia, joiden laskemisella ei oikeasti ole niin suurta merkitystä. Pieni määrä ei korreloi huonon testauksen kanssa. Mutta, itse ainakin taas tänään totesin, että testitapausten laskeminen suhteessa jonkinlaiseen ideaan kattavuuskriteeristä antaa edes jonkinlaisen tuntuman siihen minkä verran lisää pitäisi vielä suunnitella / kirjata. Tarpeellista ja hyödyllistä tällä tasolla vain kun ei ole oikein vakuuttunut tekemisen otteesta muutenkaan.
- Overspecified Cases Disease. Epäjohdonmukainen pakkomielle kohdella ihmisiä automaatiorobotteina aivan liian tarkan dokumentaation myötä. Muodostuu usein sitten myös itseään toteuttavaksi ennusteeksi, suunnittelu oli jonkun muun nakki ja minä vaan kliksuttelen ja katson mitä käskettiin...
Pandemia - maailmanlaajuinen vitsaus - sinänsä ainakin minulle kolkuttelee jotain tosi tuttua...
Erinomaisia korostuksia myös siitä miksi testitapausten lukumäärään pitäisi aina suhtautua varauksella:
- eri suoritusaika muuttaa testitapausta: jos samaa asiaa katsoo kolmatta kertaa, ei varmasti tee samaa testiä, saattaa tehdä suppeampaa tai laajempaa
- testien suunnittelu on subjektiivista: vaikka sovittaisiin yhteinen muoto ja määrä, silti on vaihtelua, koska testauksen kohteet ovat erilaisia
- testaajat eivät edes noudata testitapauksia: monestihan testitapauksia kuittaillaan suoritetuksi sitten kun "tähän liittyvät vapaat tarkastelut on ehkä jo riittävässä määrin tehty". Olen joskus itsekin ihmetellyt kun viiden minuutin tarkistus kesti testaajalla kaksi viikkoa, ympärillä oli vaan aika monta asiaa jotka tähän tehtävään piti mahduttaa.
- sama testi automaation ja ihmisen suorittamana ei ole sama testi. Ihmisen päässä tapahtuu asioita joita ei voida siirtää automaatioon, mutta joskus se ei haittaa - jos se vain tiedostetaan.
Itse kirjoitan testitapauksia, periaatteella muistilistaa testattavien asioiden monipuolisuudesta. Minua vaivaa ainakin aika vahvasti tuo OCD v.2 jossa lasketaan asioita, mutta laskemisesta haen puitteita enkä absoluuttista totuutta. Ja tilanteesta riippuen tulisi laskettua vähän eri asioita, riippuen paljolti siitä mitä voi laskea puitteiden vuoksi. Testitapaukset on helpoimmasta päästä laskettavia asioita testauksessa.
Kohtuulliset odotukset testaustoimittajalle
Tehtyäni takinkäännön - edelleen uskollisena testaukselle - ohjelmistotuoteliiketoiminnasta omiin räätälöitäviin tilaustyönä hankittaviin järjestelmiin, olen jäänyt monesti pohtimaan odotuksia kohtuulliselle testaukselle.
Päivän listani on asioita jotka ovat minusta kovin kohtuullisia, mutta jättävät silti miettimään:
- Testaaminen asiakasnäkökulmasta
Tuoteliiketoiminnassa oli selvää, että järjestelmätestausporukka epäonnistuu pahasti, jos hyvin tehdyt vaatimusmäärittelyt otetaan liian kirjaimellisesti, eikä edes koiteta merkittävässä määrin huomioida asiakkaan / käyttäjän hiljaisia vaatimuksia sekä kaikkea sitä teknistä nippelinappelitietoa, joka voi jäädä vaatimusten ja määrittelyjen väliin. Räätälöitävien järjestelmien peruselementti tuntuisi olevan "vaatimusmäärittely" joka kuvaa tilatun järjestelmän, jota tarkennetaan ja jonka rivien väliin jääneet yksityiskohdat ovat aina muutospyyntöjä. Ja eivät löydy toimittajan testauksissa. Niinpä asiakkaan testaajien ja toimittajan testaajien välillä on kuilu, joka korostuu kahdenlaisessa hyväksymistestauksessa: on aivan eri asia suorittaa sopimushyväksymistestausta kuin tuotantoonhyväksymistestausta - valitettavasti.
- Näkyvyys ja raportointi projektiin testauksen kautta
Tuoteliiketoiminnassa tuntui varsin selkeältä katsoa tehtävää testausta kokonaisuutena mittarein. Työmäärän kulumisen lisäksi kiinnosti testauksella saatu lisäarvo, niin kattavuuden kuin tulostenkin osalta. Räätälöityjen maailmassa en pidä itsestään selvänä että testauksesta saisi mitään muuta raporttia kuin että budjetoidut tunnit nyt tuli käytettyä. Aiemmassa elämässä tästä minulla onkin ollut tosi ikäviä kokemuksia, ja toivon että ne kokemukset eivät päätyisi värittämään tulevaisuutta toistuvin kaavoin.
- Mallipohjan täyttäminen ajatuksella
Kun testaussuunnitelmassa pitää miettiä mallipohjan ohjauksella jotain, sitä jotenkin ajattelisi ja kuvittelisi että viime kädessä sisällöllä on merkitystä. Muoto on tärkeä kun luetaan rutiininomaisesti toistuvia suunnitelmia ja halutaan katsoa vastaavat teemat vastaavassa järjestyksessä, mutta silloinkin hyvän ja heikon suunnitelman erottaa ajattelu ja asioiden huomioiminen eikä vaan vakioliturgian kirjaaminen.
- Riskienhallinta - testauksen edellytykset voivat olla projektin tuho
Tuoteliiketoiminnan jälkeen on vaikeaa myös nähdä syitä siihen että testauksen on arvostussyistä oltava oma organisaationosansa tai että testaus pitää ehdottomasti projektoida omana kokonaisuutenaan, että saadaan kertoa realistista tilannetta kokeilluista ja ei-toimivista asioista. Minua ei henkilökohtaisesti yhtään lohduta että olin oikeassa kun sanoin että testaus voi voi tapahtua kahdessa viikossa jos testausympäristö ei toimi, jos siinä vaiheessa projekti on myöhässä eikä ole tullut edes ehdotettua vaihtoehtoista jonkinasteista lisäkustannusta toipumissuunnitelmaksi niille keskeisimmille riskeille.
Listan viimeistä pidän jo vähän edistyneempänä kamana, mutta muita ihan peruskaurana. Saas nähdä miten mieli vielä muuttuu...
Päivän listani on asioita jotka ovat minusta kovin kohtuullisia, mutta jättävät silti miettimään:
- Testaaminen asiakasnäkökulmasta
Tuoteliiketoiminnassa oli selvää, että järjestelmätestausporukka epäonnistuu pahasti, jos hyvin tehdyt vaatimusmäärittelyt otetaan liian kirjaimellisesti, eikä edes koiteta merkittävässä määrin huomioida asiakkaan / käyttäjän hiljaisia vaatimuksia sekä kaikkea sitä teknistä nippelinappelitietoa, joka voi jäädä vaatimusten ja määrittelyjen väliin. Räätälöitävien järjestelmien peruselementti tuntuisi olevan "vaatimusmäärittely" joka kuvaa tilatun järjestelmän, jota tarkennetaan ja jonka rivien väliin jääneet yksityiskohdat ovat aina muutospyyntöjä. Ja eivät löydy toimittajan testauksissa. Niinpä asiakkaan testaajien ja toimittajan testaajien välillä on kuilu, joka korostuu kahdenlaisessa hyväksymistestauksessa: on aivan eri asia suorittaa sopimushyväksymistestausta kuin tuotantoonhyväksymistestausta - valitettavasti.
- Näkyvyys ja raportointi projektiin testauksen kautta
Tuoteliiketoiminnassa tuntui varsin selkeältä katsoa tehtävää testausta kokonaisuutena mittarein. Työmäärän kulumisen lisäksi kiinnosti testauksella saatu lisäarvo, niin kattavuuden kuin tulostenkin osalta. Räätälöityjen maailmassa en pidä itsestään selvänä että testauksesta saisi mitään muuta raporttia kuin että budjetoidut tunnit nyt tuli käytettyä. Aiemmassa elämässä tästä minulla onkin ollut tosi ikäviä kokemuksia, ja toivon että ne kokemukset eivät päätyisi värittämään tulevaisuutta toistuvin kaavoin.
- Mallipohjan täyttäminen ajatuksella
Kun testaussuunnitelmassa pitää miettiä mallipohjan ohjauksella jotain, sitä jotenkin ajattelisi ja kuvittelisi että viime kädessä sisällöllä on merkitystä. Muoto on tärkeä kun luetaan rutiininomaisesti toistuvia suunnitelmia ja halutaan katsoa vastaavat teemat vastaavassa järjestyksessä, mutta silloinkin hyvän ja heikon suunnitelman erottaa ajattelu ja asioiden huomioiminen eikä vaan vakioliturgian kirjaaminen.
- Riskienhallinta - testauksen edellytykset voivat olla projektin tuho
Tuoteliiketoiminnan jälkeen on vaikeaa myös nähdä syitä siihen että testauksen on arvostussyistä oltava oma organisaationosansa tai että testaus pitää ehdottomasti projektoida omana kokonaisuutenaan, että saadaan kertoa realistista tilannetta kokeilluista ja ei-toimivista asioista. Minua ei henkilökohtaisesti yhtään lohduta että olin oikeassa kun sanoin että testaus voi voi tapahtua kahdessa viikossa jos testausympäristö ei toimi, jos siinä vaiheessa projekti on myöhässä eikä ole tullut edes ehdotettua vaihtoehtoista jonkinasteista lisäkustannusta toipumissuunnitelmaksi niille keskeisimmille riskeille.
Listan viimeistä pidän jo vähän edistyneempänä kamana, mutta muita ihan peruskaurana. Saas nähdä miten mieli vielä muuttuu...
maanantai 18. tammikuuta 2010
Havainnot, virheet ja vaatimukset
En ole koskaan välittänyt mitenkään erityisesti ISEB/ISTQB:n terminologiasta, joka jaottelultaan on sinänsä selkiyttävä:
- error (virhe) on jotain mitä ihminen tekee.
- fault/defect (vika) on jotain mitä syntyy ohjelmistoon ihmisten tekemisten seurauksena
- failure (häiriö) on se mitä testaaja näkee kun ohjelmisto ei toimi
Tästä on päästy aina ihaniin keskusteluihin: virhetietokannat ovatkin itse asiassa häiriötietokantoja.
Olen tykännyt vetää mutkat suoriksi suomen kielellä, koska minusta tuo erottelu ja yritys täsmälliseen kielenkäyttöön ei ole koskaan taipunut suuhuni käytännön tasolla. On virheitä jotka ihmiset tekevät, on virheitä joita ohjelmistossa on ja virheitä joita näkyy ohjelmistoja käytettäessä.
Lempimääritelmäni testaajan kirjaamille havainnolle tulee kirjasta Lessons Learned in Software Testing: "Bug = anything that might bug a user". Korvaan sanan user = käyttäjä kuitenkin sanalla stakeholder = sidosryhmä. Testaajana lähtökohtaisesti minua ei oikeastaan ensisijaisesti kiinnosta että onko havaintoni virhe ohjelmistossa, virhe määrittelyissä vai muuten vaan keskeiseltä tuntuva parannusehdotus. Toki usein projekteissa seuraavana pohdiskeluna lajittelen havaintoni - periaatteena siis kuka mielestäni maksaa korjauksen. Ja kiitän onneani silloin kun sillä ei ole väliä, niinkuin tuoteliiketoiminnassa usein on ja asiakas-toimittajasuhteissa juuri koskaan ei ole.
Lähdin tätä päivän pohdintaa kuitenkin kirjoittamaan ajatuksenani virheen (vapaasti määritellen) ja vaatimuksen ero. Kuuntelin Elisabeth Hendricksonin esitystä XP-testauksesta ja ihastuin yhteen hänen pointeistaan. Hän kertoi kokemuksestaan ja oivalluksestaan että toteuttajien kanssa rinta rinnan työskennellessään oli tajunnut, että monet asiat joita hän testaajana tuo esiin palautteena ovat itse asiassa toteuttajan näkökulmasta uusia vaatimuksia. Toteuttaja ei ehkä koskaan ollut kuullut / ajatellut vaatimusta että cross-site scripting -hyökkäys ei pitäisi olla sallittua.
Toimin nyt lähellä liiketoimintaa ja asiakasta. Henkisesti ainakin toistaiseksi vastustan ajatusta että vaatimukset pitäisi tilaajan toimesta kertoa äärimmäisellä yksityiskohtien tasolla ja korostaa jokaista yksityiskohtaa: "kyllä, me tosiaan sammutamme tietokoneet käskystä viikonlopuksi" ja "ei, emme sammuta tietokoneitamme joka työpäivän päätteeksi ja joskus emme haluaisi sammuttaa niitä kuukausiin".
On vaatimuksia ja vaatimuksia. Osa ohjelmistovaatimuksista voi ja pitää mielestäni kohtuudella tulla tekijäporukalta. Ketterien menetelmien osana on oivallettu että testaaja, tutkivaa testausta hyödyntäen, pystyy työstämään tälläisiä tekijäporukan tasoisia vaatimuksia yhteentoimivuudesta, pitkistä ketjuista ja erilaisista oleellisista tilanteista. Tämä tieto ei kuitenkaan ole testaajan salatiedettä, vaan koko tiimin opiskelusisältöä.
Muistiinpano itselle: pitäisi taas tarkastella mihin vaatimusten hallinnan kirjallisuus nykyään ehdottaa tuon rajan menevän. Jo vuosia sitten tiedettiin ettei vaatimusdokumentaatioon saa kirjattua lähellekään kaikkea.
Ihanan latautuneita sanoja. Jatkan siis havaintojen tekemistä.
- error (virhe) on jotain mitä ihminen tekee.
- fault/defect (vika) on jotain mitä syntyy ohjelmistoon ihmisten tekemisten seurauksena
- failure (häiriö) on se mitä testaaja näkee kun ohjelmisto ei toimi
Tästä on päästy aina ihaniin keskusteluihin: virhetietokannat ovatkin itse asiassa häiriötietokantoja.
Olen tykännyt vetää mutkat suoriksi suomen kielellä, koska minusta tuo erottelu ja yritys täsmälliseen kielenkäyttöön ei ole koskaan taipunut suuhuni käytännön tasolla. On virheitä jotka ihmiset tekevät, on virheitä joita ohjelmistossa on ja virheitä joita näkyy ohjelmistoja käytettäessä.
Lempimääritelmäni testaajan kirjaamille havainnolle tulee kirjasta Lessons Learned in Software Testing: "Bug = anything that might bug a user". Korvaan sanan user = käyttäjä kuitenkin sanalla stakeholder = sidosryhmä. Testaajana lähtökohtaisesti minua ei oikeastaan ensisijaisesti kiinnosta että onko havaintoni virhe ohjelmistossa, virhe määrittelyissä vai muuten vaan keskeiseltä tuntuva parannusehdotus. Toki usein projekteissa seuraavana pohdiskeluna lajittelen havaintoni - periaatteena siis kuka mielestäni maksaa korjauksen. Ja kiitän onneani silloin kun sillä ei ole väliä, niinkuin tuoteliiketoiminnassa usein on ja asiakas-toimittajasuhteissa juuri koskaan ei ole.
Lähdin tätä päivän pohdintaa kuitenkin kirjoittamaan ajatuksenani virheen (vapaasti määritellen) ja vaatimuksen ero. Kuuntelin Elisabeth Hendricksonin esitystä XP-testauksesta ja ihastuin yhteen hänen pointeistaan. Hän kertoi kokemuksestaan ja oivalluksestaan että toteuttajien kanssa rinta rinnan työskennellessään oli tajunnut, että monet asiat joita hän testaajana tuo esiin palautteena ovat itse asiassa toteuttajan näkökulmasta uusia vaatimuksia. Toteuttaja ei ehkä koskaan ollut kuullut / ajatellut vaatimusta että cross-site scripting -hyökkäys ei pitäisi olla sallittua.
Toimin nyt lähellä liiketoimintaa ja asiakasta. Henkisesti ainakin toistaiseksi vastustan ajatusta että vaatimukset pitäisi tilaajan toimesta kertoa äärimmäisellä yksityiskohtien tasolla ja korostaa jokaista yksityiskohtaa: "kyllä, me tosiaan sammutamme tietokoneet käskystä viikonlopuksi" ja "ei, emme sammuta tietokoneitamme joka työpäivän päätteeksi ja joskus emme haluaisi sammuttaa niitä kuukausiin".
On vaatimuksia ja vaatimuksia. Osa ohjelmistovaatimuksista voi ja pitää mielestäni kohtuudella tulla tekijäporukalta. Ketterien menetelmien osana on oivallettu että testaaja, tutkivaa testausta hyödyntäen, pystyy työstämään tälläisiä tekijäporukan tasoisia vaatimuksia yhteentoimivuudesta, pitkistä ketjuista ja erilaisista oleellisista tilanteista. Tämä tieto ei kuitenkaan ole testaajan salatiedettä, vaan koko tiimin opiskelusisältöä.
Muistiinpano itselle: pitäisi taas tarkastella mihin vaatimusten hallinnan kirjallisuus nykyään ehdottaa tuon rajan menevän. Jo vuosia sitten tiedettiin ettei vaatimusdokumentaatioon saa kirjattua lähellekään kaikkea.
Ihanan latautuneita sanoja. Jatkan siis havaintojen tekemistä.
perjantai 15. tammikuuta 2010
Enkelin kärsivällisyys ja elefantin muisti
Kun tekee testaushommia ketjutettujen järjestelmien kanssa, tulee erityisen vahvasti sellainen fiilis että oma kärsivällisyys ja kapasiteetti ei meinaa riittää asioiden käsittelyyn ja läpivientiin.
Tässä testausmaailmassa ongelman löytäminen ei ole haaste. Ongelmien välissä luoviminen pidemmän päälle niin että löytää niistä merkittävän osan kun vanhoja ei tule korjattua on haaste. Ja ongelmista viestiminen on haaste.
Ensin pääsee yleensä keskustelemaan siitä että onko tehty havainto ongelmasta yleensäkään ongelma, vai voisiko jotenkin jo ihan käyttäjänä / testaajana tehdä jotain toisin - "eihän kukaan tee noin, ei ainakaan pitäisi". Sitten keskustelu jatkuu siitä onko havainto ongelmasta virhe suhteessa määrittelyyn vaiko määrittelymuutos, ja miten nämä määritellään. Lopulta vielä saatetaan ehdottaa että ketjussa korjaus pitäisi ollakin jossain ihan muualla kuin missä itse sitä kuvittelisi intuitiivisesti tarvittavan.
Tuntuu että testauksen tekeminen katoaa, kun testaajalta vaaditaan - otsikon mukaisesti - enkelin kärsivällisyys ja elefantin muisti.
Ketterien menetelmien korostuneita hyviä puolia on stop-and-fix mentaliteetti ja laatuvelan välttäminen. Valitettavasti vaan juuri tämä osa on yksi niitä vaikeammasta päästä olevia toteutettavia osia ketterään tekemiseen.
Tässä testausmaailmassa ongelman löytäminen ei ole haaste. Ongelmien välissä luoviminen pidemmän päälle niin että löytää niistä merkittävän osan kun vanhoja ei tule korjattua on haaste. Ja ongelmista viestiminen on haaste.
Ensin pääsee yleensä keskustelemaan siitä että onko tehty havainto ongelmasta yleensäkään ongelma, vai voisiko jotenkin jo ihan käyttäjänä / testaajana tehdä jotain toisin - "eihän kukaan tee noin, ei ainakaan pitäisi". Sitten keskustelu jatkuu siitä onko havainto ongelmasta virhe suhteessa määrittelyyn vaiko määrittelymuutos, ja miten nämä määritellään. Lopulta vielä saatetaan ehdottaa että ketjussa korjaus pitäisi ollakin jossain ihan muualla kuin missä itse sitä kuvittelisi intuitiivisesti tarvittavan.
Tuntuu että testauksen tekeminen katoaa, kun testaajalta vaaditaan - otsikon mukaisesti - enkelin kärsivällisyys ja elefantin muisti.
Ketterien menetelmien korostuneita hyviä puolia on stop-and-fix mentaliteetti ja laatuvelan välttäminen. Valitettavasti vaan juuri tämä osa on yksi niitä vaikeammasta päästä olevia toteutettavia osia ketterään tekemiseen.
perjantai 8. tammikuuta 2010
Parasta ennen päivämäärät testeillä
Projektipäällikkö on testauspäällikön ystävä. Onneksi näin välillä, valitettavasti ei vain aina. Aihetta pureskellessani erästä esitystä varten jäin miettimään erilaisia ongelmallisia suhteita projektipäälliköihin testauspäällikkönä toimiessani, ja olemaan hymyillen kiitollinen siitä hyvästä mitä joskus osuu kohdalle.
Ongelmalliset suhteet keskittyivät yleisesti ymmärryksen ja viestinnän ongelmiin. Jos itse on kovasti testaukseen ihastunut ja toisen osapuolen mielestä se on välttämätön paha ja oikeastaan sellaisenakin aika hyödytön, saattaa päätyä painokkaisiinkin sanakäänteisiin.
Eräs kohdalleni osunut varsin yleinen viestinnän ongelma projektipäälliköiden kanssa on koittaa selittää että testin tulokset eivät pysy vakiona. Erityisen tuskaisaksi tämä minulla on muodostunut ympäristöissä joissa on vahvasti mukana kaupallinen testauksen hallinnan työkalu, ja projektipäällikkö on "aseistettu" testauksen mittarein. Voi sitä projektipäällikköparkaa, joka koittaa tulkita edes kevyesti iteratiivisessa projektissa suoraan mittarista että onkos nyt kaikki testit suoritettu kertaalleen, kun minä mokoma omassa roolissani menen ja tyhjennän koko listan säännöllisin väliajoin.
Tästä pohdinnasta mieleeni muistui keskustelu erään kolleegan kanssa muutamia vuosia sitten. Hänellä oli ajatus parasta ennen päivämäärien käytöstä prosessidokumentaatiossa. Idea kaikessa yksinkertaisuudessaan oli että sen sijaan että prosessikuvaukseen pitäisi kirjoittaa päivä jolloin se on luotu, pitäisi viestinnällisistä syistä sanoa että kun se on ollut riittävän kauan olemassa, siihen pitäisi suhtautua vähän samoin kuin vanhentuneeseen maitopurkkiin.
Parasta ennen päivämäärät voisivat toimia testitapauksillakin mainiosti. Olen koittanut peukkulaaturaportoinnin yhteydessä harrastaa kolmatta peukkua kuvaamaan muutoksen määrää, eli tahtia jolla varaan oikeuden muuttaa mieltäni laadusta. Ajatusta vaatii minulta vielä hauduttelua, mutta tuntumaksi ajattelusta jäi että jokusen projektipäällikön kanssa olisi ollut yhteiselo helpompaa jos tälläisen konseptin olisi heti projektin alusta lanseerannut. Testien tulokset happanevat ja se kuinka nopeasti riippuu ympäristötekijöistä. Pitääkö ne sitten korvata tuoreemmilla onkin kokonaan toinen kysymys...
Pohdin projektipäälliköitä, mittareita ja ikuista viestinnän vaikeutta, kun muistiini palautui keskustelu muutaman vuoden takaa erään kolleegan kanssa parasta ennen päivämääristä ohjelmistoprosessidokumentaatiossa.
Ongelmalliset suhteet keskittyivät yleisesti ymmärryksen ja viestinnän ongelmiin. Jos itse on kovasti testaukseen ihastunut ja toisen osapuolen mielestä se on välttämätön paha ja oikeastaan sellaisenakin aika hyödytön, saattaa päätyä painokkaisiinkin sanakäänteisiin.
Eräs kohdalleni osunut varsin yleinen viestinnän ongelma projektipäälliköiden kanssa on koittaa selittää että testin tulokset eivät pysy vakiona. Erityisen tuskaisaksi tämä minulla on muodostunut ympäristöissä joissa on vahvasti mukana kaupallinen testauksen hallinnan työkalu, ja projektipäällikkö on "aseistettu" testauksen mittarein. Voi sitä projektipäällikköparkaa, joka koittaa tulkita edes kevyesti iteratiivisessa projektissa suoraan mittarista että onkos nyt kaikki testit suoritettu kertaalleen, kun minä mokoma omassa roolissani menen ja tyhjennän koko listan säännöllisin väliajoin.
Tästä pohdinnasta mieleeni muistui keskustelu erään kolleegan kanssa muutamia vuosia sitten. Hänellä oli ajatus parasta ennen päivämäärien käytöstä prosessidokumentaatiossa. Idea kaikessa yksinkertaisuudessaan oli että sen sijaan että prosessikuvaukseen pitäisi kirjoittaa päivä jolloin se on luotu, pitäisi viestinnällisistä syistä sanoa että kun se on ollut riittävän kauan olemassa, siihen pitäisi suhtautua vähän samoin kuin vanhentuneeseen maitopurkkiin.
Parasta ennen päivämäärät voisivat toimia testitapauksillakin mainiosti. Olen koittanut peukkulaaturaportoinnin yhteydessä harrastaa kolmatta peukkua kuvaamaan muutoksen määrää, eli tahtia jolla varaan oikeuden muuttaa mieltäni laadusta. Ajatusta vaatii minulta vielä hauduttelua, mutta tuntumaksi ajattelusta jäi että jokusen projektipäällikön kanssa olisi ollut yhteiselo helpompaa jos tälläisen konseptin olisi heti projektin alusta lanseerannut. Testien tulokset happanevat ja se kuinka nopeasti riippuu ympäristötekijöistä. Pitääkö ne sitten korvata tuoreemmilla onkin kokonaan toinen kysymys...
Pohdin projektipäälliköitä, mittareita ja ikuista viestinnän vaikeutta, kun muistiini palautui keskustelu muutaman vuoden takaa erään kolleegan kanssa parasta ennen päivämääristä ohjelmistoprosessidokumentaatiossa.
Tilaa:
Blogitekstit (Atom)