Tag: Suomi

Tarjoaako Facebook joskus hauskoja muistoja vuosien varrelta? Omasta feedistäni nousi esiin video vuodelta 2016. Siinä oli autokolari. Ei ollut hauska. Mutta herätti ajatuksia.

Kun napautat äänet päälle tätä filkkaa katsoessa saatat huomata jotain kiinnostavaa. Teslan varoitusääni nimittäin kuuluu reilusti yli sekunnin ennen itse tapahtumaa. Ajoneuvon tekniikka siis osaa ennustaa tulevaisuutta. Se näkee tilanteen syntymisen ennen kuin ihmissilmä ehtii.

Teknologian tehokkuudella on Mooren lain mukaan taipumus tuplaantua säännöllisin välein. Dataintensiivisillä järjestelmillä, kuten tämä Teslan turvallisuusominaisuus, aikajakso voi olla jopa alle vuoden.

Tämän videon kuvaamisen jälkeen Teslan tekniikka on ehtinyt kulkea läpi ainakin 5 tuplaantumissykliä, todennäköisesti enemmänkin. Käytännössä se voi tarkoittaa yli 100 kertaa suurempaa suorituskykyä.

Meidän softatestaajien tehtävänä on olla tuo turvallisuusjärjestelmä projekteille joita palvelemme. Tilanteensa tasalla oleva testaaja myös tavoittelee jatkuvasti tuplauksia kyvyssään ennustaa tulevaa, varoittaa vaaroista ajoissa ja suojella palvelemaansa liiketoimintaa.

Ihmisen aisteilla ja ehtimisellä on kuitenkin rajansa.

Onneksi yksi evoluutioeduistamme on kapasiteetti kehittää ja ottaa käyttöön työkaluja joiden avulla rajamme voivat kasvaa ajan kuluessa kenties jopa ilman rajaa. Tänään tarjolla olevien työkalujen määrä ja kyvykkyys kasvaa häikäisevää vauhtia. Osa niistä askeltaa jo eteenpäin Mooren lain mukaisesti.

Nyt tärkeä kysymys sinulle testaaja. Miten sinä olet kytkenyt itsesi tähän kehitykseen mukaan? Milloin viimeksi otit haltuun jotain uutta?

100X tasonkorotus ei ole kuin kuuden tuplaamisen takana. Mistä asioista sinun teknologinen etumatkasi voisi syntyä?

P.S. Videon onnettomuudessa ei kuollut kukaan. Voit siis hengähtää helpotuksesta!

Aamulla ketutti. Auto suti solskeessa pihatiellä.

Siinä lapioidessa naapuri vilkutti iloisesti kääntyessään omalta, sulalta pihalta tien päälle.

Ketutti kahta kauheammin. Mutta turhaan. Oma vikahan se.

Lokakuun ensilumista asti olen laiminlyönyt lumitöitä törkeästi. Aurauspenkka ja pihatie näyttävät Lahden mäkimontulta. Kerros kerrokselta kolaamaton ja siksi tiiviiksi tamppaantunut lumikerros pihassa oli hyvä kunnes tuli kevät.

Siihen solskeeseen en halua enää juuttua. Enkä usko, että sinäkään olisit kiljunut onnesta vetisen lumen lapioinnissa.

Olen huomannut, että ohjelmistoprojekteissa on usein karmea kiire. Kiusaus on suuri antaa lumen junttautua ja keskittyä tärkeämmältä tuntuviin tekemisiin. Yllätys on ikävä kun softa pitäisi saada tien päälle ja launchin hetkellä jouduttekin lapiohommiin.

Ehdottaisin, että seuraavassa Scrum-retrossa täräytät tiskiin ehdotuksen: Entä, jos tehtäisiin stabilointisprintti? Uusien piirteiden sijasta keskittyisimme teknisen velan kuittaamiseen. Bugien löytämiseen ja löydettyjen korjaamiseen.

