Laadunvarmistus, tarkastukset ja testaus Mitä on laatu? Miten varmistua laadusta? Laatumittaus Testaus Tarkastusmenettely
Laatujärjestelmä Liiketoiminta, johtaminen Laatujärjestelmä Hankkeiden hallinta (tuotteen tasolla) Projektinhallinta Projektinhallinta Projektinhallinta määrittely suunnittelu ohjelmointi testaus käyttöönotto, ylläpito tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta...
asiakasvaatimukset Prosessi? Vaatimustenhallinta? SWE-Prosessi
Esimerkki: pitsoja koteihin toimittava yritys tilaukset valmistus toimitukset tilaaja tilaus tilauksen vastaanotto vastaanotettu tilaus valmista pitsa pitsat toimita pitsa toimitus asiakas Mitenhän tämä poikkeaa ohjelmistohankkeesta?
Prosessi
Laatu ja laatujärjestelmä Termi laatu on omiaan herättämään tunneperäisiä reaktioita. Onko laatu virheettömyyttä, mitä on virheettömyys? Onko laadukkaiden osien summa laadukas? "Määritelmä" Tuotteen kyky täyttää asiakkaan kohtuulliset toiveet ja odotukset. Oikea tuote, oikea hinta, oikeaan aikaan. Laatu on välttämättä aina jossain määrin subjektiivista, so. riippuvainen käyttäjästä Objektiivinen laatu: tuote on siinä mielessä virheetön ja tarkoituksenmukainen, että se on määrittelynsä mukainen. Subjektiivinen laatu: tuote täyttää käyttäjänsä (ja asiakkaan) tuotteeseen kohdistamat odotukset. Eri käyttäjillä on erilaisia odotuksia. Laatujärjestelmä eli laadunhallintajärjestelmä määrittelee yrityksen toimintatavat.
Ohjelmiston laatuattribuutit: ISO 9126 Analyzability Changeability Stability Testability Adaptability Installability Co-existence Replaceability Maintainability Time behavior Resource utilization Portability Efficiency ISO 9126 External and internal quality Usability Functionality Reliability Understandability Learnability Operability Attractiveness Suitability Accuracy Interoperability Security Maturity Fault tolerance Recoverability mittausesimerkki
Laadun osatekijät standardissa ISO 9126 Toiminnallisuus (functionality) suitability accuracy inteoperability security Luotettavuus (reliability) maturity fault tolerance recoverability Käytettävyys (usability) understandability learnability operability attractiveness Tehokkuus (efficiency) time behaviour resource utilization Ylläpidettävyys (maintainability) analysability changeability stability testability Siirrettävyys (portability) adaptability installability co-existence replaceability
Prosessin/laatujärjestelmän raskaus Toimintatapojen tulee olla järjestelmällisiä, mutta toisaalta byrokratia on minimoitava. Prosessin tulee kuitenkin olla tarpeeksi byrokraattinen yleensä hieman byrokraattisempi kuin mitä aluksi luulisi. Järjestelmällisyyden ja byrokratian tarvetta lisäävät hankkeen koko henkilöiden vaihtuvuus kokemus ja ammattitaito ylläpitovaatimukset, järjestelmän arvioitu käyttöaika tuotteen luotettavuus- yms. vaatimukset asiakkaiden vaatimukset, lait, viranomaismääräykset yms.... Suurissa hankkeissa kyky vastata nopeasti muuttuviin asiakastarpeisiin yleensä vähenee. Laatujärjestelmän tulee mahdollistaa eri tilanteisiin sopivat toimintamallit.
Prosessi Prosessi, täysin epävirallinen määritelmä: systemaattinen toimintatapamalli jonkin tavoitteen saavuttamiseksi koostuu ihmisistä, tehtävistä, järjestelmistä, työkaluista ja menetelmistä sekä toisista prosesseista. Esimerkki Prosesseihin liittyy Tavoitteellisuus: prosesseille määritellään tavoitteet, joiden toteutumista on kyettävä mittaamaan (=tarkoitus, syötteet, tulokset, ohjaus ja mittarit) Ohjeistus: kuvaa prosessin aktiviteetit, toimijat ja vastuut. Näkyvyys: miten voidaan todentaa, että on toimittu prosessin mukaisesti. Suunnitelmallinen toiminnan kehittäminen: tavoitteiden toteutumisen arviointi ja mittaus sekä niihin perustuva toimintatapojen suunnitelmallinen kehittäminen. Omistaja(t): omistajan vastuulla on prosessikehitys, prosessin tehokkuus, mittareiden seuranta, muutosten käyttöönotto, tietojärjestelmäratkaisut... Prosessin tarkoituksena on ensisijaisesti ennustettavuus (?): asiat tehdään samalla tarkoituksenmukaisella tavalla suorittavista ihmisistä ja tilanteesta riippumatta sählääminen vähenee toiminnan ja tuotteiden laatu on (ainakin jossain määrin) ennustettavissa toimintaa voi mitata, ohjata ja ymmärtää. Ohjelmistotalon laadunhallintajärjestelmä määrittelee yleensä muutamia ohjelmistokehitykseen suoraan liittyviä ydinprosesseja, esimerkiksi asiakasprosessi, tuotekehitysprosessi ja ylläpitoprosessi.
...prosessi Kannattaa pitää mielessä, että hyvälläkään prosessilla ei voi korvata ammattitaitoisia ohjelmistokehittäjiä...mutta ammattitaitoiset ohjelmistokehittäjät, joilla on hyvä prosessi, päihittävät aina ammattitaitoiset ilman prosessia toimivat kehittäjät.
Prosessien vertailu Vesiputous RUP: Rational unified process CMM: Capability Maturity Model XP: extreme Programming SPICE: ISO 15504 Epämuodollinen, joustava ISO 9001 RUP SPICE CMM MIL STD Byrokraattinen XP Scrum iteratiivinen Muutettu (aika paljon) lähteestä Kroll, P. and Kruchten, P., The Rational Unified Process Made Easy. Addison-Wesley (2003) 416pp.
G-miehen näkemys softanteosta
Menetelmien kehittelijät työssään
Not everything that can be counted counts, and not everything that counts can be counted -- Albert Einstein, 1879 1955. Laadun mittaaminen Motto: mitä ei mitata, sitä ei voi ohjata Mittarit voidaan karkeasti jakaa kahteen luokkaan Strategiset mittarit: pitkä aikaväli, liiketoimintanäkökulma, lähtökohtana usein ns. tasapainoitettu mittaristo -kehys Operatiiviset mittarit: päivittäistä tietoa päätöksenteon tueksi Tässä keskitytään pääasiassa ohjelmistoprojektiin ja tuotantoprosessiin liittyviin operatiivisiin mittareihin Miksi mitataan Tietoa päätöksenteon tueksi ( missä ollaan ) Miten prosessia on kehitettävä: ymmärtäminen, oppiminen ja kehittäminen Miten tavoitteet on saavutettu Mitä mitataan Tuotetta ( missä ollaan ) Prosessia (miten kehitetään, ymmärtäminen, oppiminen)
Mittaamisen ongelmia Mittaaminen aiheuttaa kustannuksia. Käytännössä kovin luotettavia yksittäisiä mittareita ei ole. Asenneongelmat: yleensä ihmiset vastustavat mittareiden käyttöönottoa: "epätarkka", "hukkatyötä", "voi käyttää/tulkita väärin" "mahdotonta ei näitä tuloksia kuitenkaan mihinkään käytetä... Ihmiset sopeuttavat toimintaansa mittareihin ( sitä saa mitä mittaa ). Tulos ei välttämättä muutu. Tuottavuutta mitataan koodirivien määrällä. Virheiden vakavuusaste vaikuttaa palkkaan.
Millaisia mittareita Mittaamisen on oltava mahdollisimman automaattista. Mittareita on oltava mahdollisimman vähän, mutta kuitenkin riittävästi. Mittaustulosten hyväksikäyttötavan on oltava kaikilla selvillä. Mittarin väärinkäyttö on vältettävissä. Mittaa mielellään prosessia ja ryhmää, ei yksilöä. Objektiivisuus ja luotettavuus: tulos ei saa olla riippuva mittaajasta tai mittausajankohdasta, mittaukset toistettavissa. Trendit absoluuttisia arvoja tärkeämpiä. Ymmärrettävyys: mistä mittarin arvon muutokset johtuvat. Asiakkaan kannalta mielekäs. Mittarin arvot muutettavissa euroiksi.
Tuotteen mittaaminen, esimerkkejä Otetaan pohjaksi ISO 9126 -standardin jaottelu Toiminnallisuus Toteutetut käyttötapaukset / kaikki käyttötapaukset Läpi menevät järjestelmätestitapaukset / kaikki testitapaukset Luotettavuus Mean time between faults (MTTF) Korjatut virheet / löydetyt virheet Koodianalysaattorin virheilmoitukset Testikattavuusmitat Käytettävyys Asiakaspalaute, asiakastyytyväisyystutkimukset Käytettävyystestit Tehokkuus Vasteajat kuormitustesteissä Prosessorin käyttöaste kuormitustesteissä Vapaan muistin määrä kuormitustesteissä Ylläpidettävyys McCaben syklomaattinen kompleksisuus Maintainability index, lasketaan Halsteadin mitasta, McCaben mitasta, koodirivien määrästä ja kommenttirivien määrästä (ks. esim. Welker 2001). Siirrettävyys? Welker, K.D. 2001. The Software Maintainability Index Revisited. CrossTalk The Journal of Defense Software Engineering 14, 8, pp. 18-21. Ylisiurua, Hannu, Tuotetiedonhallintajärjestelmän leimasinkomponentin ylläpidettävyyden arviointi. Diplomityö, TTY, 2003
Esimerkkejä prosessimittareista Aikataulut: arvioidut ajat, toteutuneet ajat. Katselmoinneissa/testauksessa löytyneet virheet. Aika virheen havaitsemisesta sen korjaamiseen. Virhekustannukset Testauksessa löytyneiden virheiden aiheuttamat lisäkustannukset. Takuuaikaiset korjaukset Laskutuskelvottomat tunnit. Tuottavuus.
Liikkeellelähtö Aluksi muutamia selkeitä mittareita: aikataulujen toteutuminen asiakasvirheiden määrä takuutyön määrä asiakastyytyväisyys. Kokemuksen karttuessa mittareita otetaan lisää. Mittaustuloksista tiedotetaan: trendit näkyvissä kahvihuoneen seinällä.
Errors in a product project at March Errors found open errors 2001 error estimate open errors estimate
Otos yhden laatumittauksen tuloksia Luennot 3.1 Harjoitukset 3.7 Materiaali 3.4 Mielenkiintoni opetettuun aiheeseen lisääntyi kurssin aikana: 3.5 Opettajat ovat ystävällisiä ja ymmärtäväisiä: 4.2 Opettajien antama henkilökohtainen ohjaus on riittävää tehtävien suorittamiseen: 3.8 Harjoitustyö oli relevantti opintojakson kokonaisuuden kannalta: 4.1 Uskon kurssista olevan hyötyä myöhemmissä opinnoissani: 3.9 Opetettava aine on ajankohtainen: 4.1 Opin opintojaksolla paljon: 3.8
TASAPAINOTETTU MITTARISTO Balanced Scorecard, BSC Luultavasti yleisimmin käytetty kehys liiketoimintalähtöisten mittareiden määrittelyyn Paljon kirjallisuutta Näkökulmat taloudellinen (= omistajat) (mennyt) asiakas (nykyhetki) prosessi (nykyhetki) henkilöstö (= oppiminen) (tulevaisuus) Kaplan R S and Norton D P (1992) "The balanced scorecard: measures that drive performance", Harvard Business Review Jan Feb pp. 71-80.
Prosessin kehittäminen: on vaikeaa tuottavuus kehityshankkeet Miten hallita tilanne projektipaineista huolimatta? muutoksen vakiinnuttaminen? aika Arvaus: suurin osa isoista harppausyrityksistä epäonnistuu
Etene riittävän pienin harppauksin tuottavuus Termejä: -SPI, Software Process Improvement -Process Re-Engineering aika
Kehittämisen askeleet Kartoitetaan nykytilanne. Tähänkin asti on eletty, ei liian suuria muutoksia kerralla. Priorisoidaan kehitystarpeet. Otetaan ensimmäinen askel... Yksinkertainen malli toimintaprosessista (mitä vaiheita projektiin kuuluu). Usein lähdetään liikkeelle dokumentointimalleista Määrittely- ja suunnitteludokumentit. Projektinhallintaan liittyvä dokumentaatio (projektisuunnitelma, seuranta).
Ongelmia Monet hankkeet hiipuvat innostuneen alun jälkeen. Johdon tuki ja sitoutuminen puuttuu. Koulutukseen ei panosteta tarpeeksi. Usko kaikkivoipiin työkaluihin. Liian suuret odotukset. Rima liian korkealla. Liian suuri muutos kerralla. Muutosvastarinta. Ajankäyttö. Cowboy-mentaliteetti. Ei toimintamallia - ei käsitystä ongelmista. Prosessia ei voi ostaa.
Frustraatio 1960-luvulta The practice of programming as personal art led to the realization that standards in programming were imperative. Implementing QC was a supreme test of skills in personal relations -- and was not well demonstrated. To the extent that we were seen as imposing standards there was resistance and resentment. Without doubt, we failed in every aspect of personnel relations. In a day when programmers were simply not unemployed and available in the labor market, we experienced more than a 100 percent turnover in programming personnel in a six month period. Matley, B.G., Compu-Then: Before Megabytes. In: Glass, R.L., In the Beginning: Recollections of Software Pioneers, IEEE Computer Science Press (1998) pp. 154-164 (quotation from pages 157-158).
Standardeja ISO9001 Tällä hetkellä käytännössä tärkein (ei silti kovin tärkeä?). ISO9001 standardi määrittelee tietyt puitteet laatujärjestelmän kehittämiseksi. Uusin versio vuonna 2008. CMMI SEI:n (Software Engineering Institute) perinteinen CMM-malli (Capability Maturity Model) määrittelee viisi kypsyystasoa. Kypsyystasomalli määrittelee asiat, joita kullakin tasolla on kehitettävä seuraavalle tasolle pääsemiseksi. Nykyisin mallin nimi on CMMI ja siitä on kaksi versiota staged representation: perinteinen CMM-malli continuous representation: vastaa ISO 15504-standardia SPICE (eli ISO 15504) Muita standardeja Laatupalkintokriteerit (www.sly.fi): vuoden 2009 voittaja Viking Line ITIL (~ISO 20000): palveluiden hallinta, yrityksen tietohallinto (Joel test)
CMM kypsyystasot Taso 1: Initial Process. Taso 2: Repeatable process. Projektit pystytään viemään läpi suunnitelmien mukaisesti. Taso 3: Defined Process. Prosessi on määritelty, sitä noudatetaan, ja sitä pyritään tehostamaan. Taso 4: Managed Process. Prosessia mitataan ja mittaustuloksia käytetään sen parantamiseen. Taso 5: Optimizing Process. Tietoa kerätään automaattisesti ja sitä käytetään prosessin optimoimiseksi. Millähän tasolla yritykset yleensä ovat?
CMM arviointien tuloskehitys
Yhteenveto 30 vuoden kokemuksesta What I found was this: The inspection and testing process, defect discovery and repair throughout the development life cycle, seemed to drive success -- delivering a usable system in time. I could not correlate success with programming methods such as design methods, language, or coding practices. A certain number of defects will be introduced regardless. What appears to matter a great deal is the application of professional engineering. By that I mean technical management: establishing precise plans and procedures; defining computer programs in terms of their correctness, not just their development, and evaluating them quantitatively with respect to budgets and schedules; using models; developing a detailed system integration plan; and measuring results scientifically (projects that rely on status reports, such as test cases run, do not fare well). Britcher, R.N., A View from Below. In: Glass, R.L., In the Beginning: Recollections of Software Pioneers, IEEE Computer Science Press (1998) pp. 98-111 (quotation from page 111). (Taitto ja korostukset ijh:n)
A quotation of one of the managers, only 2 years before the big disaster at AA "...we have spent 30 years handicrafting computer systems. We like to think we re better at this than most and that our skills in hardware evaluation, project management for software development, and systems integration have given us an important leg up on the competition.
Auditointi Auditointi: tarkasteltavasta kohteesta riippumattoman henkilön tekemää laatujärjestelmän arviointia (audit, assessment, review). Auditointi voi olla joko sisäinen tai ulkoinen: sisäinen: yrityksen itse tekemä auditointi ulkoinen: esimerkiksi toisen yrityksen tai kolmannen osapuolen tekemä. Muodollinen tilaisuus, jonka aikana tarkastetaan tuotteen tai toiminnan laatu vertaamalla sitä dokumentaatioon tai standardiin. Toiminnan auditoinnissa toiminnan vertailukohtana on esimerkiksi yrityksen oma laatujärjestelmän kuvaus tai jokin laatustandardi (esimerkiksi ISO 9001).
... auditointi Tehdään, usein määrävälein, suunnitelmallisesti ohjeistukseen verraten (sekä sisäisiä että ulkoisia, ISO9001-vaatimus). Tarkastuksen kohteeksi valitaan yleensä tietty osa laatujärjestelmää. Tulokset dokumentoidaan pöytäkirjaan. Korjaavista toimenpiteistä päätetään esimerkiksi laaturyhmän kokouksessa. Ulkoisen auditoinnin tavoitteita: varmistaa, että toimittaja pystyy toimittamaan tuotteen osoittaa, että toiminta on laatujärjestelmän mukaista (sertifiointi) yritysten välinen benchmarking, oppiminen. Sisäisen auditoinnin tavoitteet: Oman toiminnan vahvuuksien ja heikkouksien tunnistaminen. Kehityskohteiden tunnistaminen. Koulutus. Valmistautuminen ulkoisiin auditointeihin.
Mitä auditointi ei ole Ihmisten kritisointia. Esimiesten keino alaisten arvointiin. Poliisitoimintaa, jolla saadaan rosvot kiinni. Mestarointia, jossa auditoija kertoo, miten asiat tulisi hoitaa. Ei myöskään suoraan pyri arvioimaan laatujärjestelmän hyvyyttä / huonoutta.
Auditoinnin vaiheet Vastuu Päätös auditoinnista Johto Auditoinnin suunnittelu Auditoija(t) Auditoinnin yleisesittely (aloituskokous) Auditoija(t) Auditointi - dokumenttien tutkiminen (ohjeet, tulosdokumentit) - haastattelut ja toiminnan tarkastelu - havaintojen teko ja kirjaus Auditoija(t) Päätöskokous - tulosten esittely - jatkotoimenpiteet Auditoija(t) Kirjallisen raportin laadinta Auditoija(t) Kehitysssuunnitelman laadinta Korjaavat toimenpiteet Seuranta Johto
Auditointi käytännössä Perustuu laatudokumentaatioon ja valittuun standardiin. Auditoija tutkii ensin mahdollisen laatudokumentaation (ohjeistus, dokumentointimallit jne.) ja sen riittävyyden standardeihin nähden. Auditoijan työvälineinä laatudokumentaatio, standardi (esim. ISO 9001), kysymyslistat sekä kynä ja paperi. Oleellista auditoinnissa on käytännön, eli todellisen toiminnan tutkiminen. Auditointi pohjautuu havaintoihin: haastattelut, työvälineiden, -tapojen ja -tulosten tarkastelut. Dokumenttien sisältöön ei yleensä puututa. Toiminnan tarkastelun jälkeen auditoijat kirjoittavat raportin, johon havainnot kirjataan. Raportin pohjalta voidaan laatia suunnitelma kehitystoimenpiteiksi. Johdon tehtävänä on huolehtia korjaavista toimenpiteistä ja suunnitelmien toimeenpanosta.
Auditoitavia kohteita Yleiset vaatimukset laatupolitiikka, johdon seuranta organisaatio, sisäiset auditoinnit, korjaavat toimenpiteet koulutus ja -asiakasohjautuvuus. Projektitoiminta projektien organisointi projektien suunnittelu, projektien seuranta..., Tuotteenhallinta: identifiointi, versionhallinta, konfiguraationhallinta ja toimintatavat. Menetelmät, työvälineet, dokumentit, ohjelmakoodi... Laadunohjaus: tarkastukset, katselmukset, testaus, mittaus... Tuotteen toimittaminen asiakkaalle.
Testauksen aamunkoitto
Määritelmiä Myers 1979 1 Testaus on prosessi, jossa etsitään virheitä ohjelmaa tai sen osaa suorittamalla. Hetzel 1983 2 Testausta ovat kaikki menetelmät, joilla pyritään arvioimaan ohjelmiston jotain ominaisuutta. Testaus on ohjelmiston laadun mittaamista. Craig ja Jaskiel 2002 3 Testaus on ohjelmistotuotantoprosessi, jossa käytetään ja ylläpidetään testwarea tarkoituksena mitata ja parantaa testattavan ohjelmiston laatua. Testware kattaa kaiken testaukseen liittyvän materiaalin: suunnitelmat, testauskoodin, testidatan... >2010? Testaus on spesifiointia (eli siis speksaamista ), virheiden etsimistä ja laadun mittaamista. 1. Myers, G.J., The Art of Software Testing. John Wiley & Sons (1979) 177pp. 2. Hetzel, B., The Complete Guide to Software Testing. QED Information Sciences (1984). 3. Craig, R.D. and Jaskiel, S.P., Systematic Software Testing. Artech House Publishing (2002) 536pp.
Jatkuva testaaminen Ennen: virheiden etsimistä Rakenna Testaa Nyt: virheiden etsimistä ja laadun mittaamista Rakenna Suunnittele, rakenna ja ylläpidä testwarea Testaa
Esimerkkiraportti testauksen tilanteesta Raportti: The Economic Impacts of Inadequate Infrastructure for Software Testing, May 2002 Ohjelmistovirheiden kustannukset USA:n kansantaloudessa n. $60 miljardia, säästöpotentiaali n. $22 miljardia
Tulevaisuus Testaus ja sille asetetut vaatimukset ovat lisääntymässä ja monimutkaistumassa huomattavasti. Ne ovat lähestymässä vaativuudeltaan testattavan ohjelmiston tekemistä => testware engineering. Seurannaisilmiöitä Testware engineering on entistä keskeisempi osa tuotekehityshanketta ja se integroituu aikaisempaa selkeämmin kaikkiin ohjelmistotyön vaiheisiin koko elinkaaren ajan. Testiaineistojen ja -ympäristöjen kehitys- ja ylläpitotyöhön on kehitettävä samantapaisia kurinalaisia ja hyvin määriteltyjä prosesseja ja välineitä, kuin itse ohjelmistotuotantoakin varten on kehitetty. Testaus ei voi enää olla sekundahommaa. Huippuasiantuntijoiden tarve lisääntyy. Osa testaajista on myös hyviä ohjelmoijia. (Ns. apinatestaus ulkoistetaan halvempiin paikkoihin.) Kasvavan regressiotestaustarpeen johdosta testausautomaatio ja työvälineiden käyttö lisääntyy. Testaus liittyy entistä tiiviimmin speksaukseen, ja saattaa tavallaan jopa korvata sen (dokumentoidut testitapaukset voivat toimia speksin korvikkeena). Testauksen testaukseen on kiinnitettävä huomiota.
Testauksen määrää ja mutkikkuutta kasvattavia tekijöitä Miksi? koodia pitää syntyä enemmän, nopeammin, tehokkaammin laadukkaammin, ennustettavammin. Tähän on reagoitu tuotantoprosessin muutoksella Iteratiivisuus tuotantoprosessissa Testaustulosten käyttö prosessimittareina, release management Ei-toiminnallisten ominaisuuksien testaus: käytettävyys, luotettavuus, ylläpidettävyys, turvallisuus, suorituskyky, interoperability, konformanssitestaus
Testauksen määrää Myös teknologiaan ja toteutustekniikoihin yms. liittyviä tekijöitä Hajautetut sovellukset, monikerrosarkkitehtuurit, Internetsovellukset (.9*.9*.9*.9=~0.66) Komponenttiohjelmointi, EJB,.NET Uudelleenkäyttö, ohjelmistoalustat (platform), sovelluskehykset Tuoteperheet Asiakaskohtaisten versioiden paketointi Järjestelmäintegraatio, EAI (Enterprise Application Integration) Monitoimittajaympäristön hallinta Mobiiliohjelmointi (yhteentoimivuus, käytettävyys, suorituskyky, muistinhallinta) Säikeiden käyttö Sulautetut järjestelmät Testikoodin lisääntyessä sen ylläpidon vaatima työmäärä lisääntyy => samantapaisia haasteita kuin muussakin ohjelmistokehityksessä
Testaus virheidenetsintäkeinona ohjelma syöteavaruus ohjelmakoodi tulosavaruus X Y sisäinen tila Johtopäätös? Syöteavaruuden koko ja mahdollisten tilojen määrä on niin valtava, ettei edes pienen ohjelman kattava testaus ei ole käytännössä mahdollista. Reaaliaikajärjestelmän tapauksessa tilanne on kertaluokkaa ongelmallisempi. Testaamalla voi siis osoittaa, että ohjelmassa on virheitä, ei sen virheettömyyttä.
Ideaalitilanne speksattu testattu toteutettu speksattu= toteutettu= testattu
Testaus Testaus on systemaattista virheiden etsimistä -- ei sattumanvaraista ohjelman kokeilua. Testauksen tarkoitus on osoittaa että ohjelmassa on virheitä. Mitä enemmän virheitä löytyy, sitä onnistuneempi testi on. Virhe on ristiriita spesifikaation ja toteutuksen välillä. Virheiden jäljitys eli debuggaus ei ole testausta. Tehtäviä... Testaussuunnitelman laatiminen. Ensimmäinen versio jo määrittelyvaiheessa. Testauksen tavoitteet kussakin testissä. Testikohtaisesti testitapausten suunnittelu. Testausympäristöjen luonti. Testauksen suoritus. Tulosten tarkastelu.
Error, fault, failure Virhe (error): ihmisen tekemä möhläys, esimerkiksi ohjelmointivirhe tai virhe dokumentissa. Kun virheellinen ohjelmankohta suoritetaan (tai koodia puuttuu), se saattaa aiheuttaa vian (fault). Järjestelmä on nyt tilassa, joka ei ole sen määrittelyn mukainen. Vika puolestaan voi aiheuttaa häiriön (failure), joka on vian ilmeneminen järjestelmän ulkoisessa käyttäytymisessä. Kansanomaisesti ilmaisten bugilla tarkoitetaan jotain ylläolevista.
Testauksen ongelmia Asenne: testauksella yritetään osoittaa ohjelman toimivuus, ei toimimattomuus. Testauksen aliarvostus: "ne jotka eivät muuta osaa, testaavat". Milloin testaus voidaan lopettaa: kun rahat/aika loppuu? Onko kaikki testattu? Mihin tehdyt korjaukset vaikuttavat? Testien toistaminen korjausten jälkeen (regressiotestauksen työmäärä). Testin toistettavuus (ajastukset ja muut hallitsemattomat ilmiöt), esimerkkejä: osoittimien käyttö (yllättävän usein) reaaliaikajärjestelmä, hajautettu järjestelmä ja graafinen käyttöliittymä.
...testauksen ongelmia Testausympäristön pystyttäminen. Testaustyökalujen vaikutus järjestelmän toimintaan. Järjestelmä on maantieteellisesti laaja (hajautettu). Poikkeamien havaitseminen on vaikeaa (esimerkiksi niiden pienuuden takia) Ei tiedetä, mikä oikean tuloksen pitäisi olla. Tilanteet, jota ei voida testitilanteessa järjestää (ohjelmistoissa on lähes aina tällaisia osia). Tulosten toteaminen oikeaksi, kun järjestelmän toimintaa ei voida seurata ulkopuolelta.
V-Malli Määrittely Arkkitehtuurisuunnittelu Moduulisuunnittelu Testauksen suunnittelu ja tulosten verifiointi Moduulitestaus Integrointitestaus Järjestelmätestaus Ohjelmointi Testitapausten suunnittelusta ajoissa on paljon hyötyä, mutta siihen liittyy myös ongelma: voi tulla tehtyä turhaa työtä.
Muita testauksen muotoja kenttätestaus hyväksymistestaus alfatestaus betatestaus regressiotestaus release testing käytettävyystestaus suorituskykytestaus...
Moduulitestaus Moduulitestaus (module testing, unit testing) varmistaa, että yksittäiset moduulit toimivat määrittelynsä mukaisesti. Ohjelmoija tekee yleensä itse.
Integrointitestaus Integrointitestaus testaa moduulien välisiä liittymiä. Testaus etenee usein rinnan moduulitestauksen kanssa joko kokoavasti (bottom up) tai jäsentävästi (top down). Jäsentävässä integroinnissa joudutaan rakentamaan kutsuttavia funktioita varten tynkämoduuleita (test stubs). Kokoavassa vaihtoehdossa tarvitaan usein testipetejä (test bed, test driver), jäsentävässä taas tynkämoduuleita (module stub). Reaaliaikajärjestelmän ohjelma koostuu tavallisesti useista tehtävistä (task, multitasking) => myös tynkäprosessien käyttö on usein hyvä idea. "Big bang on yleensä ongelmallinen.
Järjestelmätestaus Järjestelmätestaus aloitetaan usein pintapuolisella sauhutestillä (smoke testing) Järjestelmätestauksessa varmistetaan, että järjestelmä toimii määrittelynsä mukaisesti (ja käyttöohjeensa). Testauksen voi/pitäisi suorittaa ulkopuolinen ryhmä. Virheiden korjaus kallista. Luotettavuus-, toipumis-, turvallisuus- ja kuormitustestit (vasteajat, volyymit). Yhteensopivuus muiden järjestelmien kanssa.
Testitapausten valinta Lasilaatikkotestaus Harmaalaatikkotestaus Mustalaatikkotestaus Ekvivalenssiositus: jaetaan syötteet (ja tulosteet) ekvivalenssiluokkiin, mikä tahansa arvo luokassa edustaa koko luokkaa. Valitaan joka luokasta yksi arvo. Raja-arvoanalyysi: Valitaan ekvivalenssiluokista rajatapaukset. Voidaan soveltaa sekä syöteavaruuteen että tulosavaruuteen. Virheenarvaus (tarkastuslista tavallisimmista virheistä). Testattavan yksikön koon kasvaessa siirrytään lasilaatikkotestauksesta mustalaatikkotestaukseen
Yhteenveto Testauksen merkitys (ja määrä) on lisääntynyt =>testiautomaation merkitys korostuu => testauksessa erityisosaaminen korostuu. Ammattikuvan ongelma: Kansalaismielipide tuotekehityksen testausporukasta: Testaajat ovat tuotekehityksen pohjasakkaa, vain laatuinsinööri on mitättömämpi. Onko mahdollista saada pätevää väkeä kiinnostumaan testauksesta? Ja aivan viimeiseksi; hyvä testaus ei voi pelastaa huonoa ohjelmaa: Paras keino pitää testauksen määrä kohtuullisena on tuottaa vähemmän virheitä. Jos virheitä kuitenkin tehdään, ne olisi saatava tuotteesta pois mahdollisimman aikaisessa vaiheessa.
Tarkastukset ja katselmukset Johdanto: terminologia Tarkastukset Esimerkki kustannusvaikutuksista Tarkastusmenettelyn vaiheet Tarkastuslistat Tarkastusten vaikutus Ongelmat Case Bell Case Ellemtel Case TUT/projektityö
Terminologiaa Audit, assessment, arviointi: laatujärjestelmän ja organisaation toiminnan tarkastamista. Management review = johdon katselmus, tarkastetaan projektin tilanne (tai koko laatujärjestelmän tilanne, ISO 9001). Verifiointi, todentaminen: tuote on määrittelynsä mukainen. Validointi, kelpoistaminen: tuote sopii käyttötarkoitukseensa. Virhe (error, fault, failure) väärin, ei speksin mukainen (speksin täydellisyys?) ristiriita puuttuu liikaa Virheiden luokittelu: vakava, lievä, kosmeettinen tms.
terminologiaa (Technical) Review = katselmus, tekninen katselmus Tarkoituksena vaiheen päättymisen toteaminen, eli siis tehdä prosessin eteneminen näkyväksi. Tärkeimmissä etapeissa, esimerkiksi määrittely- tai suunnitteluvaiheen päättyessä. Kattaa kokonaisen vaihetuotteen. Paljon osallistujia, myös ulkopuolisia. Inspection = tarkastus: Tarkoituksena virheiden löytäminen. Joustava aikataulutus, vaiheen aikana useita. Tarkastettavana pienehkö kokonaisuus (tai osa laajempaa kokonaisuutta). Muutamia osallistujia 3-6, projektin sisäinen. Walkthrough = läpikäynti Läpikäynti on epämuodollinen tarkastuksen muoto, joka tehdään yleensä vain koodille. Tekijä selittää, mitä hän "luulee ohjelmansa tekevän". Kutsutaan joskus "koodipoliisiksi", koodi selitetään poliisille. Termien katselmus, tarkastus ja läpikäynti käyttö edellä esitetyllä tavalla ei ole vakiintunut.
terminologiaa Virtuaalikatselmus: katselmus voidaan tehdä verkossa ilman kokousta. Käytössä useissa avoimen lähdekoodin projekteissa. Avoimen lähdekoodin projektien yhteydessä vertaisarviointityyppinen (peer review) "virtuaali"katselmointi on melko yleisesti käytössä. Pariohjelmointi: ketterissä ohjelmistokehitysmenetelmissä (agile) käytetty menetelmä, jossa koodia muokatessa saman näytön ääressä istuu kaksi henkilöä, eräänlaista reaaliaikaista katselmointia. Arkkitehtuuriarviointiin on kehitetty useita katselmointimenetelmiä (ATAM, SAAM). Rick Kazman, Mark Klein and Paul Clements: ATAM: Method for Architecture Evaluation. Technical report, CMU/SEI-2000-TR-004, ESC-TR- 2000-04
Tarkastukset Tarkastusmenettely on systemaattinen yleisesti käytetty ryhmätyöhön perustuva menettely virheiden etsimiseksi mistä tahansa dokumentista ja myös ohjelmakoodista. Miksi käytetään? Tehokkaampi virheenetsimiskeino kuin testaus. Mahdollista löytää 80% virheistä. Virheet löytyvät aikaisemmin. Parantaa etenemisen näkyvyyttä. Toimii tiedonvälityskanavana. Varmistetaan, että kaikki ymmärtävät asiat samalla tavalla. Toimii koulutustilaisuutena. Sitouttaa tuloksiin. Stabiloi speksin.
Kuva 2.10 esitutkimus& sopimus määrittely tarkastus katselmus, toimittajan katselmus, asiakas mukana suunnittelu ohjelmointi ja moduulitestaus integrointi järjestelmätestaus aika 9.2.2009
Virhekustannusten kertautuminen Mitä kauemmin virhe on järjestelmässä, sen kalliimmaksi se tulee. On useasti näytetty toteen, että yli puolet (60%) tuotteesta käytön aikana löytyvistä virheistä on peräisin ohjelmointia edeltävistä vaiheista (määrittely, suunnittelu). Testaukseen ja virheiden poistamiseen kuluu 50-80% projektin ajasta. Ylläpitoon kuluu lisäksi yli puolet elinkaarikustannuksista. Ketterien menetelmien kannattajat ovat kyseenalaistaneet Johtopäätös: tämän virheiden väitteen ennaltaehkäisyyn ja havaitsemiseen ajoissa kannattaa panostaa.
Esimerkki: virheiden etsiminen Löytyvät tarkastamalla ja osittain järj. testauksessa testaamalla Löytyvät moduulitestaamalla ja tarkastamalla Löytyvät moduulitestaamalla Moduulitestaus Ei löydy tarkastamalla eikä testaamalla Korjausaika 0.5pv / virhe * 10 = 5 päivää Järjestelmätestaus Korjausaika 2pv / virhe Asiakas * 4 = 8 päivää Ajankäyttö: 5pv + 8pv = 13 päivää
Esimerkki: virheiden etsiminen Löytyvät tarkastamalla ja ositain järj. testauksessa tarkastamalla Löytyvät testaamalla ja tarkastamalla Löytyvät moduulitestaamalla Ei löydy tarkastamalla eikä testaamalla Tarkastus Korjausaika 0.2pv / virhe * 12 = 2.4 päivää Moduulitestaus Korjausaika 0.5pv / virhe * 5 = 2.5 päivää Järjestelmätestaus Asiakas Korjausaika 2pv / virhe Ajankäyttö: 2.4 + 2.5 = n. 5 päivää
Ei saa olla Keskeneräinen, Alle 50 sivua. Vaiheet Osallistujat, aikataulu Materiaali jaetaan ja esitellään lyhyesti. 15 min Sovitaan tarkastusistunnosta: aika, roolit. Työvaihe Tarkastettava dokumentti Suunnittelu esittely tarpeen? K Esittely K E Valmistautuminen Tarkastustilaisuus uusintatarkastus? E Korjaus Tekijä korjaa Tarkastuspöytäkirja Max. 2 tuntia Hyväksytty dokumentti Jälkiseuranta Materiaaliin tutustuminen, kirjataan: - "ei ymmärrä" -lista - virhelista - pikkuvirhelista (kirj. virheet) Virheiden analysointi prosessin kehittämiseksi Joku osallistujista yhdessä korjaukset tehneen/tehneiden kanssa
Roolit 2-6 henkeä. Moderaattori eli juontaja eli puheenjohtaja: huolehtii aikataulussa pysymisestä ja asian etenemisestä kokouksessa (ei mielellään tekijän linjaesimies). Ohjeita puheenjohtajalle: hillitse selittelyä; huolehdi aikataulussa pysymisestä; estä rönsyily ja liika ideointi; rohkaise/provosoi passiivisia. Tekijä (syytetty :-). Ohjeita tekijälle: älä selittele; älä tuo keskeneräistä tuotetta tarkastettavaksi. Esittelijä: esittelee materiaalia (voi olla tekijä). Sihteeri: kirjaa virheet (voi olla tekijä). Tarkastaja: kaikki toimivat tarkastajina. Muita rooleja: sovellusalueen tai jonkun teknologian asiantuntija, kieliasun tarkastaja, käyttäjänäkökulman edustaja Ohjeita kaikille: valmistaudu huolellisesti; ole ystävällinen, varo loukkaamasta tekijää; pysyttele teknisissä asioissa -- arvioi tuotetta, älä tekijää; anna myös positiivisia kommentteja; osoita ongelmat; älä esitä korjausehdotuksia; anna korjaukset pikkuvirheisiin.
Tarkastusistunto Max. 2 tuntia. Pitäisi syntyä synergiaa: löytyy uusia puuteita/virheitä. Ei selitellä ja puolustella. Ei pisteiden keräilyä. Ei syytellä. Tilaisuus ei saa muuttua ideointipalaveriksi. Etsitään virheet -- ei korjata. Sovitaan lopputuloksesta ja jälkiseurannasta. Dokumenttina syntyy tarkastuspöytäkirja, johon tulos kirjataan: osallistujat ajankäyttö / osallistuja hyväksytty / hylätty korjausaikataulu yhteenveto virheistä mahd. seurantamenettely
Mitä tarkastetaan? Seuraava lista suunnilleen prioriteettijärjestyksessä. Tarjous, sopimus (ISO 9001). Määrittelydokumentit (toiminnallinen määrittely). Projektisuunnitelma. Suunnitteludokumentit (tekninen määrittely). Testaussuunnitelmat. Koodi. Käyttäjälle menevä dokumentaatio. Koulutusmateriaali, koulutussuunnitelma. Käyttöönottosuunnitelma.
Tarkastuslistat Käytetään apuna tarkastuksissa. Laaditaan (ja ylläpidetään) kutakin vaihetuotetta varten kokemusten perusteella. Tarkastuslistat voivat olla projekti/tuotekohtaisesti - dynaamisia (=uusia kohtia lisätään tarkastusten yhteydessä). Esimerkki, opetusohjelman muuttaminen jonkun kurssin osalta Soveltuvuus pääaineeseen, vs. sivuaineet Koulutusohjelman vaihtajat Koulutusohjelman rakenne Rajapinnat muihin kursseihin, päällekkäisyys Kurssien rytmitys lukujärjestykseen Käytettävissä olevat opettajat Laitteet/ohjelmistot Opetustilavaikutukset Kustannusvaikutukset Toimintamallit siirtymäkaudelle Imago ja politiikka Intissä olevat opiskelijat
Tarkastusten vaikutuksesta Tarkastusten käyttö muuttaa kustannusjakauman etupainotteisemmaksi. Monet virheet eivät löydy testaamalla Tarkoituksena on löytää virheitä => inhimillisesti ottaen haastava prosessi. Tarkastuksella voidaan löytää tyypillisesti n. 80% virheistä (= enemmän kuin esimerkiksi testaamalla). Tarkastukset yleensä n. 5-15% projektin kokonaistyömäärästä. Tarkastuksilla on myös muita etuja. Varahenkilö Oppiminen Perehtyminen toisten tekemään työhön. Sitoutuminen projektin tuloksiin.
Tarkastusten vaikutus työmäärään Ilman tarkastuksia Tarkastusten kanssa Määrittely Määrittely Suunnittelu Suunnittelu Ohjelmointi, moduulitestaus Ohjelmointi, moduulitestaus Integrointi, testaus Integrointi, testaus varsinainen työ virheiden aiheuttama lisätyö
Pahimmat ongelmat Pahimmat kompastuskivet: asenteet ja organisointi. Tarkastustilaisuudessa Valmistautumattomuus Perehtymisen työmäärä Motivointi, asenteet Rönsyily Lepsu puheenjohtaja Ideointi, korjailu Työmäärää ei oteta huomioon aikataulutuksessa (varsinkin muiden projektien tarkastuksiin osallistuminen) Liikaa materiaalia
Experience with Inspections in Ultra- Large Scale Developments. Raportti Bell-Northern Researchin tarkastusten käyttöönotosta. Toimittaa puhelinkeskuksia, koodin kokonaismäärä 15 miljoonaa riviä. Tuloksia 2.5 miljoonan koodirivin tarkastuksista (rivimäärät eivät sisällä kommentteja). Tarkastus neljän hengen ryhmissä: pj, sihteeri, esittelijä, tekijä. Työteho: 0.8-1 virhettä/htt (henkilötyötunti). htt sisältää myös valmisteluun käytetyn ajan. 2-4 kertaa nopeampaa kuin virheiden etsiminen ja korjaaminen testaamalla. Asiakkaan raportoiman virheen korjaus vie keskimäärin 4.5 työpäivää. Tarkastusvauhti 150 riviä tunnissa (Fagan: esittelyssä 500 riviä, valmistautuessa 125 riviä tunnissa ja tarkastuksessa 90 riviä tunnissa).
Havaintoja Koodissa aluksi virheitä n. 40-50 kpl tuhatta riviä kohti. Näistä 80% on löydettävissä tarkastamalla (sopivalla vauhdilla). Virheitä, jotka eivät löydy testaamalla turha koodi, standardeja noudattamaton koodi ja kommenteissa olevat virheet.
Virheiden poistaminen tarkastamalla koodia on huomattavasti testausta halvempaa. Miksi? Testaus Testin suunnittelu. Testiympäristön pystyttäminen. Testin suorittaminen. Tulosten tarkastaminen => virheet. Virheiden jäljitys (debug). Virheiden korjaus. Tarkastaminen. Yleiskatsaus. Valmistautuminen. Tarkastus. Korjaus: jäljitystä ei tarvita, korjaukset usein ilmeisiä.
Ongelmia Tarkastusten tehokkuudesta ei ole käytettävissä todisteita. Tarkastukset vievät paljon aikaa (virheet vievät vielä enemmän). Väärinkäsitykset tarkastustekniikasta: mitä tahansa kommentointia pidetään tarkastuksena. "Low tech" -tekniikan imago, ihmiset luulevat, että testaus ja jäljitys on nopeampaa.
Kuva 14.7