Harjoituskoe Vastaukset. ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus
|
|
- Emma Hakala
- 9 vuotta sitten
- Katselukertoja:
Transkriptio
1 Harjoituskoe Vastaukset ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus Alkup. versio 1.0 Käännösversio 1.0 Tekijänoikeushuomautus Tämän dokumentin saa kopioida kokonaisuudessaan tai siitä saa tehdä otteita, mikäli lähde mainitaan.
2 Kysymys 1 FA (K1) Muistat ketterän ohjelmistokehityksen käsitteen, joka perustuu ketterään manifestiin A. Väärin Vaihtoehdot 2, 3, & 4 ovat väärin katso oikea vastaus kohdasta (B) B. Oikein Manifestissa on neljä avainarvoa: Yksilöt ja kanssakäyminen enemmän kuin menetelmät ja työkalut; Toimiva ohjelmisto enemmän kuin kattava dokumentaatio; Asiakasyhteistyö enemmän kuin sopimusneuvottelut; Muutokseen vastaaminen enemmän kuin suunnitelmassa pitäytyminen. C. Väärin 1 & 4 ovat väärin katso oikea vastaus kohdasta (B). D. Väärin kaikki vaihtoehdot väärin katso oikea vastaus kohdasta (B) Kysymys 2 FA (K1) Muistat ketterän ohjelmistokehityksen käsitteen, joka perustuu ketterään manifestiin A. Oikein Asiakkaan näkökulmasta toimiva ohjelmisto on paljon hyödyllisempi ja arvokkaampi kuin liian yksityiskohtainen dokumentaatio ja se antaa mahdollisuuden tuottaa kehitystiimille nopeaa palautetta. B. Väärin Tämä on normaali käytäntö erityisesti testiohjatussa kehityksessä, mutta ei kuulu Ketterän manifestin arvoihin. C. Väärin Arvo on: Asiakasyhteistyö enemmän kuin sopimusneuvottelut. D. Väärin Arvo on: Muutokseen vastaaminen enemmän kuin suunnitelmassa pitäytyminen. Kysymys 3 FA (K2) Ymmärrät tiimiperusteisen lähestymistavan edut A. Väärin Tämä riippuu tiimin osaamisesta; toteuttajat voivat ottaa tämän tehtävän hoitaakseen. B. Väärin Tiimi työskentelee yhdessä valitakseen työkalut, joiden avulla he voivat tehdä yhteistyötä ja toimia tehokkaasti. C. Oikein Testaajat tukevat liiketoiminnan edustajia ja tekevät heidän kanssaan yhteistyötä sopivien hyväksymistestien luomiseksi. D. Oikein Ketterissä projekteissa koko tiimi on vastuussa laadusta. E. Väärin Toteuttajat voivat auttaa näissä tehtävissä, riippuen tiimin osaamisesta ja yksilöiden työkuormasta. Harjoituskoe CTFL FA Sivu 2/ , käännös , Finnish Board
3 Kysymys 4 FA (K2) Ymmärrät tiimiperusteisen lähestymistavan edut A. Väärin Ohjelmistotestauksen taitoja pitäisi siirtää ja levittää tiimin ei-testaaville jäsenille. B. Väärin Tämä riippuu tiimin osaamisesta ja siitä, ketä on käytettävissä; joillakin testaajilla saattaa olla ohjelmistokehittäjän tausta. C. Oikein Mahdollistaa erilaisten taitojen hyödyntämisen tarpeen mukaan projektissa. D. Enables a variety of skillsets to be leveraged as needed for the project. E. Väärin Erikoistuneita testaajia tarvitaan yhä ja he ovat tärkeä ketterien projektien resurssi. Kysymys 5 FA (K2) Ymmärrät aikaisen sekä jatkuvan palautteen merkityksen A. Väärin. B. Väärin. C. Oikein Katso perustelut alla. D. Väärin. 1) Väärin Toteuttajat toteuttavat vain liiketoiminnan pyytämät ominaisuudet, jotka ovat osa iteraatiota. Jos he saavat tehtävänsä valmiiksi, he auttavat muissa iteraatioon suunnitelluissa tehtävissä. 2) Oikein Usein annettu asiakaspalaute pitää huomion kiinnittyneenä ominaisuuksiin, joiden liiketoiminnallinen arvo on suurin. 3) Väärin Testausta saatetaan tarvita enemmän usein tapahtuvien muutosten vuoksi. 4) Oikein Asiakkaat ilmoittavat, jos vaatimuksia puuttuu tai niitä on tulkittu väärin, ja muokkaavat halutessaan toiminnallisuutta. Kysymys 6 FA (K2) Ymmärrät aikaisen sekä jatkuvan palautteen merkityksen A. Väärin Sama määrä vikoja voi löytyä mitä tahansa ohjelmistokehitysprosessia käyttämällä. Ketteryyden hyöty on vikojen löytyminen ja korjaaminen nopeammin. B. Oikein Asiakkaan toimeksiantojen selvittäminen aikaisin ja säännöllisesti läpi toteutuksen tekee todennäköisemmäksi sen, että avainominaisuudet ovat asiakkaan käytettävillä aikaisemmin ja tuote vastaa paremmin sitä, mitä asiakas haluaa. C. Väärin Ketteryys ei erittele yksilöitä; se koskee koko tiimiä. D. Väärin - Kaikkia iteraation piirteitä ei ehkä ole aika tehdä loppuun, mutta ketterä prosessi mahdollistaa tiimin keskittymisen niihin ominaisuuksiin, joiden liiketoiminnallinen arvo on suurin. Harjoituskoe CTFL FA Sivu 3/ , käännös , Finnish Board
4 Kysymys 7 FA (K1) Muistat ketterän ohjelmistokehityksen näkökulmia A. Väärin Katso oikea vastaus kohdasta B.. B. Oikein Extreme Programming sisältää viisi kehitystä ohjaavaa arvoa: kommunikointi, yksinkertaisuus, palaute, rohkeus ja kunnioitus. Scrum jakaa projektin lyhyisiin iteraatioihin, joita kutsutaan sprinteiksi. Kanbanissa ei ole iteraatioita tai sprinttejä; sitä käytetään optimoimaan tehtävien jatkuva virta ja minimoimaan jokaisen tehtävän läpimenoaika. C. Väärin Katso oikea vastaus kohdasta B. D. Väärin Katso oikea vastaus kohdasta B. Kysymys 8 FA (K3) Osaat kirjoittaa testattavia käyttäjätarinoita yhteistyössä kehittäjien sekä liiketoiminnan edustajien kanssa A. Väärin On tärkeää ottaa huomioon testattavuus ja automaatio, mutta järjestelmän suunnittelu testauspanoksen rajoittamisen pohjalta ei ehkä johda loppukäyttäjän kannalta sopivaan ratkaisuun. B. Väärin Tuoteomistaja priorisoi eri laatuominaisuudet. C. Väärin Normaalisti tuoteomistaja määrittää suorituskyvyn hyväksymiskriteerit. D. Oikein Testaaja myötävaikuttaa varmistamalla, että tiimi luo käyttäjätarinan hyväksymiskriteerit. Kysymys 9 FA (K2) Ymmärrät kuinka retrospektiivejä voidaan hyödyntää ketterien projektien prosessikehityksessä A. Väärin Testaajien pitäisi osallistua jälkipalaverin kaikilta osin. B. Väärin Testaajien pitäisi osallistua jälkipalaverin kaikilta osin. C. Oikein Kaikki tiimin jäsenet, sekä testaajat että ei-testaajat, voivat antaa panoksensa sekä testaus- että muihin tehtäviin. D. Väärin Testaajat voivat saada jälkipalaverista arvokasta tietoa, jota he voivat käyttää myöhemmissä iteraatioissa. Harjoituskoe CTFL FA Sivu 4/ , käännös , Finnish Board
5 Kysymys 10 FA (K2) Ymmärrät kuinka retrospektiivejä voidaan hyödyntää ketterien projektien prosessikehityksessä A. Väärin Tämä pitäisi ottaa esiin, jotta vikoja löydettäisiin aikaisemmin prosessissa. B. Väärin Tämä pitäisi ottaa esiin prosessin parannuksena. C. Oikein Jälkipalavereissa ei ole tarkoitus nostaa esiin yksittäisiin henkilöihin liittyviä asioita vaan keskittyä prosessin parannukseen ja tiimiin kokonaisuutena. D. Väärin Tämä pitäisi ottaa esiin prosessin parannuksena. Kysymys 11 FA (K2) Ymmärrät jatkuvan integraation käytön sekä tarkoituksen A. Väärin Tämä on jatkuvan integraation periaate; koonnit tehdään vähintään kerran päivässä ja ne jaetaan automaattisesti ja yksikkö- ja integraatiotestataan automaation avulla. B. Väärin Jatkuvan integraation avulla suoritettava ohjelmisto on jatkuvasti saatavilla testaus-, esittely- tai koulutustarpeisiin missä ja milloin vain. C. Väärin Jatkuvan integraation käytäntöjen avulla toteuttajat voivat integroida ja testata työtään jatkuvasti niin, että virheet koodissa voidaan löytää nopeasti. D. Oikein Yksikkö- ja integraatiotason testaus pitäisi automatisoida, jotta koonnin laadusta saadaan nopeaa palautetta. Kysymys 12 FA (K1) Tiedät miten iteraation ja julkaisun suunnittelu eroavat toisistaan. Ymmärrät, kuinka testaaja tuo lisäarvoa niissä tapahtuviin tehtäviin A. Väärin Tätä odotetaan iteraation suunnittelun aikana. B. Väärin Tätä odotetaan iteraation suunnittelun aikana. C. Väärin Tätä odotetaan iteraation suunnittelun aikana. D. Oikein Tätä odotetaan julkaisun suunnittelun aikana. Harjoituskoe CTFL FA Sivu 5/ , käännös , Finnish Board
6 Kysymys 13 Ketterä Laajennos - Termit (K1) A. Väärin Testaaja osallistuu käyttäjätarinan luomiseen. B. Väärin Käyttäjätarinan pitäisi sisältää sekä toiminnallisia että ei-toiminnallisia vaatimuksia. C. Väärin Käyttäjätarinan kirjoittavat toteuttajat, testaajat ja liiketoiminnan edustajat yhdessä. D. Oikein Käyttäjätarinat kirjoitetaan ketterässä ympäristössä vaatimusten kuvaamiseksi toteuttajien, testaajien ja liiketoiminnan edustajien näkökulmista. Käyttäjätarinan kirjoittamiseen yhdessä voidaan käyttää eri tekniikoita, kuten aivoriihtä ja miellekarttoja. Kysymys 14 FA (K2) Osaat kuvata testauksen tehtävien eroavaisuudet ketterien ja ei-ketterien projektien välillä A. Väärin Ketterä testaus kannustaa kevyeen dokumentaatioon. B. Oikein Testiautomaatiota tapahtuu kaikilla tasoilla monissa ketterissä tiimeissä. Siinä missä toteuttajat keskittyvät automatisoimaan testejä yksikkötestaustasolla, testaajien pitäisi keskittyä testien automatisointiin integraatio-, järjestelmä- ja hyväksymistestaustasolla. Perinteisissä projekteissa ei ole niin tyypillistä kiinnittää samanlaista huomiota automaatioon. Joskus automaatio toteutetaan vasta, kun järjestelmätestaus on valmis, jotta voidaan työskennellä vakaan järjestelmän kanssa, tai automatisoidaan vain regressiotestit ylläpitoa varten sen jälkeen, kun järjestelmä on julkaistu tuotantoon. C. Väärin Tutkivaa testausta voidaan tehdä kaikissa ohjelmistokehityksen muodoissa. D. Väärin Testaajan ja toteuttajan välinen yhteistyö on hyvä käytäntö kaikissa elinkaarimalleissa. Kysymys 15 FA (K2) Osaat kuvata kuinka kehityksen ja testauksen tehtävät muodostavat kokonaisuuden ketterissä projekteissa A. Oikein Nämä kolme näkökulmaa (testaaja, toteuttaja ja liiketoiminnan edustaja) ovat tärkeitä, kun määritellään, milloin ominaisuus on valmis. B. Väärin Testaustasojen aloitus- ja lopetuskriteerit liittyvät läheisemmin perinteisiin elinkaarimalleihin. C. Väärin Ominaisuudet pitäisi todentaa samassa iteraatiossa, jossa ne toteutetaan. D. Väärin Ominaisuudet pitäisi todentaa samassa iteraatiossa, jossa ne toteutetaan. Harjoituskoe CTFL FA Sivu 6/ , käännös , Finnish Board
7 Kysymys 16 FA (K2) Osaat kuvata riippumattoman testauksen roolin ketterissä projekteissa A. Oikein Tämä on yksi ketterien projektien tuntomerkki. B. Väärin Monissa ketterissä projektitiimeissä on yhä riippumaton testaustiimi testauspäällikköineen. C. Väärin Testaus on yhä erityisrooli ketterässä kehityksessä, kun se tehdään kunnolla. D. Väärin Toteuttajat ja testaajat työskentelevät yhdessä ominaisuuksien toteuttamisessa ja testaamisessa. E. Oikein Ketterät tiimit voivat käyttää hyväksymistestauksen eri muotoja. Kysymys 17 FA (K2) Osaat kuvata riippumattoman testauksen roolin ketterissä projekteissa A. Väärin Tämä väite on tosi. Näin voi tapahtua, kun testaajat ja toteuttajat työskentelevät tiiviisti yhdessä. B. Oikein Tämä väite on epätosi. Riippumattomat testaajat VOIVAT löytää enemmän vikoja kuin toteuttajat, mutta tämä riippuu suoritettavan testauksen tasosta ja myös riippumattoman testaajan asiantuntemuksesta. C. Väärin Tämä väite on tosi. Tämä on vaihtoehto, jossa säilyy riippumattomuuden taso, koska käytössä on erilliset testaus- ja toteutustiimit ja testaajat kiinnitetään tarpeen mukaan töihin sprintin lopussa. D. Väärin Tämä väite on epätosi. Tämä vaihtoehto täyttyy, kun erikoistuneita testaajia työskentelee sprinttiin kuulumattomissa tai pitkäaikaisissa tehtävissä. Kysymys 18 FA (K2) Osaat kuvata työkaluja ja tekniikoita, joita käytetään ketterien projektien testauksen tilanteen viestimisessä, mukaan lukien testauksen edistyminen ja tuotelaatu A. Väärin Tämä voi kertoa laadusta, mutta oletuksena on silloin, että testausta on tehty riittävästi kaikkien mahdollisten vikojen tunnistamiseksi. Se ei myöskään kerro siitä, pidetäänkö järjestelmää tässä vaiheessa toimivana ohjelmistona. B. Oikein Positiivinen asiakaspalaute ja toimiva ohjelmisto ovat tuotteenlaadun avaintunnusmerkkejä. C. Väärin Tämä kertoo hyvin tiimin vauhdista, mutta se ei tarjoa tietoa tuotteen laadusta. D. Väärin Myös tämä kertoo hyvin tiimin vauhdista, mutta edelleenkään ei tarjoa tietoa tuotteen laadusta. Harjoituskoe CTFL FA Sivu 7/ , käännös , Finnish Board
8 Kysymys 19 FA (K2) Osaat kuvata työkaluja ja tekniikoita, joita käytetään ketterien projektien testauksen tilanteen viestimisessä, mukaan lukien testauksen edistyminen ja tuotelaatu A. Oikein Edistymiskäyrä kuvaa käyttäjätarinoiden suunnitellun edistymisen ja julkaisupäivän yhdessä todellisen edistymisen kanssa. B. Väärin Automaatiolokeista näkyvät läpäissyt ja hylätyt testit, mutta ne eivät ole millään lailla yhteydessä työmääräarvioihin. C. Väärin Ketterä tehtävätaulu kuvaa työn etenemistä ja tätä tietoa käytetään hyväksi edistymiskäyrissä. Käyttäjätarinoiden ja tehtävien edistymistä kuvaavilla tehtävätauluilla ei ole kuitenkaan mitään tekemistä työmääräarvioiden kanssa. D. Väärin Vikojenhallintatyökalu voi kuvata vikaraporttien edistymistä ja sitä voidaan käyttää tuotteen laatutason määrittämisessä. Se ei kuitenkaan liity tiimin edistymiseen suhteessa työmääräarvioihin. Kysymys 20 FA (K2) Osaat kuvata testien kehitysprosessin läpi monien iteraatioiden ja osaat selittää miksi testausautomaatio on tärkeää ketterien projektien regressioriskin hallinnassa A. Oikein Koska ominaisuus on jo aiemmin toimitettu, tarvitaan kaikkien testimateriaalien katselmointi, jonka tuloksena pitäisi seurata testitapausten päivittäminen vastaamaan uusia hyväksymiskriteereitä ja varmistamaan, että vääriä negatiivisia testejä ei esiinny. Tämä on ensimmäisiä tehtäviä, joita pitää tehdä ennen kuin päätöksiä minkään muiden muutosten suhteen voidaan tehdä. B. Väärin Tämä ei ole ensimmäiseksi suoritettava tehtävä, sillä testaaja ei tiedä, mitä uusia testejä muutosten vuoksi tarvitaan ilman, että senhetkiset testit ensin katselmoidaan. Voi olla, että uusia testejä ei tarvita olemassa olevien testien päivittäminen saattaa riittää. C. Väärin Vaikka tämä onkin hyvä käytäntö, se ei kohdistu tässä skenaariossa erityisesti tunnistettuun regressioriskiin. D. Väärin Sama kuin vaihtoehto B. Katselmoimatta tämän ominaisuuden nykyisiä testejä ei voida tietää, tarvitaanko lisäautomaatiota. Harjoituskoe CTFL FA Sivu 8/ , käännös , Finnish Board
9 Kysymys 21 FA (K2) Osaat kuvata testien kehitysprosessin läpi monien iteraatioiden ja osaat selittää miksi testausautomaatio on tärkeää ketterien projektien regressioriskin hallinnassa A. Väärin. B. Oikein. Katso tarkempi perustelu alla. C. Väärin. D. Väärin. i. Tämä on oikein, koska ketterä ohjelmistokehitys odottaa ja hallinnoi muutoksia, ja joka iteraatiossa tarvitaan yhä enemmän regressiotestausta. Jos automaatiota ei käytettäisi, tiimin vauhti hidastuisi. ii. iii. Tämä on väärin. Tämä ei ole syy automaation käyttöönottoon projektissa. Tämä on väärin. Emme voi suorittaa uudelleen kaikkia aikaisemman iteraation testejä. Testitapauksia syntyy paljon, useimmat niistä manuaalisen tutkivan testauksen kautta, eikä kaikkien automatisointi olisi järkevää. iv. Tämä on väärin. Automaatio auttaa välttämään suuren muutoksien määrän aiheuttamaa tuotteen regressiota. Se ei kuitenkaan takaa sitä, että vikoja ei olisi syntynyt. v. Tämä on oikein. Automaatiotyökalut linkitetään jatkuvan integraation työkaluihin, jotka suorittavat testit ja ilmoittavat välittömästi, jos uusi koodi rikkoo koonnin. Kysymys 22 FA (K2) Ymmärrät testaajan taidot (ihmiset, toimintapiiri ja testaus) ketterässä tiimissä A. Väärin katso perustelut alla. B. Väärin katso perustelut alla. C. Väärin katso perustelut alla. D. Oikein katso perustelut alla. i. Väärin Ketterät projektit hyväksyvät muutokset ja odottavat niitä; tämä ei kuitenkaan tarkoita että niitä tapahtuu päivittäin. ii. Oikein Tämä on totta, mitä aikaisemmin ketterä tiimi saa palautetta laadusta, sitä parempi. iii. Oikein Testilähtöinen lähestymistapa ja jatkuva integraatio edellyttävät testien automatisointia ja että ne tuottavat palautetta koonnista osana automatisoitua koontiprosessia. iv. Väärin Testausta pitäisi tehdä läpi joka iteraation, ei vain lopussa. v. Väärin Ketterät projektit tarvitsevat testauksen eri tasoja, kuten yksikkö-, järjestelmä- ja hyväksymistestausta. Harjoituskoe CTFL FA Sivu 9/ , käännös , Finnish Board
10 Kysymys 23 FA (K2) Ymmärrät testaajan roolin ketterässä tiimissä A. Väärin katso perustelut alla. B. Väärin katso perustelut alla. C. Oikein katso perustelut alla. D. Väärin katso perustelut alla i. Väärin Tämä tehtävä on koko tiimin yhteinen ponnistus. ii. Oikein Tätä odotetaan ketterältä testaajalta. iii. Väärin Ketterissä projekteissa vioista keskustellaan säännöllisesti sidosryhmien kanssa iv. Oikein Tämä on tyypillinen ketterän testaajan tehtävä. v. Väärin Pariohjelmointia tekee tyypillisesti kaksi toteuttajaa yhdessä; testaajien ei odoteta parantavan ohjelman logiikkaa vaikkakin he voivat katselmoida koodin testattavuuden tai ylläpidettävyyden näkökulmasta. Kysymys 24 FA (K2) Ymmärrät testaajan roolin ketterässä tiimissä A. Väärin Tämä on totta. Osa testaajan roolia on tuottaa automaatioskriptejä, suorittaa ne ja ylläpitää niitä. B. Väärin Tämä on totta. Testaajan pitäisi valmentaa kaikkia muita tiimin jäseniä missä tahansa testaukseen liittyvässä asiassa. C. Oikein Tämä on väärin. Edistymiskäyrien tuottaminen ja päivittäminen muun tiimin tuottaman tiedon perusteella kuuluu scrummasterin rooliin (tai vastaavaan rooliin muissa ketterissä menetelmissä). D. Väärin Ketterissä menetelmissä testaaja tuottaa palautetta tuotteesta kaikissa kehityksen vaiheissa, joihin voi kuulua myös koodin analysointi. Kysymys 25 Ketterä laajennos -Termi (K1) A. Väärin Edistymiskäyrä ei ota kantaa yksittäisten henkilöiden kuormittumiseen B. Väärin Tämä määritelmä kuvaa ketterää tehtävätaulua. C. Oikein Edistymiskäyrä kuvaa valmiiden käyttäjätarinoiden edistymisen ja antaa arvion siitä, kauanko sprintissä jäljellä olevien käyttäjätarinoiden valmistuminen kestää. D. Väärin Edistymiskäyrillä ei ole yhteyttä korjattuihin vikoihin tai vikoihin, jotka odottavat korjausta. Harjoituskoe CTFL FA Sivu 10/ , käännös , Finnish Board
11 Kysymys 26 FA (K1) Muistat testiohjatun kehityksen, hyväksymistestiohjatun kehityksen sekä käyttäytymisperustaisen kehityksen konseptit A. Väärin Testiohjattu kehitys (Test-Driven Development, TDD) on tekniikka, jossa käytetään automatisoituja testitapauksia ohjaamaan koodin toteutusta. Se tunnetaan myös testauslähtöisenä ohjelmointina, sillä testit kirjoitetaan ennen koodia. Testit automatisoidaan ja niitä käytetään jatkuvassa integraatiossa. B. Väärin TDD-prosessi toistetaan jokaiselle pienelle koodin osalle ja silloin suoritetaan sekä aikaisemmat testit että uudet lisätyt testit. C. Väärin Testit toimivat suoritettavien suunnittelukuvausten muotona tulevia ylläpitotehtäviä varten. D. Oikein Tämä koskee BDD:tä ei TDD:tä. Kysymys 27 FA (K1) Muistat testipyramidin konseptin A. Väärin Kunkin sprintin työkuormalla ei ole mitään tekemistä Testipyramidi-käsitteen kanssa. B. Väärin Testauksen kehitysjonolla ja testien määrällä ei ole mitään tekemistä Testipyramidikäsitteen kanssa. C. Oikein Testipyramidi korostaa sitä, että alemmilla testitasoilla testien määrä on suurempi ja se vähenee ylemmillä testitasoilla. D. Väärin Automatisoitujen testien määrällä ei ole mitään tekemistä Testipyramidi-käsitteen kanssa. Kysymys 28 FA (K2) Osaat esittää testausneljännekset ja niiden yhteyden testitasoihin ja -tyyppeihin A. Oikein Testausneljänneksiä voidaan käyttää apuna kuvaamaan testien tyyppejä kaikille sidosryhmille. B. Väärin Tämä ei ole hyvä mittari, sillä kaikki testitasot ja -tyypit eivät sovi kaikkiin järjestelmiin. C. Väärin Testitapausten määrä kutakin neljännestä kohden riippuu testattavasta järjestelmästä ja on harvoin sama kaikkien neljännesten osalta. Joissakin tilanteissa jostakin neljänneksestä ei ehkä ole yhtään testitapauksia. D. Väärin Testausneljänneksillä ei ole yhteyttä riskitasoon. Harjoituskoe CTFL FA Sivu 11/ , käännös , Finnish Board
12 Kysymys 29 FA (K2) Osaat esittää testausneljännekset ja niiden yhteyden testitasoihin ja -tyyppeihin A. Väärin katso perustelut alla. B. Väärin katso perustelut alla. C. Oikein katso perustelut alla. D. Väärin katso perustelut alla. Q1 Väärin Nämä testitapaukset eivät ole teknologiasuuntautuneita yksikkötestejä. Q2 Väärin Käytettävyys ja suorituskyky eivät kuulu toiseen neljännekseen. Q3 Oikein Käytettävyystestaus on osa kolmatta neljännestä. Q4 Oikein Suorituskyky on osa neljättä neljännestä. Kysymys 30 FA (K3) Osaat toimia testaajan roolissa scrumtiimissä A. Väärin Testiautomaatiokehyksen ja skriptien muokkaaminen tukemaan uudentyyppistä selainta ei ole ehkä kannattavaa, jos uusien vikojen löytymisen riski on pieni. Koko tiimin pitäisi suorittaa riskianalyysi ja tehdä yhteinen päätös asiasta. B. Oikein Päätös testiautomaatiokehyksen ja skriptien muokkaamisesta pitäisi tehdä yhteisesti tiimissä. Tämän jälkeen testaajan vastuulla on tehdä tarvittavat muutokset iteraatiosuunnitelmaan. C. Väärin Testaajan täytyy ilmoittaa asiasta tiimille, joka päättää sen jälkeen yhdessä, miten asian kanssa toimitaan. D. Väärin Testaaja ei yksin päätä työn laajuutta. Tämä asia käsitellään luomalla uusi käyttäjätarina tai muokkaamalla olemassa olevaa käyttäjätarinaa ja koko tiimi käsittelee asian sprintin suunnittelun yhteydessä. Harjoituskoe CTFL FA Sivu 12/ , käännös , Finnish Board
13 Kysymys 31 FA (K3) Osaat arvioida laaturiskejä ketterässä projektissa A. Oikein Riskianalyysistä saatuja tietoja käytetään suunnittelupokeri-istunnoissa, kun päätetään iteraatiossa toteutettavien tehtävien prioriteeteista. Vasta pokeri-istuntojen jälkeen tehtävät lisätään kehitysjonoon, jos päätetään, että kaikkia ei saada valmiiksi iteraatiossa. B. Väärin Tässä vaiheessa emme tiedä, onko meillä iteraatiossa riittävästi aikaa kaikkien tehtävien valmiiksi saamiseen. Se, että johonkin tehtävään liittyy korkea riski, ei tarkoita, että sen tekeminen vaatii paljon työtä. Sen tiedämme vasta suunnittelupokeri-istuntojen jälkeen. C. Väärin Iteraation pituutta ei jatketa. Suunnittelupokeri-istunnon jälkeen joitakin tehtäviä voidaan siirtää kehitysjonoon, jos päätetään, että niiden valmiiksi saamiseen ei ole riittävästi aikaa. D. Oikein Riskien pienentämistä voidaan tehdä ennen testien suoritusta riskitason pienentämiseksi. E. Väärin Ensin pitäisi pitää suunnittelupokeri-istunto sen määrittämiseksi, mitä iteraatiossa voidaan saada aikaan. Jos todetaan, että aikaa ei ole riittävästi kaikkien tehtävien valmiiksi saamiseen, on todennäköistä, että matalan riskin tehtävät lisätään tulevien sprinttien kehitysjonoon. Kysymys 32 FA (K3) Osaat arvioida testauksen työmäärää iteraation sisällön ja laaturiskien perusteella A. Väärin Asiakkailta ja toteuttajilta on saattanut jäädä huomaamatta käyttäjätarinan kelpuuttamiseksi tarvittavan testaustekniikan vaativuus. Asiasta täytyy keskustella ja koko tiimin pitää olla yhtä mieltä työmääräarviosta. B. Oikein Käyttäjätarinan suunnittelupokerikierroksia pitäisi jatkaa, kunnes koko tiimi on tyytyväinen arvioituun työmäärään. C. Väärin Koko tiimin täytyy olla yhtä mieltä käyttäjätarinan työmääräarviosta. Asiakas ei yksin ymmärrä toiminnallisuuden toteuttamisen tai testauksen monimutkaisuutta. D. Väärin Ei ole välttämätöntä, että ne ovat täsmälleen samat; voidaan sopia säännöstä, että arvioista valitaan korkein tai että kaikista kolmesta arviosta lasketaan keskiarvo. Tiimin on päätettävä tästä ennen suunnittelupokeri-istuntoa. Harjoituskoe CTFL FA Sivu 13/ , käännös , Finnish Board
14 Kysymys 33 FA (K3) Osaat tulkita oikeanlaista tietoa testauksen tehtävien tukemiseksi A. Väärin katso perustelut alla. B. Väärin katso perustelut alla. C. Oikein katso perustelut alla. D. Väärin katso perustelut alla. i. Tämä auttaa koska tiedämme, että standardista on olemassa uusi versio; olemassa olevia testitapauksia täytyy muokata tai uusia täytyy lisätä. ii. Tämä auttaa riskianalyysin aikana. iii. Tästä tiedosta ei ole hyötyä, sillä sisäänkirjautuminen muuttuu laitteen uuden julkaisun myötä ja uudet käyttäjätarinat on kirjoitettu. iv. Koska käyttöön otetaan uutta teknologiaa, on tarpeen hankkia vertailupohja samankaltaista teknologiaa käyttävistä laitteista tai tämän tyyppiselle teknologialle määritellyistä suorituskykyvaatimuksista. v. Tämä auttaa riskianalyysin aikana. Kysymys 34 FA (K2) Osaat selittää liiketoiminnan edustajille, kuinka määritetään testattava hyväksymiskriteeri A. Väärin Sekä testitapauksia että testausohjetta käytetään pohjana sille, mitä testataan. Suoritettujen testitapausten määrä ei kerro siitä, mitä testeillä on katettu (testausohjeiden määrä ei myöskään anna hyödyllistä tietoa kattavuudesta). B. Väärin Väite itsessään on riittämätön. Se tarvitsee tuekseen lisätietoa koskien testikattavuutta ja asiaan liittyviä riskejä. C. Oikein Saavutettu testikattavuus ja siihen liittyvät lisätiedot tekevät tästä parhaan vaihtoehdon, vaikka lisätietoja tarvitaankin. Niihin kuuluvat tiedot löydetyistä vioista, niiden vakavuudesta ja luokittelusta (kuinka monta vakavaa ongelmaa kullakin alueella). Tämä tieto antaa paremman perustan julkaisupäätökselle. Lisäksi tarvitaan tietoa arvioiduista ominaisuuksista ja siitä, kuinka ne vaikuttavat järjestelmän valmistumisen koko kuvaan, sekä niihin liittyvästä testauksesta. D. Väärin Iteraation/sprintin loppu antaa kuvan, että testaus lopetetaan, koska aikaa ei ole enempää, mikä ei ole paras kriteeri testauksen lopettamiselle. Harjoituskoe CTFL FA Sivu 14/ , käännös , Finnish Board
15 Kysymys 35 FA (K2) Osaat selittää liiketoiminnan edustajille, kuinka määritetään testattava hyväksymiskriteeri A. Väärin Ei testattavissa, odotettuja lasilaatikkotekniikoita tai kattavuutta ei ole kuvattu tarkemmin. B. Oikein Testattavissa. C. Oikein Testattavissa. D. Väärin Ei testattavissa, emme tiedä, mikä on kohtuullinen vasteaika. E. Väärin Ei testattavissa, selaimet täytyy määritellä. Tärkeimmistä selaimista voidaan tehdä oletuksia. Kysymys 36 FA (K3) Osaat kirjoittaa testitapauksia käyttäjätarinalle hyväksymistestiohjatussa kehityksessä A. Väärin katso perustelut alla. B. Väärin katso perustelut alla. C. Väärin katso perustelut alla. D. Oikein katso perustelut alla. i. Väärin Käyttäjätarina liittyy asiakkaan tapahtumahistoriaan. ii. Oikein Tämä testi liittyy pankkitoimihenkilön rooliin ja tuloksena on asiakkaan pankkitapahtumien katselu. iii. Oikein Tämä testi liittyy pankkitoimihenkilön rooliin ja tuloksena on asiakkaan pankkitapahtumien katselu. iv. Oikein Tämä testi liittyy pankkitoimihenkilön rooliin ja tuloksena on asiakkaan pankkitapahtumien katselu.. v. Väärin Käyttäjätarinassa ei mainita suorituskykyyn liittyviä vaatimuksia. Kysymys 37 FA (K3) Osaat kirjoittaa testitapauksia sekä toiminnalliselle että ei-toiminnalliselle käyttäytymiselle perustuen annettuihin käyttäjätarinoihin käyttäen mustalaatikkosuunnittelutekniikoita A. Väärin Käyttäjätarina ei keskity järjestelmän tiloihin vaan tarkoitus on testata toimituskuluja. B. Väärin Käyttäjätarina ei keskity siihen, onko tuote toimitettu odotetusti, tarkoitus on testata toimituskuluja. C. Oikein Raja-arvoanalyysi on paras vaihtoehto, kun testataan toimituskuluja. D. Väärin Käyttäjätarina ei keskity siihen, onko tuote toimitettu odotetusti, tarkoitus on testata toimituskuluja. Harjoituskoe CTFL FA Sivu 15/ , käännös , Finnish Board
16 Kysymys 38 FA (K3) Osaat suorittaa tutkivaa testausta ketterässä projektissa A. Oikein Tämä ei ole kelvollinen syy, koska tutkiva testaus ei pysty estämään vikojen syntymistä testien analysoinnin, suunnittelun ja suorituksen yhtäaikaisuuden ja reaktiivisuuden takia. B. Väärin Tutkiva testaus tunnetaan kokemuspohjaisena testauksen lähestymistapana, ja se on yhtä tehokas kuin testaaja, joka testausta tekee. Lähestymistavan etu on se, että suunnitellut ja suoritetut testit vaikuttavat seuraavaksi suunniteltaviin ja suoritettaviin testeihin. C. Väärin Tutkiva testaus ei ole tekniikka vaan testauksen lähestymistapa, joka voi käyttää muita tekniikoita, kuten parien testausta, luokittelupuuta, raja-arvoanalyysiä jne. D. Väärin Yksi tutkivasta testauksesta hyötyvä tilanne on se, kun vaatimukset eivät ole parhaita mahdollisia, ja ketterät projektit ovat rajallisia vaatimusten analysoinnin, syvyyden ja yksityiskohtaisuuden suhteen. Kysymys 39 FA (K1) Muistat saatavilla olevia testauksen työkaluja niiden tarkoituksen ja toimintojen mukaan ketterissä projekteissa A. Väärin Tämä on yksi wikin tarkoituksista, ei ALM-työkalun. B. Väärin Tämä on yksi jatkuvan integraation työkalun tarkoituksista, ei ALM-työkalun. C. Oikein Tämä on yksi monista ALM-työkalun käyttötarkoituksista, mutta työkalun käyttö mahdollistaa tiiviimmän yhteistyön hajautetuissa tiimeissä kuin fyysiset tehtävätaulut. D. Väärin Tämä on yksi aineiston generointi- ja lataustyökalun tarkoituksista, ei ALM-työkalun. Kysymys 40 Ketterä laajennos -Termi (K1) A. Väärin Tämä on oikein, katso sertifikaattisisällön kappale B. Oikein Testausohjeet luodaan ennen testien suoritusta ja niihin sisältyvät testauksen tavoitteet ja testattavat kohteet. C. Väärin Tämä on oikein, katso sertifikaattisisällön kappale D. Väärin Tämä on oikein, testaajalla täytyy olla vankka ymmärrys siitä, kuinka järjestelmää käytetään ja miten määritellään, milloin järjestelmä ei toimi. Harjoituskoe CTFL FA Sivu 16/ , käännös , Finnish Board
Harjoituskoe ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus
Harjoituskoe ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus Alkup. versio 1.0 Käännösversio 1.0 Tekijänoikeushuomautus: Tämän dokumentin saa kopioida kokonaisuudessaan tai siitä
Tapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
Ohjelmistojen mallintaminen. Luento 11, 7.12.
Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,
Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille
1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei
Onnistunut SAP-projekti laadunvarmistuksen keinoin
Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.
Sertifioitu testaaja Certified Tester. Perustason sertifikaattisisällön laajennos Ketterä testaaja. Foundation Level Extension Syllabus Agile Tester
Sertifioitu testaaja Certified Tester Perustason sertifikaattisisällön laajennos Ketterä testaaja Foundation Level Extension Syllabus Agile Tester Versio 2014 Käännösversio 2015 Perustuu englanninkieliseen
Käyttäjätarinat perinteisessä hankkeessa. Sisältö ja käytännöt
Käyttäjätarinat perinteisessä hankkeessa Sisältö ja käytännöt Helsingin kaupunki 21/03/17 Käyttäjätarinat perinteisessä hankkeessa Mikä on käyttäjätarina Käyttäjätarina perinteisessä hankkeessa Käyttäjätarinan
Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen
Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia
Onnistunut Vaatimuspohjainen Testaus
Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)
Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg
Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg Symbio lyhyesti Innovatiivinen tuotekehitys- ja testauskumppani Juuret Suomessa, perustettu 1997 Laadukkaat ohjelmistotoimitukset
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 28.10.2013 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus
Mihin kaikkeen voit törmätä testauspäällikön saappaissa?
Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tiera on vuonna 2010 perustettu yli 200:n kuntatoimijan omistama
Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }
Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.
Yleiskatsaus. Perustason sertifikaattisisällön laajennokset
Perustason sertifikaattisisällön laajennokset Versio 1.0 Tekijänoikeushuomautus Tämän dokumentin saa kopioida kokonaisuudessaan, tai siitä saa tehdä otteita, mikäli lähde mainitaan. Tekijänoikeushuomautus
Mihin kaikkeen voit törmätä testauspäällikön saappaissa?
Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tieran toiminta perustuu osaamisverkoston rakentamiseen, mikä
Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan
Tutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 27.10.2014 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus
Testaaminen ohjelmiston kehitysprosessin aikana
Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/
KOODAAKO PROJEKTIPÄÄLLIKKÖ?
KOODAAKO PROJEKTIPÄÄLLIKKÖ? - ROOLIODOTUKSET KETTERISSÄ OHJELMISTOPROJEKTEISSA Mikko Viskari Development Manager Ohjelmistoprojektikokemusta vuodesta 2005 Teknisen projektipäällikön roolissa vuodesta 2011
Scrumin käyttö ketterässä sovelluskehityksessä
Scrumin käyttö ketterässä sovelluskehityksessä 9.4.2008 Janne Kuha Manager, Java Services Descom Oy Janne Kuha Manager, Java Services janne.kuha@descom.fi Kuka? Descom Oy:llä, sitä ennen Wanadu Inc., Mountain
Test-Driven Development
Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole
Ajatuksia ketterästä ohjelmistokehityksestä ja laadusta
Ajatuksia ketterästä ohjelmistokehityksestä ja laadusta 2012-11-26 1 Quality Manager & Specialist, Testing /Cybercom Finland CMMI, TMMI FiSTB:n varapuheenjohtaja ja hallituksen jäsen (http://www.fistb.fi)
Sopisiko testiautomaatio yritykseesi juuri nyt? Testiautomaation soveltuvuuden arviointiopas
Sopisiko testiautomaatio yritykseesi juuri nyt? Testiautomaation soveltuvuuden arviointiopas www.valagroup.fi TESTITAUTOMAATIO SINUN YRITYKSEESI? Testauksen automatisointi ei sovellu kaikkiin tilanteisiin;
T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
Dynaaminen analyysi IV
Dynaaminen analyysi IV Luento 9 Antti-Pekka Tuovinen 16 April 2013 1 Tavoitteet Kokemusperäinen testitapausten suunnittelu Yhteenvetoa suunnittelutekniikoista 16 April 2013 2 1 Testitapausten kokemusperäinen
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen
Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Kokemusperäinen testitapausten suunnittelu Yhteenvetoa suunnittelutekniikoista 23 April 2018 2 Testitapausten kokemusperäinen
Copyright by Haikala. Ohjelmistotuotannon osa-alueet
Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary
LAATURAPORTTI Iteraatio 1
LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja
COTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant
AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision
Scrum is Not Enough. Scrum ei riitä. Ari Tanninen & Marko Taipale. Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.
Scrum is Not Enough Scrum ei riitä Ari Tanninen & Marko Taipale Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.2009 Ari Tanninen Vanhempi ohjelmistoinsinööri Marko Taipale Teknologiajohtaja,
Sisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä
SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan
@Tampereen Testauspäivät (2012-06)
@Tampereen Testauspäivät (2012-06) Testausodotukset räätälöityjen järjestelmien projekteissa Maaret Pyhäjärvi, testausasiantuntija Twitter: maaretp Testausvastaava @ Granlund Oy Yrittäjä
Ohjelmiston testaussuunnitelma
Ohjelmiston testaussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä lukaa antaa yleiskuvan koko testausdokumentista.
Sisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
Ohjelmistoprojekteista. Datanomiopiskelijat 2.vuosi
Ohjelmistoprojekteista Datanomiopiskelijat 2.vuosi Yleistä projekteista Projekti on selkeästi asetettuihin tavoitteisiin pyrkivä, ajallisesti rajattu kertaluonteinen hanke, jonka toteuttamisesta vastaa
Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle
Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle Tarkistuslista on suunniteltu käytettäväksi hyväksymistestauksen suunnittelussa, valmiuksien arvioinnissa ja katselmoinnissa.tämä tarkistuslista
KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ
KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset
Project-TOP QUALITY GATE
Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä
Onnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden
Lyhyt johdatus ketterään testaukseen
TTY:n Testauspäivät, Tampere 15.8.2006 Lyhyt johdatus ketterään testaukseen eli Ketterän ohjelmistokehityksen laatukäytäntöjä Juha Itkonen SoberIT Teknillinen korkeakoulu Juha.Itkonen@tkk.fi Ketterä ohjelmistokehitys
Testataanko huomenna?
Testataanko huomenna? Qentinel Group 2014 Esko Hannula 03.06.2014 Ohjelmistokriisistä testauskriisiin 1985: Ohjelmistot ovat huonolaatuisia ja aina myöhässä Jonkun pitäisi testata, ehkäpä noiden huonoimpien
TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - VYM JA KANTA Versio 1.0 i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen
Ohjelmistotestaus -09
Ohjelmistotestaus Testaustyökalut- ja automaatio Testaustyökalut ja -automaatio Testaustyökaluilla tuetaan testaustyötä sen eri vaiheissa Oikea työkalu oikeaan tarkoitukseen Testausautomaatio perustuu
Automaattinen yksikkötestaus
Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen
Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä Simo Tauriainen www.ponsse.com 25.8.2011 Ponsse-konserni Ponsse Oyj on tavaralajimenetelmän metsäkoneiden myyntiin, tuotantoon, huoltoon ja
TESTIRAPORTTI - JÄRJESTELMÄ, ADMIN Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - JÄRJESTELMÄ, ADMIN i Sisällysluettelo DUMENTIN VERSIOT 1 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI
TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL i Sisällysluettelo DUMENTIN VERSIOT 1 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI
Uudelleenkäytön jako kahteen
Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta
Koekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky
Koekysymyksiä Ohjelmistoprosessit ja ohjelmistojen laatu 30.4.2015 58153003 Ohjelmistojen suorituskyky 1 Kurssikokeeseen tulee neljä koetilaisuudessa vastattavaa kysymystä KOKEESSA VASTATTAVAT KYSYMYKSET
UCOT-Sovellusprojekti. Testausraportti
UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä
Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14
Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu
Test-Driven Development
Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia
Kuopio Testausraportti Asiakkaat-osakokonaisuus
Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki
Hirviö Laadunvarmistussuunnitelma
Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 30. marraskuuta 2004 1 Sisältö 1 Johdanto 3 1.1 Testauksen tavoitteet
Ketterä projektinhallinta
Ketterä projektinhallinta Petri Heiramo Agile Coach, CST 1 Petri Heiramo Ikä: 37 (vielä pari päivää ) Oma koulutus- ja valmennusyritys, Agilecraft Oy, reilut 3 viikkoa Lähes 10v ohjelmistokehitys- ja -prosessitausta
Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versi Päiväys Tekijä Kuvaus o 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto
Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi
Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen
Convergence of messaging
Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO
Testaajan eettiset periaatteet
Testaajan eettiset periaatteet Eettiset periaatteet ovat nousseet esille monien ammattiryhmien toiminnan yhteydessä. Tämä kalvosarja esittelee 2010-luvun testaajan työssä sovellettavia eettisiä periaatteita.
Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza
Testaussuunnitelma Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Versio 1.0 Ehdotus Laatija Raine Kauppinen VERSIOHISTORIA Versionotyyppi Versio- Päiväys Tekijä
Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio
Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista
statbeatmobile PROJECT REVIEW iteration 1
statbeatmobile PROJECT REVIEW iteration 1 agenda Projekti Status Käytännöt Tulokset Katsaus eteenpäin PROJEKTI / mikä on statbeat? Sosiaalinen joukkueurheilupalvelu Keskustelu, fanit, kavereiden joukkueet,
Tilannekatsaus 4.11.2013. Opintopolku.fi
Tilannekatsaus 4.11.2013 tilannekatsaus 4.11.2013 Muuntotyön tilanne AT/EAT muunnossa olleet aineistot toimitettu Opetushallitukselle. Muunnettuja tutkintoja 114, 13 tutkintoa jäänyt muuntamatta niihin
Nexus Guide. Nexuksen määritelmä ja opas: Skaalatun Scrum-kehityksen viitekehys. Nexusta ylläpitää ja kehittää Ken Schwaber ja Scrum.
Nexus Guide Nexuksen määritelmä ja opas: Skaalatun Scrum-kehityksen viitekehys Nexusta ylläpitää ja kehittää Ken Schwaber ja Scrum.org Elokuu 2015 Sisällysluettelo Nexuksen yleiskatsaus... 1 Nexus Guiden
Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
JULKISTEN PALVELUJEN ELINKAARI; HYVÄ PALVELU EILEN, TÄNÄÄN, HUOMENNA MIHIN PALVELUT OVAT MENOSSA? Lauri Helenius, Solita Oy
JULKISTEN PALVELUJEN ELINKAARI; HYVÄ PALVELU EILEN, TÄNÄÄN, HUOMENNA MIHIN PALVELUT OVAT MENOSSA? 24.10.2017 Lauri Helenius, Solita Oy Solitalaisia yli 650 Liikevaihto 2016 67 M Keski-ikä 36 V. Kasvu 2016
Testaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA
Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta
Ohjelmistotestauksen perusteita II
Ohjelmistotestauksen perusteita II Luento 2 Antti-Pekka Tuovinen 14 March 2013 1 Luennon oppimistavoitteet Testausprosessin perustoiminnot Testauksen psykologiaa Testauksen seitsemän periaatetta 14 March
VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D
VERSIONHALLINTA PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D Versio Päivä Tekijä Kuvaus 0.1 26.10.2005 Kaarlo Lahtela Ensimmäinen versio 0.2 10.12.2006 Lauri Kiiski Suomennettu 3 (8 ) SISÄLLYS
Nexus Guide. Nexuksen määritelmä ja opas: Skaalatun scrum-kehityksen viitekehys. Nexusta ylläpitää ja kehittää Ken Schwaber ja Scrum.
Nexus Guide Nexuksen määritelmä ja opas: Skaalatun scrum-kehityksen viitekehys Nexusta ylläpitää ja kehittää Ken Schwaber ja Scrum.org Elokuu 2015 Sisällysluettelo Nexuksen yleiskatsaus... 1 Nexus Guiden
Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure
Automaattinen regressiotestaus ilman testitapauksia Pekka Aho, VTT Matias Suarez, F-Secure 2 Mitä on regressiotestaus ja miksi sitä tehdään? Kun ohjelmistoon tehdään muutoksia kehityksen tai ylläpidon
Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versio Päiväys Tekijä Kuvaus 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto
Ohjelmiston toteutussuunnitelma
Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,
Harjoituskoe. ISTQB Perustaso sertifikaattisisältö
ISTQB Perustaso 2011 sertifikaattisisältö International Software Testing Qualifications Board Copyright International Software Testing Qualifications Board (jäljempänä ISTQB TM ) Kaikki oikeudet pidätetään.
HYVÄKSYMISTESTAUS- RAPORTTI - HAKEUTUJAN PALVELUT JA TODENNETUN OSAAMISEN REKISTERI
HYVÄKSYMISTESTAUS- RAPORTTI - HAKEUTUJAN PALVELUT JA TODENNETUN OSAAMISEN REKISTERI 13.5.2013 Dokumentin tallennuspaikka Sivu 1/8 SISÄLLYSLUETTELO 1 DOKUMENTIN TARKOITUS... 3 2 TESTAUKSEN TILANNE... 3
Työkalut ohjelmistokehityksen tukena
1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan
TIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21201 Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 20.9.2016 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
Harjoitustyön testaus. Juha Taina
Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida
Laadunvarmistusdokumentti
Laadunvarmistusdokumentti Dokumentin historia Versio Päiväys Muokkaaja Kuvaus Hyväksytty 1.10 07.11.2005 Rönkkö Kirsi Erotettu omaksi dokumentikseen Sisällysluettelo 1. Koko projektissa...2 1.1. Tavoitteet...2
Ketterä vaatimustenhallinta
Ketterä vaatimustenhallinta ja miksi se on useimmiten hyvä asia K A R I A L HO C E O I M P R OV EIT OY Sisältö ImproveIt Oy Perinteinen vaatimushallinta Ketterä vaatimustenhallinta Monenlaista softakehitystä
Testaussuunnitelma. Ohjelmistotuotantoprojekti Nero. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Ohjelmistotuotantoprojekti Nero Helsinki 5.11.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä
T Testiraportti - järjestelmätestaus
T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria
Testaus elinkaaressa
Testaus elinkaaressa Järjestelmätestaus Järjestelmätestaus Tarkoittaa koko järjestemän laajuuteen kohdistuvaa testausta, koko järjestelmän toiminnan näkökulmasta Järjestelmän ei tarvitse olla valmis vaan
T Ohjelmistotuotannon seminaari. Agile Processes. XP:n hyväksymistestit
T-76.650 Ohjelmistotuotannon seminaari Agile Processes XP:n hyväksymistestit 15.4.2002 Mikko Pasanen 49159H Tik N mspasane@cc.hut.fi Tiivistelmä 2 Extreme Programming on kevyt ohjelmistokehityksen metodologia,
Ohjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
Digitaalisuudesta muutosvoimaa
Digitaalisuudesta muutosvoimaa 6.9.2018 Megatrendejä ja ajankohtaisia teknologiatrendejä Globalisaatio Teknologian kehitys Demografiset muutokset Ilmastomuutos Laskentakapasiteetin kasvu, kvanttitietokoneet
Kaupunginkanslian avoin ohjelmistokehitys, rajapintatyö, syksy kevät Projektitarpeen ja tavoitteiden kuvaus
n avoin ohjelmistokehitys, rajapintatyö, syksy 2018 - kevät 2019 2/7 1 LYHYT KUVAUS 2 PUITESOPIMUKSESTA POIKKEAVAT JA ERIKSEEN SOVITTAVAT KOHDAT NYKYTILA 4 4 TILAUKSEN AIKAJANA 5 KOKOONPANO, OSALLISTUJAT
KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen
KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 NOPEA KERTAUS VIIME KERROISTA ERILAISIA T YÖKALUT YYPPEJÄ Millä työkaluilla testausta sitten tehdään? Suurin osa ohjelmistojen
Harjoituskoe Vastaukset perusteluineen. ISTQB Perustaso sertifikaattisisältö
Vastaukset perusteluineen ISTQB Perustaso 2011 sertifikaattisisältö International Software Testing Qualifications Board Copyright International Software Testing Qualifications Board (jäljempänä ISTQB TM