Vältä teknistä velkaa viimeiseen asti. Sen takaisin maksaminen on kallista ja ketuttaa kaikkia osapuolia.

Muistatko vielä miltä lapsena tuntui joulukuun ensimmäisenä päivänä? Kun heti aamulla sai silmät loistaen juosta avaamaan kalenterista ensimmäisen luukun? Voi sitä ilon päivää, kun luukun takaa paljastui pieni runo ja hassu kuva enkelistä.

Ei ole enää joulukalenterit entisellään. Kuun alussa Kauppakeskuksessa pistäytyessä saattoi bongata ainakin suklaakalentereita, legokalentereita, kaljakalentereita, teekalentereita, korukalentereita ja Babylisin huulirasvakalentereita. Yhden seksiasentokalenterinkin bongasin. Se huvitti kovasti.

Heti perään mieleen palasi oman lapsuuteni kompastuskivi. Suklaakalenteri oli usein ihan tekemätön paikka. Se oli kauluttu luuhun asti jo ennen ensimmäistä adventtia.

Mutta miksi tämä paljastus on sitten tärkeä?

Eikö olekin niin, että ihmisillä on joskus taipumus rohmuta uudet ja upeat asia nopeasti ja loppuun asti? Sen jälkeen uudesta ja upeasta tulee odotusarvo. Netflixissä sarjat katsotaan kausi kerrallaan ja sitten harmittaa, jos seuraava kausi tuleekin vain kerran viikossa. Miten vanhanaikaista.

Tästä syystä sanonkin, että upeilla asioilla on puoliintumisaika ja se käy vuosi vuodelta lyhyemmäksi.

Ennen oli upeaa päästä modeemilla internettiin. Nyt hermot voivat mennä sekunnissa jos netti ei nakutakaan odotustemme tasolla. Totumme uuteen yhä nopeammin ja pian odotusarvomme ottavat kiinni kaiken, mikä aluksi oli niin upeaa.

Pohdin tätä siksi, että kokemukseni mukaan softaprojektin onnistumiselle on kaksi keskeistä tekijää.

Aluksi ratkaisevaa on se kuinka upean ensivaikutelman toimittamanne tuote synnyttää. Onko se sellainen, että asiakkaasi paitsi oikeasti haluaa käyttää sitä, myös maksaa laskut?

Toinen tekijä nousee vielä ratkaisevammaksi, koska kuitenkin on niin, että uutta ja upeaa ei ole mahdollista toimittaa joka päivä. Se kiteytyy kysymykseen: Kuinka luotettavasti tuotteenne toimittaa sen, minkä lupasitte?

Nämä kaksi kysymystä tiivistävät sen, mistä suuremmoiset softatuotteet ja häikäisevästi onnistuvat projektit syntyvät.

Koska pintaraapaisut eivät sovi meille Provella, aloitimme asiaan liittyvän tutkimusmatkan ja niin syntyi eeppisin ohjelmasarja ikinä. AamuQAQA.

Lue lisää tästä ja liity sisäpiiriin: prove.guru/aamuqaqa

Hyvää Joulua ystävät!

Teimme testin. Soitimme 200 markkinointijohtajalle ja ehdotimme keskustelua testauksesta. Aloitimme kokeen, sillä törmäsimme niin usein verkossa markkinointisivuihin, mainoksiin ja verkkokauppojen tarjouksiin, joissa pienet bugit palvelupolulla pilasivat pelin.

Arvaatko kuinka moni näistä 200:sta markkinointijohtajasta koki bugisten tai hitaiden markkinointilanderien tippuvan omalle vastuualueelle?

Testimme tulos oli 0,5%!

On toki mahdollista, että juuri me emme osanneet puhua bugien liiketoimintahaitoista ja testauksen arvosta oikealla tavalla.

Tänään aamulla luin Sell Like Crazy -kirjan kirjoittajan Sabri Subyn pikaoppaan. Kolme kriittisintä konversioon vaikuttavaa tekijää olivat järjestyksessä nämä.

