Laadunvarmistus:

Laadunvarmistus on joukko käytäntöjä, joiden tarkoituksena on varmistaa, että tuote täyttää vaatimukset ja toimii oikein. Se kattaa prosessit, standardit ja toiminnot, jotka tuottavat laatua, eikä pelkästään toimintoja, jotka tarkistavat sen puuttumista. Ero laadunvalvonnasta, joka on valmiin tuotteen tarkastus, on enemmän kuin terminologinen: varmistus koskee virheiden ehkäisemistä, valvonta niiden havaitsemista.

Perinteisessä järjestelyssä, jossa erillinen tiimi testaa valmiin työn erillisessä vaiheessa ennen julkaisua, on hyvin dokumentoituja heikkouksia. Vikoja löydetään kauan niiden ilmaantumisen jälkeen, kun konteksti on unohtunut ja korjaamisen kustannukset ovat korkeimmat. Kirjoittamisen ja testauksen välinen viive tarkoittaa, että kehittäjät eivät saa oikea-aikaista palautetta omista virhemalleistaan. Ja vastuu laadusta siirtyy ryhmälle, jolla ei ole määräysvaltaa työn tuottamiseen.

Nykyaikainen käytäntö jakaa vastuuta keskittämisen sijaan. Kehittäjät kirjoittavat automatisoituja testejä osana testausprosessia, koodin tarkistus havaitsee ongelmat ennen kuin ne pääsevät mihinkään ympäristöön, jatkuva integraatio suorittaa verifioinnin jokaiselle muutokselle ja laatuasiantuntijat keskittyvät testausstrategiaan, tutkivaan testaukseen ja alueisiin, joille automaatio ei yllä. Asiantuntijan roolista tulee verifioinnin mahdollistaminen ja suunnittelu sen sijaan, että hän suorittaisi sen kokonaan.

Testipyramidi kuvaa automatisoidun varmennuksen järkevää jakautumista. Laaja joukko yksikkötestejä suoritetaan nopeasti ja paikantaa virheet tarkasti. Pienempi integraatiotestien kerros varmistaa komponenttien toimivuuden yhdessä. Kapea päällimmäinen kerros, joka koostuu kokonaisista testeistä, suorittaa kokonaisia ​​​​testausmatkoja todellisen järjestelmän läpi. Tämän kääntäminen päinvastaiseksi, jossa nojataan voimakkaasti hitaisiin ja hauraisiin päällimmäisiin testeihin, tuottaa testejä, joiden suorittaminen kestää tuntikausia, jotka epäonnistuvat arvaamattomasti ja lopulta ohitetaan.

Tutkiva testaus on edelleen olennaista ja sitä usein aliarvostetaan automaatioon keskittyvissä organisaatioissa. Automatisoidut testit varmistavat, että tietty toiminta toimii edelleen; ne eivät voi havaita, että työnkulku on hämmentävä, että virheilmoitus on hyödytön, että kukaan ei ole harkinnut yhdistelmää, joka tuottaa järjettömiä tuloksia, tai että muutos on pahentanut jotakin tavalla, jota mikään väittämä ei kata. Taitava manuaalinen tutkimus löytää ongelmakategorioita, joita mikään testipaketti ei pysty havaitsemaan.

Laatuvelvoitteet ulottuvat paljon toiminnallista oikeellisuutta pidemmälle. Saavutettavuus, suorituskyky realistisissa olosuhteissa, turvallisuus, käyttäytyminen yleisön tosiasiallisesti käyttämillä laitteilla ja yhteyksillä sekä tiedonkäsittelyn oikeellisuus ovat kaikki laatuominaisuuksia, ja organisaatiot, jotka tarkistavat vain toiminnallisen toiminnan, toimittavat tuotteita, jotka toimivat oikein, mutta jotka epäonnistuvat merkittävässä osassa yleisöään.

Testiaineiston hallinta on epämääräinen rajoite, joka määrittää, kuinka paljon tästä on käytännössä saavutettavissa. Realistinen data on välttämätöntä realististen vikojen löytämiseksi, kun taas tuotantodataa ei usein voida käyttää suoraan yksityisyyden suojaan liittyvien velvoitteiden vuoksi, ja liian puhdas synteettinen data peittää juuri ne ongelmat, jotka kannattaa löytää. Edustavan ja vaatimustenmukaisen testidatan tarjonnan luominen on yleensä edellytys merkitykselliselle todentamiselle eikä niinkään yksityiskohta.

Ennaltaehkäisyn taloudellinen perustelu on vakiintunut. Vian korjaamisen kustannukset nousevat jyrkästi sen mukaan, kuinka myöhään se havaitaan. Vika havaitaan merkityksettömästi kehitysvaiheessa, mutta se on huomattava tuotannossa, jolloin sillä on myös operatiivisia ja mainekustannuksia. Investoinnit varhaisempaan havaitsemiseen ovat siksi perusteltuja pelkästään kustannussyistä, riippumatta asiakaskokemusargumentista.

Koska laatu määräytyy sen mukaan, miten työ tuotetaan, eikä sen mukaan, mitä lopussa tapahtuu, käytännöt kuuluvat toimitukseen eikä sen jälkeen. Käytännössä tämä määräytyy jo työn sisällä. tuotekehitys osana valmiin määritelmää, jossa saavutettavuus- ja kokemuskriteerit on johdettu UX-tarkastus standardit ja suorituskykykynnykset verkkosuorituskyky budjetit, jotta varmennettu vastaa sitä, mitä tuotteen todellisuudessa edellytetään toimittavan.