Source: http://docplayer.fi/1331749-Sertifioitu-testaaja-certified-tester-perustason-sertifikaattisisallon-laajennos-kettera-testaaja-foundation-level-extension-syllabus-agile-tester.html
Timestamp: 2017-01-24 11:50:34+00:00
Document Index: 6615788

Matched Legal Cases: ['kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ']

⭐Sertifioitu testaaja Certified Tester. Perustason sertifikaattisisällön laajennos Ketterä testaaja. Foundation Level Extension Syllabus Agile Tester
Download "Sertifioitu testaaja Certified Tester. Perustason sertifikaattisisällön laajennos Ketterä testaaja. Foundation Level Extension Syllabus Agile Tester"
1 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 versioon Based on English version 31st of May, 20142 Tekijänoikeushuomautus Tämän dokumentin saa kopioida kokonaisuudessaan tai siitä saa tehdä otteita, mikäli lähde mainitaan. Tekijänoikeushuomautus (jäljempänä ISTQB ). Perustason sertifikaattisisällön Ketterä testaaja laajennoksen työryhmä: Rex Black (Puheenjohtaja), Bertrja Cornanguer (Varapuheenjohtaja), Gerry Coleman (Oppimistavoitteet), Debra Friedenberg (Koe), Alon Linetzki (Liiketoiminnalliset tulokset ja markkinointi), Tauhida Parveen (Julkaisija) ja Leo van der Aalst (Kehitys). Tekijät: Rex Black, Jaers Claesson, Gerry Coleman, Bertrja Cornanguer, Istvan Forgacs, Alon Linetzki, Tilo Linz, Leo van der Aalst, Marie Walsh ja Stephan Weber. Sisäiset katselmoijat: Mette Bruhn-Pedersen, Christopher Clements, Alessjaro Collino, Debra Friedenberg, Kari Kakkonen, Beata Karpinska, Sammy Kolluru, Jennifer Leger, Thomas Mueller, Tuula Pääkkönen, Meile Posthuma, Gabor Puhalla, Lloyd Roden, Marko Rytkönen, Monika Stoecklein-Olsen, Robert Treffny, Chris Van Bael ja Erik van Veenendaal; Suomenkielisen version toteutukseen ja katselmointiin ovat osallistuneet seuraavat henkilöt: Kimmo Hakala, Minna Aalto, Kari Kakkonen, Marko Rytkönen, Lare Lekman, Soile Sainio ja Tommi Välimäki. Käännösversio 2015 Sivu 2 / FiSTB3 Versiohistoria Versio Päivä Huomiot Syllabus v Itsenäiset osat Syllabus v Työryhmän katselmoinnin kommentit versiosta 01 sisällytetty Syllabus v Työryhmän katselmoinnin kommentit versiosta 02 sisällytetty Syllabus v Alfakatselmoinnin kommentit versiosta 03 sisällytetty Syllabus v Työryhmäpäivitykset versiosta 07 Syllabus v Beetaversio Syllabus GA -versio Syllabus Kirjoitusvirheitä korjattu suomenkielinen versio Käännösversio GA -versiosta Käännösversio 2015 Sivu 3 / FiSTB4 Sisällysluettelo Versiohistoria...3 Sisällysluettelo...4 Kiitokset Johdatus tähän sertifikaattisisältöön Tämän dokumentin tarkoitus Yleiskatsaus Tentittävät oppimistavoitteet Ketterä ohjelmistokehitys minuuttia Ketterän ohjelmistokehityksen perusteet Ketterä ohjelmistokehitys ja ketterän ohjelmistokehityksen manifesti Tiimiperusteinen lähestymistapa Aikainen ja säännöllinen palaute Näkökulmia ketteriin lähestymistapoihin Ketterän ohjelmistokehityksen lähestymistapoja Yhteistyössä tapahtuva käyttäjätarinoiden luonti Retrospektiivit Jatkuva integraatio Julkaisun ja iteraation suunnitteleminen Keskeiset ketterän testauksen periaatteet, käytännöt ja prosessit 105 minuuttia Eroavaisuuksia perinteisten ja ketterien lähestymistapojen testauksessa Testauksen ja kehityksen tehtävät Projektin työn tulokset Testitasot Testaus ja kokoonpanonhallinta Riippumattoman testauksen organisatoriset vaihtoehdot Testauksen asema ketterissä projekteissa Testauksen tilanteen, edistymisen ja tuotelaadun kommunikointi Regressioriskin hallinta manuaalisten ja automatisoitujen testitapausten kehittämisen avulla Testaajan rooli ja taidot ketterässä tiimissä Ketterän testaajan taidot Testaajan rooli ketterässä tiimissä Ketterät testausmenetelmät, tekniikat ja työkalut 480 minuuttia Ketterät testausmenetelmät Testiohjattu kehitys, hyväksymistestiohjattu kehitys ja käyttäytymisperustainen kehitys Testipyramidi Testausneljännes, testitasot ja testityypit Testaajan rooli Laaturiskien arviointi ja testauksen työmäärän arviointi Laaturiskien arviointi ketterissä projekteissa Testauksen työmäärän arviointi perustuen sisältöön ja riskiin Ketterien projektien tekniikoita Hyväksymiskriteerit, riittävä kattavuus sekä muut testauksen tiedot Hyväksymistestiohjatun kehityksen soveltaminen Toiminnallinen ja ei-toiminnallinen mustalaatikkotestisuunnittelu Tutkiva testaus ja ketterä testaus Työkalut ketterissä projekteissa Tehtävänhallinta- ja seurantatyökalut Kommunikoinnin ja tiedon jakamisen työkalut Ohjelmiston koonnin ja levityksen työkalut Kokoonpanonhallinnan työkalut Testien suunnittelun, toteuttamisen ja suorittamisen työkalut Käännösversio 2015 Sivu 4 / FiSTB5 3.4.6 Pilvilaskenta- ja virtualisointityökalut Viitteet Standardit ISTQB dokumentit Kirjat Ketterä terminologia Muita viitteitä Asiahakemisto Käännösversio 2015 Sivu 5 / FiSTB6 Kiitokset Tämän dokumentin tuotti Foundation -tason työryhmä. Ydintiimi kiittää katselmointitiimiä ja kansallisia hallituksia ehdotuksistaan sekä palautteestaan. Ydintiimin jäsenet: Rex Black (Puheenjohtaja), Bertrja Cornanguer (Varapuheenjohtaja), Gerry Coleman (Oppimistavoitteet), Debra Friedenberg (Koe), Alon Linetzki (Liiketoiminnallinen tulos ja markkinointi), Tauhida Parveen (Julkaisija) ja Leo van der Aalst (Kehitys). Tekijät: Rex Black, Jaers Claesson, Gerry Coleman, Bertrja Cornanguer, Istvan Forgacs, Alon Linetzki, Tilo Linz, Leo van der Aalst, Marie Walsh ja Stephan Weber. Sisäiset katselmoijat: Mette Bruhn-Pedersen, Christopher Clements, Alessjaro Collino, Debra Friedenberg, Kari Kakkonen, Beata Karpinska, Sammy Kolluru, Jennifer Leger, Thomas Mueller, Tuula Pääkkönen, Meile Posthuma, Gabor Puhalla, Lloyd Roden, Marko Rytkönen, Monika Stoecklein-Olsen, Robert Treffny, Chris Van Bael ja Erik van Veenendaal. Ydintiimi haluaa kiittää myös seuraavia henkilöitä kansallisista hallituksista ja Agile expert yhteisöstä, jotka osallistuivat katselmointiin, kommentointiin sekä tämän sertifikaattisisällön äänestyksen toimittamiseen: Dani Almog, Richard Berns, Stephen Bird, Monika Bögge, Afeng Chai, Josephine Crawford, Tibor Csöndes, Huba Demeter, Arnaud Foucal, Cyril Fumery, Kobi Halperin, Inga Hansen, Hanne Hinz, Jidong Hu, Phill Isles, Shirley Itah, Martin Klonk, Kjell Lauren, Igal Levi, Rik Marselis, Johan Meivert, Armin Metzger, Peter Morgan, Ninna Morin, Ingvar Nordstrom, Chris O Dea, Klaus Olsen, Ismo Paukamainen, Nathalie Phung, Helmut Pichler, Salvatore Reale, Stuart Reid, Hans Rombouts, Petri Säilynoja, Soile Sainio, Lars-Erik Sjaberg, Dakar Shalom, Jian Shen, Marco Sogliani, Lucjan Stapp, Yaron Tsubery, Sabine Uhde, Stephanie Ulrich, Tommi Välimäki, Jurian Van de Laar, Marnix Van den Ent, António Vieira Melo, Wenye Xu, Ester Zabar, Wenqiang Zheng, Peter Zimmerer, Stevan Zivanovic ja Terry Zuo. Tämä dokumentti on muodollisesti hyväksytty julkaistavaksi ISTQB :n yleiskokouksessa 31. Toukokuuta Suomenkielisen version toteutukseen ja katselmointiin ovat osallistuneet seuraavat henkilöt: Kimmo Hakala, Minna Aalto, Kari Kakkonen, Marko Rytkönen, Lare Lekman, Soile Sainio ja Tommi Välimäki. Käännösversio 2015 Sivu 6 / FiSTB7 0. Johdatus tähän sertifikaattisisältöön 0.1 Tämän dokumentin tarkoitus Tämä sertifikaattisisältö muodostaa pohjan Qualification -vaatimusten perustasolle ketterään testaukseen. ISTQB antaa tämän sertifikaattisisällön käyttöön seuraavasti: Kansallisille hallituksille käännettäväksi paikalliselle kielelle ja valtuutetuille koulutuksentarjoajille. Kansalliset hallitukset voivat muokata sertifikaattisisältöä paikallisen kielen tarpeiden mukaisesti sekä muokata lähdeviittauksia sovittaen ne paikallisiin julkaisuihin. Kansallisille tutkintolautakunnille pohjaksi tuotettaessa koekysymyksiä paikalliselle kielelle sovitettuna sertifikaattisisällön oppimistavoitteisiin. Koulutuksen tarjoajille kurssimateriaalin tuottamiseen ja sopivien oppimismenetelmien määrittämiseen. Sertifiointikandidaateille kokeeseen valmistautumiseen (osana harjoituskurssia tai itsenäisesti). Kansainväliselle ohjelmisto- ja systeemitekniikan yhteisölle kehittämään ohjelmisto- ja systeemitestauksen ammattia sekä perustaksi kirjoille ja artikkeleille. ISTQB voi sallia muita entiteettejä käyttämään tätä sertifikaattisisältöä toisiin tarkoituksiin antamalla etukäteen kirjallisen luvan. 0.2 Yleiskatsaus Perustason sertifikaattisisällön laajennoksen yleiskatsausdokumentti [ISTQB_FA_OVIEW_FI] sisältää seuraavat tiedot: Liiketoiminnalliset tulokset sertifikaattisisällölle Tiivistelmä sertifikaattisisällöstä Syysuhteet sertifikaattisisältöjen välillä Oppimistavoitteiden kuvaukset (K -tasot) Liitteet 0.3 Tentittävät oppimistavoitteet Oppimistavoitteita käytetään Perustason sertifikaatin Ketterä testaaja laajennoksen oppisisällön tenttimiseen sertifikaatin saavuttamiseksi. Yleisesti, tämän sertifikaattisisällön kaikki osat ovat K1 -tason tentittäviä ja se tarkoittaa, että kokelas tunnistaa, muistaa ja pystyy palauttamaan mieleensä termin tai käsitteen. Määrätyt oppimistavoitteet tasoilla K1, K2 ja K3 kuvataan asiaankuuluvan luvun alussa. Käännösversio 2015 Sivu 7 / FiSTB8 1. Ketterä ohjelmistokehitys minuuttia Avainsanat Ketterä manifesti, ketterä ohjelmistokehitys, vaiheittainen kehittämismalli, iteratiivinen kehittämismalli, ohjelmiston elinkaari, testausautomaatio, testauksen kohteen kuvaus, testauslähtöinen ohjelmistokehitys, testioraakkeli, käyttäjätarina Oppimistavoitteet ketterälle ohjelmistokehitykselle 1.1 Ketterän ohjelmistokehityksen perusteet FA manifestiin FA FA (K1) Muistat ketterän ohjelmistokehityksen käsitteen, joka perustuu ketterään (K2) Ymmärrät tiimiperusteisen lähestymistavan edut (K2) Ymmärrät aikaisen sekä jatkuvan palautteen merkityksen 1.2 Näkökulmia ketteriin lähestymistapoihin FA (K1) Muistat ketterän ohjelmistokehityksen näkökulmia FA (K3) Osaat kirjoittaa testattavia käyttäjätarinoita yhteistyössä kehittäjien sekä liiketoiminnan edustajien kanssa FA (K2) Ymmärrät kuinka retrospektiivejä voidaan hyödyntää ketterien projektien prosessikehityksessä FA (K2) Ymmärrät jatkuvan integraation käytön sekä tarkoituksen FA (K1) Tiedät miten iteraation ja julkaisun suunnittelu eroavat toisistaan. Ymmärrät kuinka testaaja tuo lisäarvoa niissä tapahtuviin tehtäviin 1.1 Ketterän ohjelmistokehityksen perusteet Ketterän projektin testaaja työskentelee eri tavalla kuin testaaja perinteisessä projektissa. Testaajan täytyy ymmärtää ketteriä projekteja tukevat arvot ja periaatteet. Testaajan täytyy myös ymmärtää merkityksensä osana tiimiperustaista lähestymistapaa yhdessä kehittäjien ja liiketoiminnan edustajien kanssa. Ketterässä projektissa työskentelevien henkilöiden kommunikointi on aikaista ja jatkuvaa, mikä auttaa havaitsemaan vikoja aikaisin ja kehittämään laadukkaan tuotteen Ketterä ohjelmistokehitys ja ketterän ohjelmistokehityksen manifesti Vuonna 2001 joukko laajimmin käytettyjen kevyiden ohjelmistokehitysmenetelmien edustajia sopi yhteisestä arvolauseiden ja periaatteiden joukosta, joka tuli tunnetuksi Ketterän ohjelmistokehityksen julistuksena tai Ketteränä manifestina. Ketterä manifesti sisältää neljä lausetta. Kokemuksemme perusteella arvostamme: Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja Muutokseen reagoimista enemmän kuin pitäytymistä suunnitelmassa Ketterä manifesti esittää, että vaikka edellä mainittujen lauseiden oikealla puolellakin olevilla käsitteillä on arvoa, vasemmalla puolella olevia käsitteitä arvostetaan kuitenkin enemmän. Käännösversio 2015 Sivu 8 / FiSTB9 Yksilöt ja kanssakäyminen Ketterä ohjelmistokehitys on hyvin ihmiskeskeistä. Tiimit muodostuvat henkilöistä, jotka kehittävät ohjelmiston. Tiimin tehokkaassa työskentelyssä on kyse pikemminkin jatkuvasta kommunikoinnista ja kanssakäymisestä kuin turvautumisesta työkaluihin ja prosesseihin. Toimiva ohjelmisto Asiakkaan näkökulmasta toimiva ohjelmisto on paljon hyödyllisempi ja arvokkaampi kuin hyvin tarkka dokumentaatio ja se tarjoaa mahdollisuuden antaa kehittäjille nopeaa palautetta. Lisäksi toimiva ohjelmisto (vaikkakin rajoitetuilla toiminnoilla) on saatavilla paljon aikaisemmin kehityksen elinkaaressa, mikä voi nopeuttaa merkittävästi tuotteen julkaisua markkinoille. Näin ollen ketterä ohjelmistokehitys on erityisen hyödyllinen nopeasti muuttuvissa liiketoimintaympäristöissä, joissa ongelmat ja/tai ratkaisut ovat epäselviä, tai joissa liiketoiminta toivoo innovoivansa uusilla ongelma-alueilla. Asiakasyhteistyö Asiakkaan on usein hyvin vaikea määritellä haluamaansa järjestelmää ja tiivis yhteistyö asiakkaan kanssa parantaa todennäköisyyttä ymmärtää asiakkaan vaatimukset. Vaikka asiakkaan kanssa tehdyn sopimuksen merkitys on suuri, säännöllinen ja läheinen yhteistyö asiakkaan kanssa auttaa todennäköisesti onnistumaan paremmin projektissa. Vastaaminen muutokseen Muutos on väistämätöntä ohjelmistoprojekteissa. Lainsäädännöllä, kilpailijoiden toiminnalla, tekniikan kehittymisellä sekä muilla liiketoimintaympäristön tekijöillä on suuri vaikutus projektiin ja sen tavoitteisiin ja näihin tekijöihin on myös kehitysprosessin mukauduttava. Sinänsä työkäytäntöjen joustavuus muutoksen omaksumisessa on tärkeämpää kuin se, että noudatetaan jäykästi suunnitelmaa. Periaatteet Ketterän ohjelmistokehityksen julistuksen takana on 12 periaatetta. Tärkein tavoitteemme on tyydyttää asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti. Muuttuvat vaatimukset ovat tervetulleita myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi. Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein ja suosimme tiheämpää aikaväliä. Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan. Rakennamme projektit motivoituneiden yksilöiden ympärille. Annamme heille puitteet ja tuen, jotka he tarvitsevat ja luotamme siihen, että he saavat työn tehtyä. Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu. Toimiva ohjelmisto on edistymisen ensisijainen mittari. Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omistajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen. Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesauttaa ketteryyttä. Yksinkertaisuus - tekemättä jätettävän työn maksimointi - on oleellista. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä. Tiimi tarkastelee säännöllisesti, kuinka parantaa tehokkuuttaan ja mukauttaa toimintaansa sen mukaisesti. Käännösversio 2015 Sivu 9 / FiSTB10 Eri ketterät menetelmät tarjoavat ohjaavia toimintatapoja julistuksen periaatteiden käytännön toteuttamiseen Tiimiperusteinen lähestymistapa Tiimiperusteinen lähestymistapa tarkoittaa sitä, että kaikki joilla on projektin menestyksen kannalta välttämätöntä tietoa ja osaamista, osallistuvat. Tiimiin kuuluu asiakkaan sekä muita liiketoiminnan sidosryhmien edustajia, jotka määrittävät tuotteen ominaisuudet. Tiimin olisi hyvä olla suhteellisen pieni; menestyviä tiimejä on tunnistettu aina kolmen henkilön tiimeistä yhdeksän henkilön tiimeihin. Ihanteellisesti koko tiimi jakaa saman työtilan, sillä yhteinen fyysinen sijainti edesauttaa voimakkaasti kommunikointia ja vuorovaikutusta. Tiimiperusteista lähestymistapaa tuetaan päivittäisillä seisoen pidettävillä palavereilla (katso luku 2.2.1), johon osallistuvat kaikki tiimin jäsenet ja joissa kommunikoidaan työn edistyminen ja esteet nostetaan esille. Tiimiperusteinen lähestymistapa edistää tehokkaampaa ja suorituskykyisempää tiimidynamiikkaa. Tiimiperusteisen lähestymistavan käyttäminen tuotekehityksessä on yksi ketterän kehityksen keskeistä hyödyistä. Sen hyödyt ovat seuraavat: Parantaa kommunikointia ja yhteistyötä tiimissä Mahdollistaa erilaisten taitojen valjastamisen projektin hyödyksi Laatu on jokaisen vastuulla Ketterissä projekteissa laadusta vastaa koko tiimi. Tiimiperusteisen lähestymistavan ydin perustuu siihen, että testaajat, kehittäjät ja liiketoiminnan edustajat työskentelevät yhdessä jokaisessa kehitysprosessin vaiheessa. Testaajat työskentelevät läheisesti sekä kehittäjien että liiketoiminnan edustajien kanssa taatakseen sen, että haluttu laatutaso saavutetaan. Tähän sisältyy liiketoiminnan edustajien tukeminen sekä yhteistyö heidän kanssaan, jotta he pystyvät laatimaan sopivat hyväksymistestit. Siihen kuuluu myös työskentely kehittäjien kanssa, jotta saavutetaan yhteinen käsitys testausstrategiasta, sekä päättäminen testausautomaation lähestymistavoista. Näin ollen testaajat voivat siirtää ja levittää testausosaamista muille tiimin jäsenille sekä vaikuttaa tuotteen kehittämiseen. Koko tiimi osallistuu jokaiseen konsultointiin tai tapaamisiin, jossa tuotteen ominaisuuksia esitetään, analysoidaan tai arvioidaan. Ajatusta jossa kaikkiin tuotteen kehitystä koskeviin keskusteluihin osallistuvat testaajat, kehittäjät ja liiketoiminnan edustajat, kutsutaan kolmen voimaksi [Crispin08] Aikainen ja säännöllinen palaute Ketterillä projekteilla on lyhyet iteraatiot, mikä mahdollistaa sen, että projektitiimi saa tuotteen laadusta jatkuvaa palautetta aikaisin läpi koko kehityksen elinkaaren. Yksi tapa antaa nopeaa palautetta on jatkuva integraatio (katso luku 1.2.4). Kun käytetään peräkkäistä kehitysprosessia, asiakas ei useinkaan näe tuotetta kuin vasta lähellä projektin loppua. Siinä vaiheessa kehitystiimin on usein liian myöhäistä ottaa enää käsiteltäväksi mahdollisia asiakkaan ongelmia. Saamalla säännöllistä asiakaspalautetta projektin edistyessä ketterät tiimit voivat sisällyttää useimmat uudet muutokset tuotekehitysprosessiin. Aikainen ja säännöllinen palaute auttaa tiimiä keskittymään ja toimittamaan asiakkaalle ensiksi ne ominaisuudet, joilla on korkein arvo liiketoiminnalle tai ominaisuuteen liittyvä riski. Se auttaa myös johtamaan tiimiä paremmin, koska tiimin kyvykkyys on läpinäkyvää kaikille. Esimerkiksi kuinka paljon työtä voidaan tehdä sprintissä tai iteraatiossa? Mikä voisi auttaa edistymään nopeammin? Mikä estää meitä tekemästä niin? Aikaisen ja säännöllisen palautteen hyödyt ovat: Vältytään vaatimuksiin liittyviltä väärinymmärryksiltä, joista aiheutuvia ongelmia ei välttämättä löydetä ennen kuin vasta myöhemmin kehitysprosessissa, jolloin ne ovat kalliimpia korjata. Käännösversio 2015 Sivu 10 / FiSTB11 Selkeytetään asiakkaan ominaisuuksiin liittyviä pyyntöjä ja saadaan ominaisuudet aikaisin asiakkaan käytettäväksi. Tällä tavalla tuote heijastaa paremmin asiakkaan tarpeita. Löydetään (jatkuvan integraation kautta), eristetään ja ratkaistaan laatuongelmat aikaisin. Tarjotaan tietoa ketterälle tiimille sen tuottavuudesta ja toimituskyvystä. Edistetään tasaista projektin etenemisvauhtia. 1.2 Näkökulmia ketteriin lähestymistapoihin Organisaatiot käyttävät useita erilaisia ketteriä lähestymistapoja. Yleisiä käytäntöjä useimmissa ketterissä organisaatioissa ovat yhteistyössä tapahtuva käyttäjätarinoiden luonti, retrospektiivit, jatkuva integraatio sekä jokaisen iteraation kuin myös koko julkaisun suunnittelu. Tässä aliluvussa käydään läpi muutamia ketteriä lähestymistapoja Ketterän ohjelmistokehityksen lähestymistapoja Ketteriä lähestymistapoja on useita ja niistä jokainen toteuttaa Ketterän ohjelmistokehityksen julistuksen arvoja ja periaatteita eri tavalla. Tässä sertifikaattisisällössä tarkastellaan kolmea eri lähestymistapaa: Extreme Programming (XP), Scrum ja Kanban. Extreme Programming (XP) XP:n toi alun perin julkisuuteen Kent Beck [Beck04] ja se on ketterä ohjelmistokehityksen lähestymistapa, jota kuvaavat tietyt arvot, periaatteet sekä ohjelmistokehityksen käytännöt. XP sisältää viisi kehitystä ohjaavaa arvoa: kommunikointi, yksinkertaisuus, palaute, rohkeus ja kunnioitus. XP sisältää myös joukon periaatteita täydentäviä arvoja: ihmisyys, talous, yhteinen hyöty, itsesimilaarisuus, parantaminen, moninaisuus, reflektio, virtaus, mahdollisuus, redundanssi, epäonnistuminen, laatu, pienet askeleet ja vastuullisuus. XP kuvaa 13 pääkäytäntöä: yhdessä istuminen, koko tiimi, informatiivinen työtila, innostettu työskentely, pariohjelmointi, tarinat, viikoittainen sykli, neljännesvuosittainen sykli, verkkaisuus, kymmenen minuutin koonti, jatkuva integraatio, testilähtöinen ohjelmointi ja vaiheittainen suunnittelu. Useat nykyään käytössä olevista ketterän kehityksen lähestymistavoista ovat ottaneet vaikutteita XP:n arvoista ja periaatteista. Esimerkiksi ketterät tiimit scrumissa usein sisällyttävät XP:n käytäntöjä toiminnassaan. Scrum Scrum on ketterän johtamisen kehys ja se sisältää seuraavat keskeiset välineet ja käytännöt [Schwaber01]: Sprintti: scrum jakaa projektin iteraatioihin (kutsutaan sprinteiksi), jotka ovat kiinteän mittaisia (yleensä kahdesta neljään viikkoon) Tuoteversio: jokaisen sprintin tuotoksena syntyy potentiaalinen julkaistava/toimitettava tuote (kutsutaan tuoteversioksi). Tuotteen kehitysjono: Tuoteomistaja hallinnoi priorisoitua kehitettävien asioiden listaa (kutsutaan tuotteen kehitysjonoksi). Tuotteen kehitysjono kehittyy jokaisessa sprintissä (kutsutaan tuotteen kehitysjonon työstämiseksi). Sprintin kehitysjono: Jokaisen sprintin alussa scrumtiimi valitsee joukon korkeimman prioriteetin kehitettäviä asioita tuotteen kehitysjonosta sprinttiin (kutsutaan sprintin kehitysjonoksi). Koska Käännösversio 2015 Sivu 11 / FiSTB12 tuoteomistajan sijaan scrumtiimi valitsee sprintissä toteutettavat asiat, valintaa kutsutaan ennemminkin vetäväksi kuin työntäväksi periaatteeksi. Valmiin määritelmä: Varmistaakseen sen, että jokaisen sprintin jälkeen on potentiaalinen julkaistava versio, tiimi keskustelee ja määrittää sopivat kriteerit sprintin päättämiselle. Tämä keskustelu syventää tiimin ymmärrystä kehitettävistä asioista ja tuotevaatimuksista. Aikarajoittaminen: Vain ne tehtävät, vaatimukset tai ominaisuudet, jotka tiimi olettaa saavansa valmiiksi sprintin aikana, ovat mukana sprintin kehitysjonossa. Jos kehitystiimi ei pysty saamaan valmiiksi tehtävää sprintin aikana, tehtävään liittyvät ominaisuudet vedetään pois sprintistä ja kyseinen tehtävä siirretään takaisin tuotteen kehitysjonoon. Aikarajoittaminen ei koske ainoastaan tehtäviä, vaan myös muita tilanteita (esimerkiksi kokoukset pakotetaan alkamaan ja loppumaan ajallaan). Läpinäkyvyys: Kehitystiimi raportoi ja päivittää sprintin tilanteen päivittäisessä kokouksessa (kutsutaan päiväpalaveriksi). Se tekee meneillään olevan sprintin sisällön ja edistymisen mukaan lukien testitulokset, näkyväksi tiimille, johdolle ja kaikille kiinnostuneille osapuolille. Esimerkiksi kehitystiimi voi näyttää sprintin tilanteen kirjoitustaululta. Scrum määrittelee kolme roolia: Scrummaster: Varmistaa sen, että scrumin käytännöt sekä säännöt otetaan käyttöön ja niitä noudatetaan. Hän selvittää kaikki rikkomukset, resurssiasiat tai muut esteet, jotka voivat estää tiimiä noudattamasta käytäntöjä ja ohjeita. Tämän roolin edustaja ei ole tiiminvetäjä vaan valmentaja. Tuoteomistaja: Edustaa asiakasta ja luo, ylläpitää ja priorisoi tuotteen kehitysjonon. Tämän roolin edustaja ei ole tiiminvetäjä. Kehitystiimi: Kehittää ja testaa tuotetta. Tiimi on itseorganisoitunut: ei ole tiiminvetäjää, joten tiimi tekee päätökset. Tiimi on myös osaamiseltaan monitahoinen (katso luvut ja 3.1.4). Scrum (toisin kuin XP) ei sanele mitään määrättyjä ohjelmistokehityksen tekniikoita (esimerkiksi testilähtöinen ohjelmistokehitys). Lisäksi scrum ei tarjoa opastusta siihen, miten testaus pitäisi tehdä scrum-projektissa. Kanban Kanban [Jaerson13] on johtamisen lähestymistapa, jota toisinaan käytetään ketterissä projekteissa. Sen yleinen tavoite on visualisoida ja optimoida kehitysjono arvoketjussa. Kanban hyödyntää kolmea välinettä [Linz14]: Kanban-taulu: Hallinnoitava arvoketju kuvataan Kanban-taululla. Jokainen sarake näyttää sijoituspaikan, jossa on siihen liittyvät tehtävät, kuten esimerkiksi kehitys ja testaus. Tuotettavien asioiden tai käsiteltävien tehtävien kuvaamiseen käytetään lappuja, joita siirretään vasemmalta oikealle sijoituspaikasta toiseen. Work-in-Progress Limit (WIP): Rinnakkaisten aktiivisten tehtävien määrä on tiukasti rajoitettu. Sitä kontrolloidaan asettamalla maksimiarvot sijoituspaikassa ja/tai taululla oleville lapuille. Jos sarakkeessa on vapaata kapasiteettia, työntekijä vetää lapun edellisestä sarakkeesta. Läpimenoaika: Kanbania käytetään optimoimaan jatkuva tehtävävirta minimoimalla (keskimääräinen) läpimenoaika arvovirrassa. Kanban sisältää yhtäläisyyksiä scrumiin. Molemmissa aktiiviset tehtävät on visualisoitu, mikä tekee niiden sisällön ja tilanteen läpinäkyväksi. Ne tehtävät, joita ei ole vielä aikataulutettu, odottavat kehitysjonossa, josta ne siirretään Kanban-taululle heti, kun siellä on uutta tilaa (tuotantokapasiteettia). Iteraatiot tai sprintit ovat Kanbanissa valinnaisia. Kanban-prosessi mahdollistaa tuotosten julkaisun yksi kerrallaan ennemmin kuin osana julkaisua. Siksi aikarajoittaminen synkronointimenetelmänä on valinnaista toisin kuin scrumissa, jossa kaikki sprinttiin sisältyvät tehtävät synkronoidaan. Käännösversio 2015 Sivu 12 / FiSTB13 1.2.2 Yhteistyössä tapahtuva käyttäjätarinoiden luonti Heikko määrittely on usein suuri syy projektin epäonnistumiselle. Määrittelyongelmat voivat olla seurausta käyttäjien näkemyksen puutteesta heidän todellisiin tarpeisiinsa, kokonaisnäkemyksen puuttumisesta järjestelmään, tarpeettomista tai ristiriitaisista ominaisuuksista ja muusta erheellisestä viestinnästä. Ketterässä kehityksessä käyttäjätarinat kirjoitetaan tallentamaan vaatimukset kehittäjien, testaajien ja liiketoiminnan edustajien näkökulmasta. Peräkkäismallisessa kehityksessä tämä jaettu visio ominaisuuksista saavutetaan muodollisten katselmointien avulla sen jälkeen, kun vaatimukset on kirjoitettu; ketterässä kehityksessä jaettu visio saadaan aikaan tekemällä säännöllisesti vapaamuotoisia katselmointeja, kun vaatimuksia kirjoitetaan. Käyttäjätarinoiden täytyy käsitellä sekä toiminnallisia että ei-toiminnallisia ominaisuuksia. Jokainen tarina sisältää hyväksymiskriteerit näille ominaisuuksille. Nämä kriteerit pitäisi määritellä yhteistyössä liiketoiminnan edustajien, kehittäjien ja testaajien kanssa. Ne tarjoavat kehittäjille ja testaajille ominaisuudesta laajemman vision, jonka liiketoiminnan edustajat kelpuuttavat. Ketterä tiimi pitää tehtävää suoritettuna sitten kun hyväksymiskriteerit on täytetty. Tyypillisesti testaajan ainutlaatuinen näkökulma parantaa käyttäjätarinaa, koska hän havainnoi puuttuvia yksityiskohtia tai ei-toiminnallisia vaatimuksia. Testaaja voi osaltaan edistää työtä kysymällä liiketoiminnan edustajilta avoimia kysymyksiä käyttäjätarinaan liittyen, ehdottamalla tapoja käyttäjätarinan testaamiseksi ja varmistamalla sen hyväksymiskriteerit. Yhteistyössä tapahtuvan käyttäjätarinan luonnissa voidaan käyttää sellaisia tekniikoita kuin aivoriihi ja miellekartta. Testaaja voi käyttää INVEST-tekniikkaa [INVEST]: Itsenäinen (Independent) Neuvoteltavissa oleva (Negotiable) Arvokas (Valuable) Arvioitavissa oleva (Estimable) Pieni (Small) Testattavissa oleva (Testable) 3C konseptin mukaan [Jeffries00] käyttäjätarina on yhdistelmä kolmesta elementistä: Kortti: Kortti on fyysinen media, joka kuvaa käyttäjätarinan. Se identifioi vaatimuksen, sen kriittisyyden, odotetun kehitys- ja testausajan sekä hyväksymiskriteerit tarinalle. Kuvauksen pitää olla täsmällinen, koska sitä tullaan käyttämään tuotteen kehitysjonossa. Keskustelu: Keskustelu selittää kuinka ohjelmistoa tullaan käyttämään. Keskustelu voi olla dokumentoitua tai suullisesti tapahtuvaa. Testaajien erilainen näkökulma kehittäjiin ja liiketoiminnan edustajiin verrattuna [ISTQB_FL_SYL] tuo arvokasta palautetta ajatusten vaihdolle, mielipiteille sekä kokemuksille. Keskustelu alkaa julkaisun suunnitteluvaiheessa ja jatkuu, kun tarina on aikataulutettu. Vahvistaminen: Hyväksymiskriteerit, joista on puhuttu keskusteluissa, käytetään vahvistamaan tarina tehdyksi. Nämä hyväksymiskriteerit voivat kattaa useita käyttäjätarinoita. Sekä positiivista että negatiivista testausta pitäisi käyttää kriteerien kattamiseksi. Vahvistamisen aikana eri osallistujat esittävät testaajan roolia. Heihin voi kuulua niin kehittäjiä kuin suorituskykyyn, tietoturvaan, yhteen toimivuuteen ja muihin laatuominaisuuksiin keskittyviä asiantuntijoita. Jotta tarina voidaan vahvistaa tehdyksi, määritetyt hyväksymiskriteerit pitäisi testata ja osoittaa kriteerien täyttyminen. Ketterät tiimit eroavat sen mukaan, kuinka he dokumentoivat käyttäjätarinoita. Huolimatta siitä, mitä lähestymistapaa käyttäjätarinoiden dokumentoimisessa käytetään, dokumentoinnin pitäisi olla ytimekästä, riittävää ja tarpeellista. Käännösversio 2015 Sivu 13 / FiSTB14 1.2.3 Retrospektiivit Ketterässä kehityksessä retrospektiivi tarkoittaa joka iteraation lopussa pidettävää kokousta, jossa keskustellaan siitä, missä onnistuttiin, mitä voisi parantaa sekä kuinka parannukset voidaan toteuttaa ja tähänastiset onnistumiset toistaa tulevissa iteraatioissa. Retrospektiivit kattavat sellaisia aiheita kuin prosessi, ihmiset, organisoitumiset, syysuhteet ja työkalut. Säännöllisesti pidetyt retrospektiivit, joihin liittyen toteutetaan sopivat seurantatoimet, ovat kriittisiä itseorganisoitumiselle sekä kehityksen ja testauksen jatkuvalle parantamiselle. Retrospektiivien seurauksena voi olla testaukseen liittyviä parannuspäätöksiä liittyen testauksen tehokkuuteen, testauksen tuottavuuteen, testitapausten laatuun ja tiimityytyväisyyteen. Ne voivat käsitellä myös sovelluksen, käyttäjätarinoiden, ominaisuuksien tai järjestelmän rajapintojen testattavuutta. Vikojen juurisyyanalyysi voi ohjata testauksen ja kehityksen parannuksiin. Tiimien pitäisi ylipäänsä toteuttaa vain muutamia parannuksia yhteen iteraatioon. Tämä mahdollistaa jatkuvan parantamisen pysyvällä tahdilla. Retrospektiivien ajoitus ja organisointi riippuvat siitä, mitä ketterää menetelmää seurataan. Liiketoiminnan edustajat ja tiimi ovat jokaisessa retrospektiivissä osallistujan roolissa ja fasilitaattori organisoi ja pitää kokouksen. Joissakin tapauksissa tiimi voi kutsua muita osallistujia kokoukseen. Testaajien pitäisi olla tärkeässä roolissa retrospektiiveissä. Testaajat ovat osa tiimiä ja he tuovat mukaan ainutlaatuista näkökulmaa [ISTQB_FL_SYL], luku 1.5. Testausta tehdään jokaisessa sprintissä ja se vaikuttaa ratkaisevasti onnistumiseen. Kaikki tiimin jäsenet mukaan lukien testaajat ja ne, jotka eivät testaa, voivat tarjota työpanostaan sekä testauksen että testaukseen kuulumattomiin tehtäviin. Retrospektiivit täytyy pitää ammattimaisessa ympäristössä, jossa vallitsee keskinäinen luottamus. Retrospektiivin menestystekijät ovat samoja, kuin minkä tahansa katselmoinnin menestystekijät, joita käytiin läpi luvussa 3.2 Perustason sertifikaattisisällössä [ISTQB_FL_SYL] Jatkuva integraatio Tuotteen inkrementin toimitus vaatii luotettavaa, toimivaa ja integroitua ohjelmistoa jokaisen sprintin lopussa. Jatkuva integraatio käsittelee tätä haastetta kokoamalla yhteen kaikki ohjelmistoon tehdyt muutokset ja integroimalla kaikki muutetut komponentit säännöllisesti, ainakin kerran päivässä. Kokoonpanonhallinta, käännös, ohjelmiston koonti, kehittäminen ja testaus on paketoitu yhdeksi automatisoiduksi toistettavaksi prosessiksi. Koska kehittäjät integroivat työnsä jatkuvasti, koostavat ja testaavat jatkuvasti, viat koodissa voidaan havaita nopeammin. Kehittäjien tekemää koodausta, virheenjäljitystä ja koodin yhteiseen lähdekoodikirjastoon tallentamista seuraava jatkuvan integroinnin prosessi koostuu seuraavista automatisoiduista tehtävistä: Staattinen analyysi koodille: staattisen koodianalyysin suorittaminen ja tulosten raportointi Kääntäminen: koodin kääntäminen ja linkittäminen sekä ajettavien tiedostojen luominen Yksikkötestaus: yksikkötestien suorittaminen, koodikattavuuden tarkistaminen ja testitulosten raportointi Levittäminen: koonnin asentaminen testausympäristöön Integraatiotestaus: integraatiotestauksen suorittaminen ja tulosten raportointi Raportointi (näkymä): kaikkien edellä mainittujen toimintojen statuksen kirjaaminen julkiseen näkyvään paikkaan tai sähköpostitse lähettäminen Automaattinen koonti ja testausprosessi tapahtuu päivittäin ja se havaitsee integraatiovirheet aikaisin ja nopeasti. Jatkuva integraatio antaa ketterille testaajille mahdollisuuden suorittaa automatisoidut testit säännöllisesti ja joissakin tapauksessa osana jatkuvan integroinnin prosessia, sekä lähettää nopeasti palautetta tiimille koodin laadusta. Nämä testitulokset ovat näkyvissä koko tiimille erityisesti silloin, kun automatisoidut raportit on integroitu prosessiin. Automaattinen regressiotestaus voi olla jatkuvaa läpi Käännösversio 2015 Sivu 14 / FiSTB15 iteraation. Hyvä automaattinen regressiotestaus kattaa niin paljon toiminnallisuudesta kuin on mahdollista, mukaan lukien aiemmissa iteraatioissa toimitetut käyttäjätarinat. Automaattisten regressiotestien hyvä kattavuus auttaa tukemaan laajojen integroitujen järjestelmien rakentamista (ja testausta). Kun regressiotestit on automatisoitu, testaajat vapautuvat keskittämään manuaalisen testauksensa uusiin ominaisuuksiin, tehtyihin muutoksiin sekä vikakorjausten varmistustestaukseen. Automatisoitujen testien lisäksi jatkuvaa integraatiota noudattavat organisaatiot käyttävät tyypillisesti koontityökaluja jatkuvan laadun valvontaan. Yksikkö- ja integraatiotestien lisäksi nämä työkalut voivat suorittaa täydentäviä staattisia ja dynaamisia testejä, mitata ja profiloida suorituskykyä, luoda ja muotoilla dokumentaatiota lähdekoodista ja helpottaa manuaalisia laadunvalvontaprosesseja. Tämä jatkuva laadun valvonnan toteuttaminen tähtää tuotteen laadun parantamiseen ja sen toimittamiseen käytetyn ajan vähentämiseen korvaamalla perinteinen tapa toteuttaa laadunvalvontatehtävät vasta koko kehitystyön valmistumisen jälkeen. Koontityökalut voidaan linkittää automaattisiin kehitystyökaluihin, jotka voivat poimia sopivan koonnin jatkuvasta integraatiosta tai koontipalvelimelta ja jakaa sitä yhteen tai useampaan kehitys-, testaus-, esitys- ja jopa tuotantoympäristöihin. Tämä vähentää virheitä ja viivästyksiä, jotka liittyvät siihen, että julkaisujen asentamisessa näihin ympäristöihin joudutaan turvautumaan tehtävään erikoistuneisiin henkilöihin tai kehittäjiin. Jatkuva integraatio voi tarjota seuraavia etuja: Mahdollistaa aikaisemman integraatio-ongelmien sekä ristiriitaisten muutosten havaitsemisen sekä helpomman juurisyyanalyysin Antaa kehitystiimille säännöllistä palautetta siitä, toimiiko koodi Pitää päivän aikana testatun ohjelmiston version samana kehitetyssä versiossa Vähentää kehittäjän koodin refaktoroinnista aiheutuvaa regressioriskiä johtuen koodin nopeasta uudelleentestauksesta jokaisen pienen muutoksen yhteydessä Tarjoaa luottamuksen siihen, että jokapäiväinen kehitystyö perustuu kiinteään perustaan Tuo näkyvyyttä tuoteinkrementin valmistumisen lähestymiseen, mikä kannustaa kehittäjiä ja testaajia Poistaa isoihin integraatioihin liittyvän aikatauluriskin Tarjoaa suoritettavan ohjelmiston jatkuvan saatavuuden läpi sprintin testaus-, esitys- tai koulutustarkoituksiin Vähentää toistuvia manuaalisia testauksen tehtäviä Tarjoaa nopeaa palautetta tehdyistä laadun- ja testauksenparannuspäätöksistä Jatkuvaan integraatioon liittyy kuitenkin myös riskejä ja haasteita: Jatkuvan integraation työkalut pitää ottaa käyttöön ja niitä pitää ylläpitää Jatkuvan integraation prosessi pitää olla määritetty ja vakiintunut Testausautomatisointi vaatii resursseja ja sen perustaminen voi olla monimutkaista Perusteellinen testikattavuus on olennaista, jotta saavutetaan automatisoidun testauksen hyödyt Toisinaan tiimit luottavat liikaa yksikkötesteihin ja suorittavat liian vähän järjestelmä- ja hyväksymistestejä Jatkuva integraatio vaatii työkalujen käyttämistä, mukaan lukien testaustyökalut, automatisoidun koontiprosessin työkalut ja versionhallintatyökalut Julkaisun ja iteraation suunnitteleminen Kuten Perustason sertifikaattisisällössä mainitaan [ISTQB_FL_SYL], suunnittelu on jatkuva tehtävä ja sama pätee myös ketteriin elinkaariin. Niissä tehdään kahdentyyppistä suunnittelua, sekä julkaisun että iteraation. Käännösversio 2015 Sivu 15 / FiSTB16 Julkaisun suunnittelu katsoo eteenpäin tuotteen julkaisuun, usein jo muutamia kuukausia ennen projektin alkamista. Julkaisun suunnittelu määrittelee ja uudelleen määrittelee tuotteen kehitysjonon ja siihen voi kuulua laajojen käyttäjätarinoiden jalostamista pienempien käyttäjätarinoiden kokoelmaksi. Julkaisun suunnittelu antaa perustan testauksen lähestymistavalle ja testauksen suunnittelulle läpi kaikkien iteraatioiden. Julkaisusuunnitelmat tehdään korkealla tasolla. Julkaisua suunniteltaessa liiketoiminnan edustajat hyväksyvät ja priorisoivat julkaisuun liittyvät käyttäjätarinat yhdessä tiimin kanssa (ks. kappale 1.2.2). Näihin käyttäjätarinoihin perustuen identifioidaan projekti- ja laaturiskit ja suoritetaan korkean tason arviointia (katso luku 3.2). Testaajat osallistuvat julkaisun suunnitteluun ja tuovat lisäarvoa erityisesti seuraaviin tehtäviin: Testattavien käyttäjätarinoiden määrittäminen, mukaan lukien hyväksymiskriteerit Projekti- ja laaturiskien analysointiin osallistuminen Käyttäjätarinoihin tarvittavan testauspanoksen arvioiminen Tarvittavien testitasojen määrittäminen Julkaisun testauksen suunnitteleminen Sen jälkeen kun julkaisun suunnittelu on tehty, alkaa ensimmäisen iteraation suunnittelu. Iteraation suunnittelu katsoo eteenpäin yksittäisen iteraation loppuun asti ja se käsittelee iteraation kehitysjonoa. Iteraation suunnittelussa tiimi valitsee käyttäjätarinat priorisoidusta julkaisun kehitysjonosta, tarkentaa niiden sisältöjä, suorittaa niille riskianalyysin ja arvioi jokaiselle tarinalle tarvittavan työmäärän. Jos käyttäjätarina on liian epäselvä eikä sitä onnistuta selkiyttämään, tiimi voi kieltäytyä hyväksymästä sitä ja käyttää prioriteettijärjestyksessä seuraavana olevaa käyttäjätarinaa. Liiketoiminnan edustajien täytyy vastata tiimin kysymyksiin jokaisesta käyttäjätarinasta niin, että tiimi voi ymmärtää mitä heidän pitäisi toteuttaa ja kuinka heidän pitäisi testata tarina. Valittujen tarinoiden määrä perustuu tiimin vauhtiin ja valittujen käyttäjätarinoiden arvioituun kokoon. Sen jälkeen kun iteraation sisältö on lyöty lukkoon, käyttäjätarinat pilkotaan sopivien tiimin jäsenten toteutettaviksi tehtäviksi. Testaajat osallistuvat iteraation suunnitteluun ja tuovat lisäarvoa erityisesti seuraavissa tehtävissä: Osallistumalla käyttäjätarinoiden yksityiskohtaiseen riskianalysointiin Määrittämällä käyttäjätarinoiden testattavuutta Luomalla hyväksymistestejä käyttäjätarinoille Pilkkomalla käyttäjätarinoita tehtäviksi (erityisesti testaustehtäviksi) Arvioimalla testauksen työmäärää kaikille testaustehtäville Identifioimalla testattavan järjestelmän toiminnallisia ja ei-toiminnallisia puolia Tukemalla ja osallistumalla testausautomaatioon useilla eri testaustasoilla Julkaisusuunnitelmat voivat muuttua projektin edetessä, mukaan lukien tuotteen julkaisujonossa olevat yksittäiset käyttäjätarinat. Nämä muutokset voivat aiheutua sisäisistä tai ulkoisista tekijöistä. Sisäisiin tekijöihin kuuluvat toimituskyvykkyys, nopeus ja tekniset asiat. Ulkoisiin tekijöihin kuuluvat uusien markkinoiden ja mahdollisuuksien löytyminen, uudet kilpailijat tai liiketoiminnan uhkat, jotka voivat vaikuttaa julkaisun tavoitteisiin ja/tai tavoitepäiviin. Lisäksi iteraatiosuunnitelmat voivat muuttua iteraation aikana. Esimerkiksi tietty käyttäjätarina, jota oli pidetty suhteellisen yksikertaisena arvioinnissa, voi olla paljon odotettua monimutkaisempi. Nämä muutokset voivat olla testaajille haasteellisia. Testaajien täytyy ymmärtää julkaisun koko kuva testauksen suunnittelua varten ja heillä täytyy olla joka iteraatiossa käytettävissään riittävä pohjamateriaali ja testioraakkeli testien kehitystarkoituksiin, kuten on kuvattu Perustason sertifikaattisisällössä kappaleessa 1.4. Tarvittavan tiedon täytyy olla aikaisin testaajien saatavilla, mutta Käännösversio 2015 Sivu 16 / FiSTB17 muutokset täytyy kuitenkin hyväksyä ketterien periaatteiden mukaisesti. Tämä pulma vaatii huolellisia päätöksiä liittyen testausstrategiaan ja testausdokumentaatioon. Lisää ketterästä testauksesta voi katsoa [Black09] luvusta 12. Julkaisun ja iteraatioiden suunnittelun pitäisi sisältää testauksen suunnittelua sekä kehitykseen liittyvien tehtävien suunnittelua. Erityisesti testaukseen liittyviin käsiteltäviin asioihin kuuluvat: Testauksen laajuus, testauksen määrä valituilla alueilla, testauksen tavoitteet ja syyt edellä mainittuihin päätöksiin. Tiimin jäsenet, jotka toteuttavat testauksen tehtäviä. Tarvittava testiympäristö ja aineisto, milloin niitä tarvitaan ja onko niihin tulossa lisäyksiä tai muutoksia ennen projektia tai sen aikana. Toiminnallisten ja ei-toiminnallisten testaustehtävien ajoitus, järjestys, riippuvuudet ja esiehdot (esim. kuinka tiheään suoritetaan regressiotestausta, mitkä ominaisuudet riippuvat toisista ominaisuuksista tai testiaineistosta, jne.), mukaan lukien kuinka testauksen tehtävät liittyvät ja riippuvat kehityksen tehtävistä. Käsiteltävät projekti- ja tuoteriskit (ks. kappale 3.2.1). Lisäksi laajemman tiimin työmääräarvion pitäisi ottaa huomioon myös vaadittujen testaustehtävien loppuun viemiseen tarvittava aika ja työpanos. Käännösversio 2015 Sivu 17 / FiSTB18 2. Keskeiset ketterän testauksen periaatteet, käytännöt ja prosessit 105 minuuttia Avainsanat koonnin todentamistesti, kokoonpanon osa, kokoonpanonhallinta Oppimistavoitteet keskeisille ketterän testauksen periaatteille, käytännöille ja prosesseille 2.1 Eroavaisuuksia perinteisten ja ketterien lähestymistapojen testauksessa FA (K2) Osaat kuvata testauksen tehtävien eroavaisuudet ketterien ja ei-ketterien projektien välillä FA (K2) Osaat kuvata kuinka kehityksen ja testauksen tehtävät muodostavat kokonaisuuden ketterissä projekteissa FA (K2) Osaat kuvata riippumattoman testauksen roolin ketterissä projekteissa 2.2 Testauksen asema ketterissä projekteissa FA (K2) Osaat kuvata työkaluja ja tekniikoita, joita käytetään ketterien projektien testauksen tilanteen viestimisessä, mukaan lukien testauksen edistyminen ja tuotelaatu FA (K2) Osaat kuvata testien kehitysprosessin läpi monien iteraatioiden ja osaat selittää miksi testausautomaatio on tärkeää ketterien projektien regressioriskin hallinnassa 2.3 Testaajan rooli ja taidot ketterässä tiimissä FA FA (K2) Ymmärrät testaajan taidot (ihmiset, toimintapiiri ja testaus) ketterässä tiimissä (K2) Ymmärrät testaajan roolin ketterässä tiimissä Käännösversio 2015 Sivu 18 / FiSTB19 2.1 Eroavaisuuksia perinteisten ja ketterien lähestymistapojen testauksessa Kuten Perustason sertifikaattisisällössä [ISTQB_FL_SYL] sekä [Black09] kuvataan, testaustehtävät liittyvät toteutustehtäviin ja näin ollen testaus on erilaista eri elinkaarimalleissa. Testaajien täytyy ymmärtää testauksen eroavaisuudet perinteisten (esim. vaiheittainen malli, kuten v-malli tai iteratiivinen malli, kuten RUP) ja ketterien elinkaarimallien välillä työskennelläkseen tehokkaasti ja suorituskykyisesti. Ketterät projektit eroavat testauksen ja kehityksen tehtävien integroinnin, projektin tuotosten, nimeämisten, eri testaustasoilla käytettävien aloitus- ja lopetuskriteerien sekä työkalujen suhteen ja siinä, kuinka riippumatonta testausta voidaan käyttää tehokkaasti hyödyksi. Testaajien pitäisi muistaa, että organisaatiot eroavat merkittävästi siinä, kuinka ne toteuttavat malleja. Poikkeaminen ketterien elinkaarimallien ihanteesta (katso kappale 1.1) voi edustaa älykästä käytäntöjen räätälöintiä ja sopeuttamista. Kyky sopeutua määrätyn projektin tilanteeseen ja siinä noudatettuihin ohjelmistokehityksen käytäntöihin on avaintekijä testaajien menestymiseen Testauksen ja kehityksen tehtävät Yksi keskeisimmistä perinteisten ja ketterien elinkaarimallien välisistä eroavaisuuksista on ajatus hyvin lyhyistä iteraatioista, joista jokaisen tuloksena on toimiva ohjelmisto ja jossa on liiketoiminnan edustajille lisäarvoa tarjoavia ominaisuuksia. Projektin alussa on julkaisun suunnittelujakso, jota seuraavat peräkkäiset iteraatiot. Jokaisen iteraation alussa on iteraation suunnitteluvaihe. Kun iteraation puitteet on määritelty, valitut käyttäjätarinat toteutetaan, integroidaan järjestelmään ja testataan. Nämä iteraatiot ovat hyvin dynaamisia, ja toteutus-, integraatio- ja testaustehtäviä tapahtuu läpi jokaisen iteraation ja niissä on paljon rinnakkaisuutta ja päällekkäisyyttä. Testauksen tehtäviä suoritetaan koko ajan iteraation aikana eikä viimeisenä toimintona. Testaajilla, kehittäjillä sekä liiketoiminnan edustajilla on kaikilla rooli testauksessa, kuten on perinteisissäkin elinaarimalleissa. Kehittäjät suorittavat yksikkötestejä, kun he kehittävät ominaisuuksia käyttäjätarinoista. Sitten testaajat testaavat nuo ominaisuudet. Myös liiketoiminnan edustajat testaavat tarinoita toteuttamisen aikana. Liiketoiminnan edustajat saattavat käyttää kirjoitettuja testitapauksia, mutta he voivat myös yksinkertaisesti kokeilla ja käyttää ominaisuutta antaakseen nopeasti palautetta kehitystiimille. Joissain tapauksissa toteutetaan säännöllisesti korjaus- tai vakautusiteraatio, jossa pyritään ratkaisemaan pitkään auki olleita vikoja ja muita teknisen velan muotoja. Kuitenkin paras käytäntö on sellainen, että yhtään ominaisuutta ei pidetä valmiina, ennen kuin se on integroitu ja testattu järjestelmässä [Goucher09]. Toinen hyvä käytäntö on keskittyä seuraavan iteraation alussa edellisestä iteraatiosta jäljelle jääneisiin vikoihin osana kyseisen iteraation kehitysjonoa (kutsutaan korjaa viat ensin ). Jotkut kuitenkin valittavat, että tämä käytäntö johtaa tilanteeseen, jossa iteraation kokonaistyömäärää ei tiedetä ja on vaikeampi arvioida, milloin jäljellä olevat ominaisuudet voidaan toteuttaa. Peräkkäisten iteraatioiden lopuksi voi olla joukko julkaisuun liittyviä toimintoja, jotta ohjelmisto saadaan toimitusvalmiiksi, vaikka joissakin tapauksissa toimitus tapahtuu aina jokaisen iteraation lopuksi. Kun käytetään riskipohjaista testausta yhtenä testausstrategiana, korkean tason riskianalyysi tapahtuu julkaisun suunnittelun aikana ja usein testaajat ohjaavat tämän analyysin. Jokaiseen iteraatioon liittyvät sille ominaiset laaturiskit tunnistetaan ja arvioidaan kuitenkin iteraation suunnittelun yhteydessä. Tämä riskianalyysi voi vaikuttaa kehitysjärjestykseen kuin myös ominaisuuksien testaamisen tärkeyteen ja syvyyteen. Se vaikuttaa myös jokaiseen ominaisuuteen tarvittavan testaustyön arviointiin (katso kappale 3.2). Joissakin ketterissä käytännöissä (esim. XP) käytetään parityöskentelyä. Siihen voi kuulua paritestausta, jossa kaksi testaajaa yhdessä testaa ominaisuutta. Siihen voi myös kuulua myös se, että Käännösversio 2015 Sivu 19 / FiSTB20 testaaja työskentelee yhteistyössä kehittäjän kanssa ominaisuuden kehittämisessä ja testauksessa. Parityöskentely voi olla vaikeaa silloin, kun testaustiimi on hajautettu, mutta prosessit ja työkalut voivat helpottaa hajautettua parityöskentelyä (katso [ISTQB_ALTM_SYL], kappale 2.8). Testaajat voivat toimia myös tiimin testaus- ja laatuvalmentajina ja jakaa testausosaamista ja tukea laadunvarmistustyötä tiimissä. Tämä edistää tuntemusta tuotteen laadun yhteisestä omistajuudesta. Useissa ketterissä tiimeissä tapahtuu testausautomatisointia kaikilla testauksen tasoilla ja tämä voi tarkoittaa sitä, että testaajat käyttävät aikaa automatisoitujen testien luomiseen ja suorittamiseen sekä testien ja tulosten seurantaan ja ylläpitämiseen. Testiautomaation laajan käytön vuoksi suurempi osa ketterissä projekteissa tehtävästä manuaalisesta testauksesta tehdään yleensä käyttämällä kokemusperusteisia ja vikaperusteisia tekniikoita kuten ohjelmistohyökkäyksiä, tutkivaa testausta ja virheenarvausta (katso [ISTQB_ALTA_SYL], osat 3.3 ja 3.4 ja [ISTQB_FL_SYL], kappale 4.5). Kehittäjien keskittyessä luomaan yksikkötestejä, testaajien pitäisi keskittyä luomaan automatisoituja integraatio-, järjestelmä- ja järjestelmäintegraatiotestejä. Tämä johtaa ketterissä tiimeissä taipumukseen suosia testaajia, joilla on vahva tekninen ja testausautomaatiotausta. Yksi ketteristä perusperiaatteista on se, että muutoksia voi tapahtua koko projektin ajan. Siksi ketterissä projekteissa suositaan hyvin kevyttä projektin työn tulosten dokumentointia. Olemassa olevien ominaisuuksien muutoksilla on vaikutuksia testaukseen ja erityisesti regressiotestaukseen. Automaattisen testauksen käyttäminen on yksi tapa hallita muutokseen liittyvän testaustyön määrää. Kuitenkin on tärkeää, että muutoksen määrä ei ylitä projektitiimin kykyä käsitellä muutoksiin liittyviä riskejä Projektin työn tulokset Projektin työn tulokset, jotka ovat välitön mielenkiinnon kohde ketterille testaajille, jaetaan tyypillisesti kolmeen kategoriaan: 1. Liiketoimintapainotteiset työn tulokset, jotka kuvaavat sen, mitä tarvitaan (esim. vaatimusmäärittelyt) ja kuinka sitä käytetään (esim. käyttäjädokumentaatio) 2. Kehitystyön tulokset, jotka kuvaavat sen, miten järjestelmä rakennetaan (esim. tietokannan entiteettisuhdekaaviot), jotka itse asiassa toteuttavat järjestelmän (esim. koodi), tai jotka arvioivat yksittäistä koodin osaa (esim. manuaalinen ja automaattinen testaus) 3. Testaustyön tulokset, jotka kuvaavat sen, kuinka järjestelmä testataan (esim. testausstrategiat ja suunnitelmat), joilla testataan järjestelmä (esim. manuaaliset ja automaattiset testit), tai jotka esittävät testaustuloksia (esim. testauksen näkymä, josta puhutaan osassa 2.2.1) Tyypillisessä ketterässä projektissa yleinen käytäntö on välttää tuottamasta hyvin suurta määrää dokumentaatiota. Sen sijaan keskitytään enemmän toimivaan ohjelmistoon yhdessä automaattisten testien kanssa, jotka osoittavat yhdenmukaisuuden vaatimuksiin. Tämä rohkaisu dokumentoinnin vähentämiseen koskee ainoastaan sellaista dokumentointia, joka ei tuo lisäarvoa asiakkaalle. Menestyvässä ketterässä projektissa tasapaino löytyy jostain siltä väliltä, että vähennetään dokumentaatiota tehokkuuden kasvattamiseksi ja että laaditaan riittävästi dokumentaatiota liiketoimintaan, testaukseen, toteutukseen ja ylläpitoon liittyvien tehtävien tukemiseksi. Tiimin täytyy tehdä julkaisun suunnittelun aikana päätös siitä, mitä työn tuloksia tarvitaan ja millä tasolla niitä dokumentoidaan. Tyypilliset liiketoimintaorientoituneet työn tulokset ketterissä projekteissa käsittävät käyttäjätarinoita ja hyväksymiskriteerit. Käyttäjätarinat ovat ketterä muoto vaatimusmäärittelyistä, ja niiden pitäisi selittää se, kuinka järjestelmän pitäisi käyttäytyä yksittäisen, yhtenäisen ominaisuuden tai toiminnon suhteen. Käyttäjätarinan pitäisi määritellä tarpeeksi pieni ominaisuus, joka voidaan toteuttaa valmiiksi yksittäisessä iteraatiossa. Laajempaa kokoelmaa toisiinsa liittyviä ominaisuuksia tai kokoelmaa aliominaisuuksia, jotka muodostavat yksittäisen monimutkaisen ominaisuuden, voidaan kutsua eepoksiksi. Eepokset voivat sisältää käyttäjätarinoita eri kehitystiimeille. Esimerkiksi yksi käyttäjätarina Käännösversio 2015 Sivu 20 / FiSTB Näytä lisää
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 Lisätiedot Harjoituskoe Vastaukset. ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus
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 Lisätiedot 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 Lisätiedot 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 Lisätiedot Harjoituskoe ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus
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 Lisätiedot 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 Lisätiedot 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 Lisätiedot 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 Lisätiedot Sertifioitu Testaaja. Jatkotason sertifikaattisisältö Testausasiantuntija
Sertifioitu Testaaja Jatkotason sertifikaattisisältö Testausasiantuntija Versio 2012 Tekijänoikeushuomautus Tämän dokumentin saa kopioida kokonaisuudessaan tai siitä saa tehdä otteita, mikäli lähde mainitaan. Lisätiedot 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 Lisätiedot 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 Lisätiedot Ohjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu Lisätiedot 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 Lisätiedot 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 Lisätiedot Scrumjatkuvan palvelun DWprojektissa-case. Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy
Scrumjatkuvan palvelun DWprojektissa-case OP-Pohjola Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy Agenda Scrum lyhyesti Jatkuvan palvelun DW-projekti- Case OP-Pohjola Lähtötilanne ennen Scrumia Scrumin Lisätiedot 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) Lisätiedot Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma
Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia Lisätiedot Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
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 Lisätiedot 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 Lisätiedot 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 Lisätiedot Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli Lisätiedot Sertifioitu Testaaja. Jatkotason sertifikaattisisältö Testauspäällikkö
Sertifioitu Testaaja Jatkotason sertifikaattisisältö Testauspäällikkö Versio 2012 Tekijänoikeushuomautus Tämän dokumentin saa kopioida kokonaisuudessaan tai siitä saa tehdä otteita, mikäli lähde mainitaan. Lisätiedot 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/ Lisätiedot Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia
Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia Nina Perta, Senior quality consultant Knowit Oy Elina Varteva, QA Specialist Knowit Oy Copyright Knowit Oy 2014 Nina Perta Lisätiedot Hajautettu Ohjelmistokehitys
Hajautettu Ohjelmistokehitys Maria Paasivaara Hajautuksen muotoja Yrityksen sisäinen hajautus Maan sisällä Maiden välillä, esim. offshore Yritysten välinen hajautus Alihankinta Lisenssointi Partnershipit Lisätiedot 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. Lisätiedot Luku 10 Käyttöönoton suunnitteluja toteutusvaihe
Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Käyttöönoton Roll-Out Planning suunnittelu- & Preparation ja valmistelu Design Tiedon- Data Conversion muunnos- prosessien Processes suunnittelu Toimipisteiden Lisätiedot 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 Lisätiedot Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa
1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä Lisätiedot IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS
20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien Lisätiedot 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 Lisätiedot Ohjelmiston testaus ja laatu. Testausmenetelmiä
Ohjelmiston testaus ja laatu Testausmenetelmiä Testausmenetelmiä - 1 Testauksen menetelmien päälähestymistapoina ovat black-box testi testaaja ei voi tutkia lähdekoodia testaus perustuu sovellukselle suunnitteluvaiheessa Lisätiedot Kokonaisuuksien, riippuvuuksien ja synergioiden hahmottaminen helpottuvat
Johtaminen voidaan jakaa karkeasti kolmeen osaan: 1. Arvojohtaminen (Leadership) 2. Työn(kulun) johtaminen (Process management) 3. Työn sisällön ja tulosten/ tuotosten johtaminen (esim. Product management) Lisätiedot 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 Lisätiedot työryhmien SharePoint-yhteistyötä helpottava ratkaisu
työryhmien SharePoint-yhteistyötä helpottava ratkaisu LIIKKEENJOHDON SUURIN HAASTE Modernin yrityksen on muutoksen kyydissä pysyäkseen suunniteltava tehokas strategia ja seurattava sitä. Siinä piilee kuitenkin Lisätiedot Miten asiakas tekee valintansa?
Miten asiakas tekee valintansa? ja miten me voimme vaikuttaa siihen? TkT Asiantuntija Harri Karkkila Strategia Asiakkaan kokema arvo Asiakastyytyväisyys ja asiakaskokemus Kilpailuedut Yrittäjä Kouluttaja Lisätiedot 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ä Lisätiedot L models. Testisuunnitelma. Ryhmä Rajoitteiset
Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Testisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset Lisätiedot Siirtyminen ketterien menetelmien maailmaan! Maarit Laanti 24 October 2013!
Siirtyminen ketterien menetelmien maailmaan! Maarit Laanti 24 October 2013! Sisältö! 1. Tilanne nyt: waterscrumming! 2. Kokonaisvaltainen ketteryys mitä sillä haetaan, mitä sillä saadaan?! 3. Ketterän Lisätiedot Sertifioitu Testaaja Certified Tester. Perustason sertifikaattisisältö Foundation Level Syllabus
Sertifioitu Testaaja Certified Tester Perustason sertifikaattisisältö Foundation Level Syllabus Versio 2010 Käännösversio 2010 Perustuu englanninkieliseen versioon 30.3.2010 Based on English version 30th Lisätiedot Soft QA. Vaatimusten muutostenhallinta. Ongelma
Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei Lisätiedot Riskit hallintaan ISO 31000
Riskit hallintaan ISO 31000 Riskienhallinta ja turvallisuus forum 17.10.2012 Riskienhallintajohtaja Juha Pietarinen Tilaisuus, Esittäjä Mitä on riskienhallinta? 2 Strategisten riskienhallinta Tavoitteet Lisätiedot Suomen avoimien tietojärjestelmien keskus COSS ry
Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet Lisätiedot 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 Lisätiedot 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 Lisätiedot Tietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto Lisätiedot Testauksen hallinta ja johtaminen
Testauksen hallinta ja johtaminen Luento 10 Antti-Pekka Tuovinen 18 April 2013 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia Lisätiedot Yhteisöllisen oppimisen työpaja 9.12.2010 Reflektori 2010 Tulokset
Yhteisöllisen oppimisen työpaja 9.12.2010 Reflektori 2010 Tulokset Fasilitointi: Kati Korhonen-Yrjänheikki, TEK; Dokumentointi työpajassa: Ida Mielityinen, TEK; Fläppien dokumentointi tulosraporttia varten: Lisätiedot 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 Lisätiedot 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 Lisätiedot Kuinka IdM-hanke pidetään raiteillaan
Kuinka IdM-hanke pidetään raiteillaan Projektipäällikön kokemuksia 4.10.2011 IdM-projektitkin pitää suunnitella Kaiken perustana on riittävä ymmärrys projektin sisällöstä, laajuudesta ja vaaditusta osaamisesta Lisätiedot 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 Lisätiedot Finnaa arkistoille. Aki Lassila Arkistot 26.11.2012
Finnaa arkistoille Aki Lassila Arkistot 26.11.2012 Finnan arkkitehtuuri Asiakasliittymä rakentuu useista moduleista, jotka on integroitu toisiinsa; uusia moduleita voidaan integroida järjestelmään tarpeen Lisätiedot 0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen
Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 24.10.2005 Elina Kontro Laatuasiat siirretty omaan dokumenttiin jatkotyöstetty 0.2 27.10.2005 Santeri Saarinen Bugien elinkaari yms. asioita jatkettu 0.3 28.10.2005 Lisätiedot PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009
PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI 28.9.2009 POHDINTAA Mitä asioita projektissa seurataan? Kuka vastaa ohjauksesta? Millä tavoin projektia seurataan ja ohjataan? Mitä asioita ohjaukseen kuuluu? Lisätiedot Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!
Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA Lisätiedot Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007
Merlin Systems Oy Kommunikaatiokartoitus päätöksenteon pohjaksi Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlinin palvelujen toimittaminen ja Asiakasratkaisuyksikön tehtäväkenttä Merlin Asiakasratkaisut Lisätiedot JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi
JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Katselmointi osana laadunvarmistusta... 2 2 Yleistä katselmoinneista... Lisätiedot 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 Lisätiedot 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ä Lisätiedot PROJEKTINHALLINTA. Käyttäjälähtöinen suunnittelu
PROJEKTINHALLINTA Käyttäjälähtöinen suunnittelu PROJEKTINHALLINTA OSANA KURSSIA Opettaja: Tomi Jokitulppo email: Tomi.Jokitulppo@metropolia.fi puhelin: 040 5430197 4 opetuskertaa: 2.10., 9.10., 16.10. Lisätiedot 2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia
OAMK / Luova 4.5. ja 11.5. Sisäinen auditointi osa Oamkin ympäristöohjelmatyötä Sisältö 1. päivä Johdanto Auditoinnin tavoitteet Ympäristöstandardin (ISO 14001) pääkohdat Alustava ympäristökatselmus Auditoinnin Lisätiedot Advanced Test Automation for Complex Software-Intensive Systems
Advanced Test Automation for Complex Software-Intensive Systems Aiheena monimutkaisten ohjelmistovaltaisten järjestelmien testauksen automatisointi Mistä on kyse? ITEA2-puiteohjelman projekti: 2011-2014 Lisätiedot 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 Lisätiedot Kuntasektorin kokonaisarkkitehtuuri
Kuntasektorin kokonaisarkkitehtuuri Yhteiskäyttöisten komponenttien kehitys ja hallinta Kurttu 18.4.2013 Ohjelmistokomponenttien uudelleenkäyttö Kustannussäästöjä» Kehityskustannukset» Lisenssikustannukset Lisätiedot Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä
Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Laajuus Jatkuva laajeneminen sekä maantieteellisesti että sisällön kannalta: Yhdestä Lisätiedot Laaturaportti [iteraatio 2] Ryhmä 14
Laaturaportti [iteraatio 2] Ryhmä 14 Versio Pvm Tekijä Kuvaus 1.0 2.3.2008 Luukkonen Ensimmäinen versio Sisältö 1. Käytetyt laatumenetelmät... 1 1.1 Automaattiset yksikkötestit, tutkiva testaus ja jatkuva Lisätiedot Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun
Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun l Yrityksen kumppanien yhteydenpidon lisääminen Janne Ohtonen, Enterprise Architect, Affecto Finland Oy Yit Yrityksen kumppaniverkosto Lisätiedot Turvakriittisen projektin menetelmät ja työkalut
Turvakriittisen projektin menetelmät ja työkalut 1. Vaatimushallinta Vaatimushallintaan kohdistuu turvaluokitelluissa projekteissa paljon odotuksia. Etenkin jäljitettävyys vaatimuksiin, testaukseen ja Lisätiedot @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ä Lisätiedot 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 Lisätiedot Projektisuunnitelma. Projektin tavoitteet
Projektisuunnitelma Projektin tavoitteet Projektin tarkoituksena on tunnistaa erilaisia esineitä Kinect-kameran avulla. Kinect-kamera on kytkettynä tietokoneeseen, johon projektissa tehdään tunnistuksen Lisätiedot Vaatimusmäärittely Ohjelma-ajanvälitys komponentti
Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit Lisätiedot Strathclyde-prosessi
Strathclyde-prosessi (Materiaali pohjautuu Terry Williamsin luentokalvoihin The Catastrophic Project - an examination of some real-life project failures and an exposure of root causes. Project Management Lisätiedot Testauspalvelu laadunvarmistajana Arekin monitoimittajaympäristössä. Satu Koskinen Teknologiajohtaja, Arek Oy
Testauspalvelu laadunvarmistajana Arekin monitoimittajaympäristössä Satu Koskinen Teknologiajohtaja, Arek Oy Agenda Arek yrityksenä Testauspalvelun uudelleen järjestelyt 2014 Vastuut ja käytännön työnjako Lisätiedot Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat
Järjestelmäarkkitehtuuri (TK081702) SOA yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja, Lisätiedot AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011
AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä Lisätiedot 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, Lisätiedot FENG OFFICE -PROJEKTINHALLINTATYÖKALU
1(5) FENG OFFICE -PROJEKTINHALLINTATYÖKALU Verkkoprojektissa tarkoituksenmukaisen projektinhallintatyökalun käyttö vähentää viestintään kuluvaa työaikaa merkittävästi, kun projektin osapuolilla on reaaliaikainen Lisätiedot Työkalujen merkitys mittaamisessa
Työkalujen merkitys mittaamisessa Mittaaminen ja Ohjelmistotuotanto -seminaari Toni Sandelin 18.4.2001, VTT Elektroniikka, Oulu 1 Sisältö Mihin työkalutukea tarvitaan? Työkalut & metriikat: luokitus Mittausohjelmien Lisätiedot Mitä Lean on? Lean5 Europe Oy Ltd
Mitä Lean on? Lean5 Europe Oy Ltd Tommi Elomaa MITÄ ON LEAN? 1. ARVO TEHDÄÄN VAIN SITÄ, MIKÄ TUOTTAA ARVOA ASIAKKAALLE. EI TEHDÄ MITÄÄN MUUTA. Leanin keskeinen ajatus on päinvastainen Tarkoitus ei ole Lisätiedot 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 Lisätiedot Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön
Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko tarjoaa mainion tilaisuuden toteuttaa tapahtumia yhteistyössä oman alueen eri organisaatioiden kanssa. Lisätiedot Hankinnan problematiikka
Antti Kirmanen Hankinnan problematiikka Toimittajan näkökulma Asiakkaan näkökulma www.sulava.com www.facebook.com/sulavaoy 2 1. Ristiriita www.sulava.com www.facebook.com/sulavaoy 3 Asiakas haluaa Onnistuneen Lisätiedot TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!
TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka Lisätiedot 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 Lisätiedot 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 Lisätiedot ecome Markkinoiden kehittynein julkaisujärjestelmä
ecome Ecome Finland Oy Itämerenkatu 3 p. 020 7749 580 00180 Helsinki p. 020 7749 585 Suomi - Finland ecome@ecome.fi y. 2193874-3 www.ecome.fi Ecome-järjestelmä pähkinänkuoressa Ecome on suomalaisen yhtiön Lisätiedot Forssan kaupungin INNOVAATIOSÄÄNTÖ
Forssan kaupungin INNOVAATIOSÄÄNTÖ Yhteistoimintaryhmä 20.12.2010 Kaupunginhallitus 10.1.2011 Sisällysluettelo 1. Merkitys... 3 2. Synty... 3 3. Tavoitteet... 3 4. Määritelmä... 3 5. Tekeminen... 4 6. Lisätiedot Valtakunnallinen AlueAvain Hanketoiminnan ihanuus ja kurjuus 27.10.2015 Marja Tuomi
Valtakunnallinen AlueAvain Hanketoiminnan ihanuus ja kurjuus 27.10.2015 Marja Tuomi Päivän ohjelmasta Projektin elinkaari Ideasta suunnitteluun Käynnistämisen haasteet Suunnitelmasta toteutukseen Palautteen Lisätiedot Kansallinen digitaalinen kirjasto Käyttöliittymä Finna. 12.12.2012 Aki Lassila / Kehittämispäällikkö / Kirjastoverkkopalvelut
Kansallinen digitaalinen kirjasto Käyttöliittymä Finna 12.12.2012 Aki Lassila / Kehittämispäällikkö / Kirjastoverkkopalvelut Finna tehostaa ja mahdollistaa Finnan kehittämisen myötä KDK:sta tulee: Tiedon Lisätiedot Ostavat organisaatiot konsultin silmin
Ostavat organisaatiot konsultin silmin Softaa sutjakasti - Kuinka pitää projektimopo käsissä Sytyke Ry:n laivaseminaari 9.9.2009 Paula Miinalainen, Arbor Vitae Konsulttina monitoimittajaympäristöissä muutosten Lisätiedot CASE Varma Testauksen haasteet moniuloitteisessa testiympäristössä. 5.11.2015 Tuukka Vähäpassi
CASE Varma Testauksen haasteet moniuloitteisessa testiympäristössä 5.11.2015 Tuukka Vähäpassi Varman esittely Keskinäinen työeläkevakuutusyhtiö Varma on Suomen suurin työeläkevakuutusyhtiö ja yksityinen Lisätiedot Kuopio. Testitapausluettelo: Projektit-osakokonaisuus
Kuopio Testitapausluettelo: Projektit-osakokonaisuus Kuopio, testitapausluettelo, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 19.3.2002 Matti Peltomäki Kriittisen prioriteetin testitapaukset Lisätiedot Valintanauhan komentojen selaaminen Jokaisessa valintanauhassa on ryhmiä ja jokaisessa ryhmässä on joukko siihen liittyviä komentoja.
Pikaopas Microsoft Project 2013 näyttää erilaiselta kuin aiemmat versiot. Tämän oppaan avulla pääset alkuun nopeasti ja saat yleiskuvan uusista ominaisuuksista. Pikatyökalurivi Voit mukauttaa tämän alueen, Lisätiedot 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ä Lisätiedot Integrated Management System. www.ims.fi, Ossi Ritola