1. Sivun tekninen toimivuus
2. Sivun salaman nopea lataus
3. Sivun kiinnostusta herättävä sisältö

Kolme kolmesta tekijästä koskevat laatua. Niistä kaksi ensimmäistä liittyy tekniikkaan.

Paikallistat varmasti nopeasti ristiriidan edellä mainituista?

Rohkenen väittää, että markkinointijohtajien työkalupakeista puuttuu kriittinen väline konversioiden nostamiseksi ja asiakasvirtojen kasvattamiseksi!

Se on testaus.

Näytän tällä videolla miten Robot Framework asennetaan Windows-koneelle nettisivujen testaamista varten ja kirjoitan yksinkertaisen testin. Video on toivottavasti niin seikkaperäinen, että asennus onnistuu vaikka olisit testiautomaation aloittelija.

Työohje noudattaa Robot Frameworkin dokumentaatiota:

1. Asenna Python, jos koneella ei ole sitä ennestään. Kannattaa valita Pythonin asennustyökalusta kohta “Add Python to PATH”. Python löytyy täältä: https://www.python.org/downloads/

2. Asenna Robot Framework kirjoittamalla komentoriville:

pip install robotframework

3. Robot Frameworkin asennus on onnistunut, jos versionumeron tarkistus palauttaa tuloksen. Kirjoita komentoriville:

robot --version

Lisäohje: Jos asennus ei toimi, todennäköisin vika on siinä, että Python ja sitä kautta pip eivät ole komentorivin Path:lla. Avaa “System Environment Variables” ja lisää muuttujalle “Path” Pythonin asennuskansio sekä sen alla oleva scripts-kansio. Tämä on ohjeistettu videolla kohdassa 5:00. Käynnistä komentorivi uudelleen muuttujan lisäämisen jälkeen.

Itse Robot Frameworkin asennus oli tässä ? Kirjoitetaan seuraavaksi selaintesti Selenium Webdriver -rajapinnan avulla. Tätä varten asennetaan Robotin erillinen Selenium-kirjasto sekä selaimen Webdriver.

4. Asenna Robotin Selenium-library kirjoittamalla komentoriville:

pip install --upgrade robotframework-seleniumlibrary

5. Asenna seuraavaksi Seleniumin Webdriver (tässä oletetaan, että koneella on Chrome-selain):

pip install webdrivermanager
webdrivermanager chrome

6. Kopioi Webdriverin asennuskansion polku komentoriviltä ja lisää se Path-muuttujaksi. Videolla tämä on ohjeistettu kohdassa 6:20. Käynnistä komentorivi uudelleen Path:n päivittämisen jälkeen.

Lisäohje: jos Robot herjaa virheellisestä Chromedriver-veriosta, tarkista että driverin ja selaimen versionumeroiden ensimmäinen numero on sama – tästä on kerrottu videolla kohdassa 9:44.

7. Asenna tarvittaessa moderni koodieditori. Suosikkieditorini on Visual Studio Code ja sen Robot Framework Intellisense lisäosa.

8. Kirjoita ensimmäinen testi Selenium Libraryn Keyword-dokumentaatiota hyödyntäen ja tallenna se tiedostopäätteellä .robot. Videolla luotu esimerkki löytyy täältä.

Siirry komentorivillä samaan kansioon jossa testi on ja suorita se komennolla:

robot .

Taputa itseäsi olalle kun testi lähtee ajoon! Nyt olet valmis harjoittelemaan Robotin käyttämistä esimerkiksi demoprojektin avulla tai voit lukea miten kirjoitetaan hyviä testitapauksia. Robotilla voi testata paljon muutakin kuin nettisivuja – dokumentaatio listaa kymmenittäin valmiita ulkoisia testikirjastoja.

Miltä ohje vaikutti? Saitko ensimmäisen testin tehtyä?

