Sogeti ET-seminaari 14.5.2013

307 views

Published on

14.5.2013 Sogeti Finlandin tiloissa pidetyn lounasseminaarin esitysmateriaali.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
307
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Familiar : Does the software behave as intended under the conditions it's supposed to be able to handle? Explicit requirements Planned testing Algorithms Unfamiliar: Are there any other risks? Implicit requirements, needs, wants, etc. Exploratory testing Heuristics Familiar you can expect and you prepare for the problems in it. Perhaps even prevent them. Defined problems and defined solutions. But the unfamiliar doesn’t work that way. When moving to the unfamiliar you have to expose yourself to situations where observations can be made. There aren’s specific places where bugs hide, but there are areas where they might hide. Controlling the chaos.
  • Suunnitelmavetoisen testauksen suunnittelu- ja valmisteluvaihe vie enemmän aikaa kuin itse testaus. Muutoksien aiheuttama korjaustaakka sotkee tulevien erien testaussuunnitteluaikataulun. Samalla testauksesta katoaa kokonaiskuva paljonko on työtä on tehty, paljonko on jäljellä, jne. Monesti ajaudutaan hiomaan testitapauksia täydellisiksi sen sijaan, että mietittäisiin onko kaikki tarvittavat toiminnallisuudet huomioitu testeissä. Helposti tuudittaudutaan ajattelemaan, että kunhan kaikki tehdyt testit on ajettu, kaikki on hyvin… Tarkitus on todistamista, tutkiminen/testaaminen on altistumista uudelle tiedolle. Jos ei ole kehitystä, ei ole tarkistusta ja testausta. Kaikki kolme luovat edellytykset kaikille kolmelle toimia. Esim. jos ei ole tarkistusta, testauksesta tulee tarkistusta, koska kaikki läpi pääsevät, mahdollisesti vakavatkin ongelmat vievät kaiken huomion. Kehittäminen ja verifiointi ovat hyvin tietoteknisiä, kvantifioituja, [lisää robottitermi tähän] toimintoja. Testaus sitoo ihmisen tarpeen ohjelmistoon ja täten siihen vaikuttavat psykologia (käyttäytyminen, oppiminen, havainnointi, jne.), antropologia, jopa filosofia. Testauksessa pyritään oppimaan ja löytämään, ja apuna ovat tottakai kaikki tietotekniikan keinot. Laatuaspektiin esimerkiksi Eeva Wahlström. Nyrkkeilijää koulittaessa kehitysvaihe opettaa lyömään, liikkumaan, laittaa lenkille, puntille, jne. Tarkistusvaiheessa katsotaan mitä on saatu aikaan ja opetetaan reaktioita erilaisiin tapahtumiin (suora lyönti ja sen väistö/torjunta). Testausvaiheessa tuodaan vastustaja, joka saattaa tehdä mitä vaan. Sparrataan laatu kuntoon. Eevan testausvaiheessa sparrivastustajina miehiä, jotta "tuotannossa" vastaantulevat naiset olisivat helppoa kauraa. Testaajan ammattitaito lepää usein geneerisissä malleissa, joita esim. ISTQB, TMap, jne. tarjoavat. Ei ole järkevää toistaa geneerisiä testitapauksia (raja-arvot, ekvivalenssiluokat, jne.) kerta toisensa jälkeen ihmisen toimesta. Ne tulee liittää osaksi verifiointikoneistoa, joka on yleensä automaatiota. Mitä ala on oppinut testauksesta tulisi ottaa käyttöön kehityksessä ja tarkistuksessa! Tälle luotava prosessi! Varsinainen testaus on kuitenkin aina lähtökohtaisesti tutkivaa (sapient activity). Jos testaajat sidotaan verifiointiin, he kokevat kaiken tekemisen taakaksi. Tämä ei hyvä lähtökohta testaamiselle. Jos tehdään testausta skriptien mukaan ja verifioiden, ei koskaan päästä kartoittamaan niitä inhimillisiä etuja/ominaisuuksia, joilla virheitä löytää. Sami ei olisi koskaan päässyt korostamaan vahvuuksiaan ja korjaamaan heikkouksiaan, jos muutosta ei olisi tapahtunut. Sama pätee kaikkiin. Vapaus on nostanut esiin loistavia testaajia. Tarkistuksessa ilmeneviin bugeihin ei tarvita ammattitestaajia ja näiden intuitiota. Ammattitestaajat voivat kuitenkin koordinoida tätä toimintaa. Taksikuski-analogia: On hyviä ja on huonoja. Huonoilla apuna GPS, joka ikäänkuin ammattitaidon korvike. Toki GPS:ää voivat käyttää myös ammattilaiset (esim. Ruuhkatutka). Lopullinen tavoite kuitenkin poistaa resurssiongelma mahdollistamalla kaikkien tuleminen taksikuskeiksi. Jos ei keskity bugien etsimiseen ja niihin keinoihin millä niitä löytää, ei voi koskaan tulla hyväksi siinä. Muista myös tunnepuoli. Kehitys ja kehittäjillä resurssoitu tarkistus ovat toimintoja, jossa sihdataan lopputulokseen, saamaan aikaan jotain. Luomisprosessissa syntyy tunneside omaan tuotokseen eikä sitä pysty enää arvioimaan puolueettomasti. Oma lapsi ei ole koskaan ruma, jne. Testaaja ei alistu tähän vaan pitää pään kylmänä, arvioi lopputuloksen lisäksi jatkuvasti myös tietä lopputulokseen ja tuottaa tietoa päätöksenteon tueksi.
  • Kysymykset jo heuristiikkoja. Itse asiassa algoritmitkin ovat heuristiikkoja tässä tapauksessa, koska niiden lopputulos ei ole selvä. Koko ajatus algoritmisesta testauksesta on kyseenalainen.
  • Tarkat keinot löytää tietoa vs. altistuminen tiedolle.
  • "Imagine running a test. The program misbehaves. The tester notices the behavior and recognizes that something is wrong. What is it that makes the tester decide this is wrong behavior?“ -Cem Kaner Noppapeli. Miten voit tietää toimivatko nopat eivätkä ole esim. painotettuja? Todennäköisyyslaskuilla, mittaamalla nopat ja tietenkin luottamalla turvamiesten aavistuksiin.
  • Kaikki hyvinkin aiheellisia kysymyksiä, jotka eivät ainoastaan anna Kyllä/Ei –vastauksia vaan saattavat johtaa uusiin kysymyksiin ja tietoon, jota testauksen tärkeää tuottaa. Laajenevan testikattavuuden käsite.
  • This is how your mindmap looks like after heuristic barrage. Stars indicate how well you think you’ve tested a certain area of interest: - One star. Superficial inspection. Doesn't require any testing expertise, but doesn't mean that bugs are not found. Actually the most serious ones are often the easiest to find. - Two stars. Tested as well as it's possible withing these time and resource constraints. Three stars. Additional testing wouldn't bring any added value. The tester has bled his heart into this and has no ammo left. Keinoja jäsentää ideointia: Mindmapit (Samin lempikeino. Suora yhteys ajatteluun ja sen visualisointiin.) Taulukot ja matriisit Vuokaaviot (Hyvä esim. End-2-End –testauksessa.) Tarkistuslistat (Hyvä ruutineissa. On kuitenkin syytä huomata, että tällainen toiminta on verifioimista ja pitäisi pyrkiä saattamaan esim. automaation pureskeltavaksi.) Aineistolla voidaan myös ruokkia korkean tason suunnittelua. Esim. erilaisia vakuutussopimuksia ja näille tarvittava testiaineisto. Raportointi arkkitehtuurin mukaisesti ja aineistohallinta siihen sopivin keinoin (esim. mindmap tai Excel-matriisi). Testitapausten määrästä ja kattavuudesta: Mitä yleisölle sanoo luku 100? Entä 1000? Entä 10000? Onko paljon vai vähän? Entä millaista softaa testataan? Web-sovellus, ulkoinen sovellus kiinni SAP:iin, pankkimuutos (SEPA, jossa käydään kaikki järjestelmät läpi), jne? Nasan tekemä testisuunnittelu avaruussukkulalle oli yksi A4. Onko 100 paljon? 1000? 10000? Kattaako se kaiken (huom. Ideoiden loputon määrä ja testauksen äärettömyys)? Jos ei, niin minkä osan ja mistä? Kannattaako kattavuudesta edes puhua? Mitä jos sen sijaan keskittyisi viestimään mitä tuli testattua? Sitäkin tulee tehtyä enemmän, kun ei käytä liikaa aikaa testisuunnitteluun (liikaa = ei tuota lisäarvoa). Miksi raportoinnissa pitää viestiä suunnittelun alin taso? Onko päättäjä kiinnostunut tästä? Onko päättäjä päättänyt mikä tämä on? Ota selvää mikä taso on tarpeen raportoida äläkä keskity siihen, että kertoisit yksittäisten testitapausten tilanteen. Näin saat hengitystilaa omalle suunnittelulle ja luovan testauksen käyttöönotolle (mindmapit, jne.) Jos päättäjä sen sijaan haluaa raportoinnin testitapaustasolla, myy korkeampi taso testitapauksina tai rehellisesti selitä luovan testauksen läsnäolo. Luo käytännöt mindmapien sisällön viestimiseen, jne. Mitä alemmas suunnittelu menee, sitä lähemmäksi päästään domain-spesifisyyttä. Kun suunnittelun jättää tietylle tasolle, voidaan domain-dynamiikkoihin paremmin reagoida. Esim. finanssialalla testidata näyttelee kriittistä roolia. Testisuunnittelu voidaan jättää korkealle tasolle, jotta päästään nopeasti testaamaan ja testidata on sitten se, johon keskitytään. Tapauskohtaisia otoksia, datan poimintaa tarpeeseen ja tärkeimmät ominaisuudet huomioonottaen. Ei kaikkia variaatioita!!! Mitä korkeampi suunnittelutaso, sitä kattavampi testaus. Huom! Kattavuus ei ota kantaa syvyyteen, joten eri aiheiden testauksen syvyystasoja voidaan kuvata esim. numeroin (1 = kevyt raapaisu, 3 = syvä testaus, tms.) Sessiopohjaisessa testauksessa käytetään usein tarinoita (charter), joita voidaan käyttää ohjaamaan testausta; Vakuutuksen tilaaminen verkosta, e2e-ketju FO-MO-BO-eräajo-SAP, sisäisen tikettijärjestelmän palautelomakkeen tietty kenttä, videovalvontajärjestelmän videotoiston sulavuus... Nämä voivat vaikuttaa useisiin haaroihin testiarkkitehtuurissa ja tähänkin on syytä mukautua luomalla uusi haararakenne arkkitehtuuriin. IT-työläisen tärkein työkalu on tämän päänuppi. Sen poistaminen yhtälöstä on edesvastuutonta. Sitä kuitenkin pidetään riskinä ja usein automaation viehätys piileekin sen "luotettavuudessa". Mutta päänuppia tukemaan voidaan valjastaa mekanismeja kuten testiarkkitehtuuri. Ja automaation voi aina valjastaa testauksen avuksi, kunhan päänuppi on ratissa. Tärkeintä on käyttää aika hyvin ja testata niitä alueita, jotka merkitsevät tärkeille ihmisille. Nämä usein asiakkaita, mutta huomioi kaikki sidosryhmät. Bachin/Boltonin RST-template: http://www.xmind.net/share/mkltesthead/heuristic-testing-strategy-model-%28master%29-1/ Ks. lisää (mm. mallipohjainen suunnittelu) Peksin blogista: http://how-do-i-test.blogspot.com/
  • Vaatimusmassa. Samat laatuominaisuudet jakavat vaatimukset nippuun. Nämä tarinoita, jotka sekä testitapauksia että kehityskokonaisuuksia. Tätä tasoa raportoidaan ohjausryhmälle. Tarinat ketjuja eli pitää suorittaa jonkinlainen tapahtumaketju, jotta tarina tulee ”kerrotuksi”. Tämä menee läpi erinäisten ketjun osien eli järjestelmien, järjestelmän osien ja niiden välisten integraatioiden. Ketjut kertovat kaikille missä järjestyksessä ja milloin mitäkin tapahtuu. Ketjun osista syvenee testausrakenne testaajan tekemän testauksen myötä. Tämä yksittäisten testaajien keinoja hallita työtään. Testaajan on aina kyseenalaistettava myös korkeammalla tasolla (defocusing). Mikäli vaatimuksissa on jotain häikkää tai niitä pitää kasata uudestaan, testaaja huomaa tämän.
  • Lähde: James Lindsay, http://workroomprds.blogspot.com/ Siellä oli myös don’t bother, älä vaivaudu? Stealth job = Tehdään tutkivasti salaa. Ei mainosteta niitä keinoja, joilla bugeja löydetään vaan pidetään nekin tyytyväisenä, jotka odottavat tuloksia laskettujen testitapausten, tiukan V&V-prosessin, jne. kautta. Jos ei ole voimaa, ei voi olla vastavoimaa (= jujutsu, pehmeä tekniikka). Traditional retreat = Off-Piste (Iron Script) = Off-Piste (Marshmallow Script) = Bug Hunt = Kokoonnutaan jahtaamaan bugeja. Voi olla sosiaalinenkin tapahtuma (esim. saunailta, osaamisyhteisön illallinen, julkinen kilpailu, jne.) Mielenkiintoista, että tähän osallistujilta harvoin vaaditaan raskasta testisuunnittelua, testitapausmassoja, jne. Testaajilta tätä kuitenkin odotetaan järjestään, vaikka se olisikin täysin tehotonta. Set Aside Time = Gambling = Script-Substitute = Session-Based = http://www.satisfice.com/sbtm/ Questioning = Thread-Based = Touring = Scouting = Määrätään ”tiedustelija”, joka käyttää kaiken aikansa tutkimukseen, ei mihinkään muuhun. Tehtävänä löytää kaikkea kiinnostavaa testattavasta kohteesta. Kanban = Following Lenfle = Daily News = R&D = Testing Guru = Video Reports = Post-Partum Labelling = The Summarizer = GPS = Cloudy = The Inquiring Metricator = On aivan sama mitä menetelmää käyttää, kunhan luo testaajille mahdollisuuden tutkimiselle. Tärkeintä on keskittyä hyötyihin  seuraava kalvo.
  • Sessiopohjainen testaus saattaa olla intensiivisyytensä takia rankkaa, joten ei koko päivää täyteen sessioita.
  • Kytätään seurauksia. Seuraukset johtavat syihin, jotka korjaamalla koko joukko seurauksia saadaan korjattua. Näin ei siis tarvitse löytää kaikkia seurauksia. Yksi seuraus voi johtua myös useammasta syystä eli pitää korjata useammassa paikassa, jotta tietty seuraus saadaan poistumaan. On mietittävä myös seurausketjua. On bugi, joka korjaantuu sillä, että korjataan virhe koodissa. Varsinainen ongelma kuitenkin lepää lähes aina ihmisessä. Ota tähän WC-harja-analogia. Hyvin epätodennäköinen seuraus voi johtaa hyvin todennäköiseen syyhyn, joka voi edelleen johtaa hyvin todennäköiseen seuraukseen. Bugijahtauskisoissa kierot kaverit saattavat löytää bugin syyn, mutta raportoivat kasapäin tästä johtuvia seurauksia, koska tärkeintä on löytää paljon ja mahdollisimman vakavia bugeja. Oikea tapa olisi jahdata seurausten syy ja korjata tämä. Huom! Yhdelle seuraukselle voi olla myös useita syitä. Bugiraporttien kirjoittaminen vie aikaa ja katkaisee testausflown. Tätä aikaa pienentää se, että tutkii löydöstään hieman pidemmälle ja myös hieman sen ympäriltä (80/20), ja pyrkii löytämään perimmäisen syyn virheelle ja raportoi vasta sitten. Tässä voi käyttää avuksi myös muiden, etenkin kehityksen apua. Lisäksi jos bugeja raportoidaan (älä sano kirjoitetaan, koska sitä tekevät kehittäjät) liikaa, niiden ylläpitämiseen ja prosessoimiseen menee aikaa (defect management). Toki bugeja pitää raportoida, mutta perinpohjin tutkitusta alueesta voi kirjoittaa perinpohjaisemman raportin, jossa käsitellään aihetta laajemmin, tarkemmin ja kenties useampi aiheeseen liittyvä bugi kerralla. Tällöin myös yksi raportti voi toimia kattodokumenttina, johon liitetään muita aiheeseen liittyviä bugiraportteja. Toki tällä menettelyllä ei saada valtavaa massaa bugiraportteja, mutta jokainen on loistava ja sehän on koko homman juju. Bug advocacy. Bugin myyminen sille, joka vastaa sen korjaamisesta. Tässä auttaa se, ettei yksittäisiä bugeja nakuteta isoja määriä (ja kiinnitetä testitapauksiin) vaan että niistä kerrotaan kattavasti. Useampi bugi, jolla on sama root cause, voidaan summata samaan raporttiin ja tehdä tästä seikkaperäinen kertomus, josta käy ilmi enemmän kuin yksittäisestä osasta bugisilppua. Näin myös defect management vähenee. Aikoinaan Juha Itkosen showssa otettiin esille huoli dokumentaation riittämättömyydestä. Itse asiassa bugiraportointi on parempaa, koska raportoidaan oikea tapahtumaketju, jossa yleensä mukana tulkinta myös root causesta sen sijaan, että kopioitaisiin ketju ennalta kirjoitetusta skriptistä, joka osuu vain sinne päin. Skriptaavassa testauksessa on kaiken muun lisäksi oletus myös sille mitä kehittäjä haluaa tietää virhetilanteesta. Huom! Bugin vakavuusaste on vain yksi suure. Se kertaa esiintymistodennäköisyys on bugin riskiluokitus, joka määrää bugin korjausprioriteetin.
  • Huom! Tutkiva testaus ei ole itsessään erillinen toiminto vaan se on tapa ajatella ja lähestyä testausta. Itse asiassa jos mietitään käsitettä ”tutkiva”, kaikki testaus on lähtökohtaisesti tutkivaa. Tutkiva testaus arvioi jatkuvasti myös itseään eli prosessi paranee jatkuvasti (ks. esim. Scrum). Skriptaava testauksessa ei korosteta tämän tärkeyttä. Loppujen lopuksi muista kuitenkin, että tutkiva testaus on testauksen kokonaisvastuun jakamista testaajille ja yhteistyön korostamista. Hyväksi tullaan vain saatujen vapauksien ei langetettujen rajoitteiden kautta.
  • Sogeti ET-seminaari 14.5.2013

    1. 1. Miten tutkiva testauskääntyy käytäntöön?Sami Söderblom, Sogeti Finland
    2. 2. Äänessä tänään Sami Söderblom+358 41 538 2001sami.soderblom@sogeti.comsami.soderblom@gmail.com 35-vuotias, avioliitossa, kissa, valokuvaus,jujutsu, sähly Vakituisessa työsuhteessa 13-vuotiaasta N. 10 vuotta testausta, sen johtamista,prosessikehitystä, koulutusta/valmennusta, jne. Testauskokemusta liiketoiminta-alueiltakuten videovalvonta, mainonta, vakuutus, pankki, telecom, (video)pelit,vähittäismyynti, rahtilogistiikka, julkishallinto, henkilöstöhallinto… Töissä yrityksissä kuten Fortum, Finnet, Suomen Kuluttajaliitto, Telia Mobile,Siemens, Mirasys, Blyk, Tapiola, Itella, Nordea, Tulli, Suomen Lähikauppa… Sytykkeen alla toimivan Testausosaamisyhteisön ohjausryhmän jäsen.
    3. 3. Mitä on tutkimus?TuttuTuntematonTuttu
    4. 4. Testauksen spektriTarkistus TutkimusVS.
    5. 5. Testaussuunnittelusta sananen
    6. 6. Testaussuunnittelusta testaussuoritukseen?
    7. 7. Ajattelumallit
    8. 8. Algoritminen vs. heuristinen ajatteluMääritetyt ongelmatMääritetyt ratkaisutMielivaltaisuusIntuitioTutkimusNyrkkisäännötValistuneet arvauksetAutomaatioHeuristiikatAlgoritmitOdotetut lopputuloksetMetriikat”Hidas” ajattelu”Nopea” ajatteluPäätöksetDeterminismiLuovuusKvantifiointiMututuntumaMielleyhtymätTekniikatKartan lukeminenKartan piirtäminen
    9. 9. Oraakkelit Testausoraakkelit ovat tietolähteitä,joiden perusteella voidaan tehdäjohtopäätöksiä siitä käyttäytyykötestauskohde oikein vai väärin. Oraakkelit voivat olla kirjattujavaatimuksia, tärkeiden ihmistenesittämiä toiveita, lainalaisuuksia,kirjoittamattomia sääntöjä,maalaisjärkeä, jne. jne. Oraakkelit eivät aina tuota tietoaitsestään vaan tietoa pitää kaivaa(esim. ei-toiminnalliset vaatimukset). Oraakkelien tuottama tieto voi myösjatkuvasti muuttua eli on suositeltavaapitää oraakkelit jatkuvasti saatavilla.
    10. 10. Heuristinen testaussuoritus
    11. 11. Tutkivan testauksen raportointi”Do not go where the path may lead, go instead where there is no path andleave a trail." -Ralph Waldo Emerson
    12. 12. Tutkivan testauksen raportointi Excelissä
    13. 13. Tutkivan testauksen raportointi Notepadissa
    14. 14. Case Reiskan Nakki & Sinappi – Tutkiva E2E-testaus!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!
    15. 15. Ideoita tutkivan testauksen hallintaan10 tutumpaa tapaaStealth jobTraditional retreatOff-Piste (Iron Script)Off-Piste (Marshmallow Script)Bug HuntSet Aside TimeGamblingScript-SubstituteSession-BasedQuestioningThread-BasedTouring10 erikoisempaa tapaaScoutingKanbanFollowing LenfleDaily NewsR&DTesting GuruVideo ReportsPost-Partum LabellingThe SummarizerGPSCloudyThe Inquiring MetricatorLähde: James Lindsay, http://workroomprds.blogspot.com/
    16. 16. Case Väiskin Voltti – Sessiopohjainen testaus Testaajalle tai joukolle testaajia annetaan aikaväli (esim. tunti), jonatehdään intensiivistä ja häiritsemätöntä testausta. Tämä on sessio. Sessiossa keskitytään yhteen testaustarinaan ja tapahtumiin sen ympärillä. Session jälkeen pidetään lyhytretrospektiivi, jossa punnitaanmitä tuli tehtyä ja ehkäraportoidaan bugejakin. Retrospektiivissä päätetäänedetäänkö saman tarinan kanssa(muista testaussyvyysluokitukset)vai jatketaanko seuraavaantarinaan. Myös uusien tarinoidenluonti mahdollista.
    17. 17. Erilaisia sessiotyyppejä Intake (Sisäänotto). Aloitetaan dialogi testauskohteen kanssa jamuodostetaan karkea käsitys mistä on kyse. Survey (Kartoitus). Kartoitetaan testauskohteen kokonaisuus pyrkienkattavuuteen. Analysis (Analyysi). Järjestelmällinen lähestyminen, esim.Päätoiminnallisuuksien ja tukevien toiminnallisuuksien kartoittaminen. Setup (Ympäristö). Muodostetaan käsitys ympäristöstä ja riippuvuuksista,esim. Asennukset, infran tutkiminen, loppukäyttäjätarpeiden huomioiminen,jne. Deep coverage (Syväluotaus). Nähdään vaivaaliiketoiminnallisten ja teknisten prosessienymmärtämiseksi, mennään itsestäänselvääpidemmälle ja löydetään vaikeasti löydettäviäbugeja. Closure (Lopetus). Lopetellaan testaus ja muodostetaan raportit, handover-dokumentaatio, uudelleentestataan korjatut bugit, päivitetäänregressiosettiä, jne.
    18. 18. Tarinankerronnasta sananen Tutki järjestelmän tietoturvaakaikilla käytössä olevilla ohjelmistoilla ja tekniikoillalöytääksesi kaikki tietoturva-aukot. Tutki lomakkeen ensimmäistä syöttökenttääsyötteellä <script>alert(”Sä et vaan osaa! LOLZ!!1”);</script>testataksesi järjestelmän kykyä kestää JavaScript-hyökkäyksiä. Tutki lomakkeiden syöttökenttiäJavaScript- ja SQL-injektio –hyökkäyksillälöytääksesi tietoturva-aukkoja. Tutki sivuston sisäänkirjaustahyödyntäen manipuloituja URL-osoitteita and POST-parametrejakatsoaksesi voivatko käyttäjät päästä käsiksi aineistoon, jota he eivätostaneet.Explore [target]with [resources]to discover[information]
    19. 19. Bugihallinnasta sananenSyySeurausSeurausSeurausSeurausSeurausSeurausSeurausSeurausSyySeurausSeurausSeuraus
    20. 20. Mitä on tutkiva testaus?SuunnitteluSuoritusOppiminenOhjaaminen“It is not the strongest of the species that survives, nor the most intelligent, but theone most responsive to change.” –Charles Darwin
    21. 21. Lisää aiheestaMuistaSamin blogi!;-)
    22. 22. KIITOS!!

    ×