Jostain (käsittämättömästä) syystä maailmankaikkeus on päätynyt tilaan, jossa web-kehityksen työpanosta käytetään Internet Explorer-selaimen tukemiseen. IE:llä testaus on lyhyen tähtäimen voittona palkitsevaa – IE:n aukaistessaan testaaja löytää 99,5 % varmuudella bugeja. Toisaalta tekee mieli leikkiä ajatuksella siitä, mitä saavutettaisiin, jos IE:n toimivuuden tunkkaamiseen käytetty aika käytettäisiin vaikka globaalin köyhyyden vastaiseen työhön.

Eksistentialistiset pohdinnat sikseen – mistä tämän bugien aarreaitta, Internet Explorer, löytyy?

Microsoft jakaa IE-testaukseen tarvittavia Windows-virtuaalikoneita ilmaiseksi. Virtuaalikoneen asennus on varsin helppoa ja ohjeistan sen myös alla olevalla videolla:

1. Lataa ja asenna virtualisointialusta, esimerkiksi Oracle VirtualBox

2. Lataa Microsoftin sivulta ilmainen IE:n sisältävä Windows. Tarjolla on IE-versiot 8-11.

3. Pura asennuspaketti (zip)

3, Tuplaklikkkaa asennuspaketin .ovf -tiedostoa ja Virtual Box avautuu

4. Klikkaa Virtual Boxissa painiketta “Import”

5. Kun import on valmis, voit käynnistää Windowsin VirtualBoxista

Ohjevideolla näytetään lisäksi, kuinka virtuaalikoneen näytön kokoa pystyy muuttamaan ja kuinka leikepöytä (copy-paste) jaetaan oman koneen kanssa. Lisäksi videolla säädetään virtuaalikoneen saamia resursseja sekä vilautetaan, missä voi tallentaa koneen tilan, eli ottaa snapshotin.

Mukavia testaushetkiä IE:n parissa 😀 Jos et jostain syystä halua tehdä tätä testausta itse, Proven testauslabra auttaa mielellään!

Kahden mustan pakettiauton ovet avautuvat ja ulos hyppää salamannopeasti taktisiin varusteisiin pukeutuneita miehiä rynnäkkökivääreineen. Ovi avataan muurinmurtajalla; ”Poliisi! Kaikki maahan!”. Sekasorto valtaa talon. Miehet juoksentelevat ympäriinsä, naiset kyyristyvät ja lapset itkevät. SWAT on tehnyt rynnäkön jemmataloon.

Kun miehet makaavat lattialla raudoitettuna ja naiset istuvat lapsia sylissään puristaen seinustalla, poliisit aloittavat etsinnän. Yksi poliiseista suuntaa keittiöön ja löytää valkoista jauhetta. Nopeasti hän sekoittaa jauheen veteen ja annostelee pulloihin itkeviä pienokaisia varten. Maitojauhetta, ei huumausainetta. Yllättävä reagointi rauhoittaa tilanteen ja syytetyt saadaan siirrettyä autoihin ilman vastarintaa.

Charles ”Chip” Huthin johtama SWAT-tiimi ei suinkaan aina ollut toiminut edellä kuvatulla tavalla. Rankan lapsuuden kovettama Chip oli tunnettu voimakkaasta luonteestaan ja kovista otteistaan. Rynnäköiden yhteydessä ammuttiin perheiden lemmikit, tupakat tumpattiin huonekaluihin ja epäillyt saivat tuntea nahoissaan sen, että olivat mahdollisesti syyllistyneet rikokseen. Tiimi johti Kansas Cityn poliisilaitoksen reklamaatiotilastoa, korvaussummat nousivat suuriksi ja välit yhteisöön olivat huonot. Ongelmat olivat ilmiselviä, mutta niitä pidettiin työn luonnollisina sivuoireina.

Eräänä päivänä, hakiessaan teini-ikäistä poikaansa koulusta, Chip huomasi, että jokin oli vialla ja yritti itsepäisesti saada pojan avautumaan. Poika kieltäytyi puhumasta ja lopulta kun SWAT-johtaja tiedusteli syytä, poika tiuskaisi isälleen: ”Koska sinä olet robotti.”

Eihän kaveri mikään Robocop ollut, joten vastaus osui arkaan paikkaan.

Maailmalla on tapana tarjota tilaisuuksia käänteentekeville oivalluksille, kuten Chipinkin kohdalla oli tapahtunut. Tavara oli osunut tuulettimeen lukuisia kertoja aikaisemminkin, niin kentällä kuin kotona. Kuitenkin vasta pojan palaute pysäytti.

Chip tiimeineen toimi aikaisemman koulutuksen perusteella yhdestä periaatteesta käsin. Hyökkäys on paras puolustus.

Automatka koulusta kotiin käynnisti kuitenkin prosessin. Voisiko ollakin niin, että uhkaava käytös vain lisäsi vastarintaa?

Ajatusmallin muutos otti aikaa, mutta tulokset olivat häikäiseviä. Ongelmat pyrittiin paikallistamaan ja poistamaan ajoissa ennen eskaloitumista ja toimintassa keskityttiin tilanteen lukemiseen. Eläintenkäsittelyä opiskeltiin koirankouluttajien avulla ja Chip kielsi miehiltään tarpeettoman tihutyön tekemisen ”ellei joku pysty osoittamaan, että nuuskamälli epäillyn kotona edistää tehtävää, ei hyvä heilahda”.

Uuden lähestymistavan ansiosta välit yhteisöön paranivat nopeasti, valitukset tippuivat nollaan ja siitä huolimatta ryhmä teki kolmen vuoden aikana enemmän takavarikkoja kuin koko edellisellä vuosikymmenellä yhteensä. Käsittämätön korotus työn tuloksissa oli seurausta yhdestä oivalluksesta. Tulokset tulevat toisten ihmisten kautta. Yhteisön tuki toiminnalle on ratkaisevassa roolissa interventoiden lopputuloksissa.

Mutta miksi ihmeessä pohdin moista asiaa ohjelmistotestaus -blogissa?

Kuvio on yksinkertainen. Softakehityskin on yhteisö, jonka tuki testaukselle on ratkaisevassa roolissa myöhempiä onnistumisia ajatellen. Vain harvoin yhteisö omatoimisesti tarjoaa tukensa tiimille jonka tehtävänä ovat interventiot. Tuo tuki on ansaittava.

Testaus on asioiden parantamista toisten ihmisten kautta. Siksi merkittävimmät tasonkorotukset työn tuloksissa eivät usein tule uusia työkaluja ja tekniikoita tutkimalla. Ne tulevat sijoittamalla suhteiden rakentamiseen kohti asiakkaita, esimiehiä ja kehittäjäkollegoita.

Aurinkoisin terveisin,

//Antti Niittyviita
040 572 7204

Yksin ei voi menestyä. Parhaaseen tulokseen päästäkseen on antauduttava yhteistyöhön.

Softatuotteen kehityksessä devaajan ja testaajan yhteistyö voi johtaa huikeisiin tuloksiin. Virheetön tuote saadaan markkinoille nopeammin, kun testaaja tietää mitä devaaja haluaa, ja devaaja ymmärtää miten testaajan löytämät bugit heikentävät tuotetta.

Yhteistyön tiiviys riippuu siitä, mitä halutaan saada aikaan ja minkälaiseen työhön testaaja on palkattu. Jos tilaaja on pestannut testaustiimin laatupoliisiksi tuotteen toimituksen yhteyteen, ei yhteistyön välttämättä tarvitse olla tiivistä.

Kun taas halutaan kehittää softaa nopeasti ja tehokkaasti niin, että virheitä tulee mahdollisimman vähän, yhteistyö devaajan ja testaajan välillä on ratkaisevan tärkeää. Koska kun kehittäjä kuulee bugista pitkän ajan päästä, on virheen etsiminen sama kuin etsisi tiettyä perhekuvaa mummolan ullakolta. Muistijälki on ehtinyt haalistua ja aikaa virheen löytämiseen kuluu paljon. Mitä tiiviimmässä yhteistyössä devaaja ja testaaja tekevät töitä, sen nopeammin ja selkeämmin tieto kulkee.

Miten näin tiiviiseen yhteistyöhön sitten päästään? Esimerkiksi istumalla saman pöydän ääreen!

Katso videolta vastauksia pähkähulluihin kysymyksiin munakellon tikittäessä tahtia!

Joko olet muuten liittynyt mukaan AamuQAQAn sisäpiiriin? Liity mukaan ilmaiseksi: https://testauskoulutus.fi/aamuqaqa/
Liityttyäsi saat viikoittain sähköpostiisi videomateriaalia laadunvarmistuksesta ja testauksesta!

Tässä muistilista teille kaikille testaajille:

1. Lopputulos = Begin with the end in the mind. Testaustavan valintaan liittyy haluttu lopputulos.
2. Ajankäyttö = Kun sinulta kysytään, kuinka paljon testaukseen menee aikaa, käännä kysymys toisin päin: paljonko minulla on aikaa käytettävissä?
3. Taustatiedot = Koska emme voi arvata mikä on tärkeää toiselle, on taustatietojen keräys tärkeää.
4. Ikkunointi = Muista purkaa kokonaisuus osatekijöihin. Tähän vaikuttaa se, mitä tuloksia halutaan (evidenssiä vai bugeja) ja kuinka paljon aikaa on käytettävissä.
5. Tilannekuva = Mikä on testauksen tilanne? Tämä kysymys voi tulla vastaan missä tahansa testauksen vaiheessa. Vastaamiseen auttavat laadukkaat muistiinpanot ja mindmapit.
6. Käyntikortti = Bugiraportti on testaajan käyntikortti. Panosta siihen, sillä se edustaa sinua silloin kun et ole itse mestoilla.
7. Tarjoilu = Tarjoile tuloksesi niin, että joku on valmis muuttamaan ajatteluaan työsi tulosten perusteella.

Oletko kuullut aikaisemmin tornimallista? Katso video, niin tiedät, miten tämä seitsemän kohdan lista siihen linkittyy!

Joko olet muuten liittynyt mukaan AamuQAQAn sisäpiiriin? Liity mukaan ilmaiseksi: https://testauskoulutus.fi/aamuqaqa/
Liityttyäsi saat viikoittain sähköpostiisi videomateriaalia laadunvarmistuksesta ja testauksesta!

Tällä viikolla puhutaan testiraportoinnista, eli koko testaussession yhteenvedosta. Älä lopeta lukemista! Se on ihan eri asia kuin aiemmin käsitelty aihe, bugiraportointi.

Mitä teet tilanteessa, jossa et löydä yhden yhtä bugia? Miten asiakkaasi uskoo, että olet tehnyt työsi hyvin (tai edes aloittanut), jos soperrat luu kurkussa: ”Vähän oon testaillu, löysin yhden bugin tuossa aamulla”.

Jotta selviät jatkossa näistä kuumottavista tilanteista, pidä yksi ohje mielessä: ole aina valmis raportoimaan! Meillä Proven testilabrassa on vuosien varrella hioutunut hyvä malli raportoimiseen ja vastaamalla seuraaviin kysymyksiin on vaikea mennä metsään.

1. Mikä on testauksen tavoite eli missio?
2. Miten testausta on tehty?
3. Mitä on löydetty?
4. Mitä tehdään seuraavaksi?

Videolla pääset sukeltamaan mallin sielunmaisemaan – tai ainakin videon katseltuasi tiedät, miten rakentaa testaussessiosta pätevä tarina.

Pst! Paras Testauskurssi on saanut jatko-osan. Liity mukaan ilmaiseksi: https://testauskoulutus.fi/aamuqaqa/
Saat viikottain meiliisi videomateriaalia laadunvarmistuksesta ja testauksesta – ilman spämmiä!