Mitä ketterä testaus on? Prosessi ja elinkaari

Mitä ketterä testaus on?

Ketterä testaus on ketterän ohjelmistokehityksen sääntöjä ja periaatteita noudattava testauskäytäntö. Toisin kuin Waterfall-menetelmässä, ketterä testaus voidaan aloittaa projektin alussa jatkuvalla integraatiolla kehityksen ja testauksen välillä. Ketterä testausmenetelmä ei ole peräkkäinen (sillä mielessä se suoritetaan vasta koodausvaiheen jälkeen), vaan jatkuva.

Ketterän testauksen periaatteet

Tässä ovat ketterän testauksen keskeiset periaatteet:

• Tässä ketterässä testausmallissa toimiva ohjelmisto on ensisijainen edistymisen mitta.
• Parhaan tuloksen saavuttavat itseorganisoituvat tiimit.
• Arvokkaiden ohjelmistojen varhainen ja jatkuva toimittaminen on tärkein prioriteettimme.
• Ohjelmistokehittäjien on toimittava kokoontuakseen päivittäin koko projektin ajan.
• Ketteryyden lisääminen jatkuvalla teknisellä parannuksella ja hyvällä suunnittelulla.
• Ketterä testaus varmistaa, että lopputuote vastaa yrityksen odotuksia antamalla jatkuvaa palautetta.
• Agile Test -prosessissa meidän on suoritettava testausprosessi toteutuksen aikana, mikä vähentää kehitysaikaa.
• Agile-testausprosessin tulisi toimia johdonmukaisella kehitysvauhdilla
• Pohdi säännöllisesti, kuinka tehostaa.
• Parhaat arkkitehtuurit, vaatimukset ja mallit syntyvät itseorganisoituvien tiimien avulla.
• Joka kerta kun tiimi kokoontuu, se tarkistaa ja muuttaa käyttäytymistään tehostaakseen toimintaansa.
• Kasvotusten keskustelu kehitystiimin kanssa on tehokkain ja tehokkain tapa välittää tietoa tiimin sisällä.

Ketterä testaus sisältää erilaisia ​​periaatteita, jotka auttavat meitä lisäämään ohjelmiston tuottavuutta.

Ketterän testauksen elinkaari

Ketterän testauksen elinkaari päättyy viidessä eri vaiheessa, kuten seuraavasta kuvasta näkyy:

Tässä ovat ketterän prosessin testausvaiheet:

Vaihe 1: Vaikutusten arviointi: Tässä alkuvaiheessa keräämme palautetta sidosryhmiltä ja käyttäjiltä. Tätä vaihetta kutsutaan myös palautevaiheeksi, koska se auttaa testausinsinöörejä asettamaan tavoitteita seuraavalle elinkaarelle.

Vaihe 2: Ketterä testaussuunnittelu: Se on ketterän testauksen elinkaaren toinen vaihe, jossa kaikki sidosryhmät kokoontuvat suunnittelemaan testausprosessin aikataulua ja suorituksia.

Vaihe 3: Julkaisuvalmius: Tässä vaiheessa tarkastelemme kehitetyt/toteutetut ominaisuudet, ovatko ne valmiita julkaistavaksi vai eivät. Tässä vaiheessa myös päätetään, kumman pitää palata edelliseen kehitysvaiheeseen.

Vaihe 4: Päivittäiset scrummit: Tämä vaihe sisältää jokaisen standup-aamukokouksen, jossa seurataan testauksen tilaa ja asetetaan tavoite koko päivälle.

Vaihe 5: Testaa ketteryyttä Reveli: Agilen elinkaaren viimeinen vaihe on Agility Revew Kokous. Se sisältää viikoittaisia ​​tapaamisia sidosryhmien kanssa arvioidakseen säännöllisesti edistymistä tavoitteiden suhteen.

Ketterä testisuunnitelma

Ketterä testisuunnitelma sisältää tässä iteraatiossa tehdyt testaustyypit, kuten testitietovaatimukset, infrastruktuurin, testiympäristötja testitulokset. Toisin kuin vesiputousmallissa, ketterässä mallissa testisuunnitelma kirjoitetaan ja päivitetään jokaiselle julkaisulle. Tyypillisiä testisuunnitelmia ketterissä ovat

• Testausalue
• Uusia toimintoja, joita testataan
• Testaustaso tai -tyypit ominaisuuksien monimutkaisuuden perusteella
• Kuormitus- ja suorituskykytestaus
• Infrastruktuurin huomioiminen
• Lieventämis- tai riskisuunnitelma
• resursointi
• Toimitukset ja virstanpylväät

Ketterät testausstrategiat

Ketterän testauksen elinkaari kattaa neljä vaihetta

Iteraatio 0

Ensimmäisen vaiheen tai iteroinnin 0 aikana suoritat alkuasetustehtävät. Se sisältää ihmisten tunnistamisen testausta varten, testaustyökalujen asentamisen, resurssien ajoituksen (käytettävyyden testauslaboratorio) jne. Seuraavat vaiheet on asetettu suoritettavaksi Iteraatiossa 0

• Liiketoiminnan perustelu hankkeelle
• Määritä rajaehdot ja projektin laajuus
• Esittele tärkeimmät vaatimukset ja käyttötapaukset, jotka ohjaavat suunnittelun kompromisseja
• Piirrä yksi tai useampi ehdokasarkkitehtuuri
• Riskin tunnistaminen
• Kustannusarvio ja esiprojektin valmistelu

Rakentamisen iteraatiot

Ketterän testausmetodologian toinen vaihe on Construction Iterations, suurin osa testauksesta tapahtuu tässä vaiheessa. Tätä vaihetta havaitaan iteraatioiden sarjana ratkaisun lisäyksen rakentamiseksi. Tämän tekemiseksi jokaisen iteroinnin aikana tiimi toteuttaa XP:n, Scrumin, ketterän mallinnuksen ja ketterän datan käytäntöjen hybridi.

Rakennusiteraatiossa ketterä tiimi noudattaa priorisoitua vaatimuskäytäntöä: Jokaisella iteraatiolla otetaan talteen tärkeimmät jäljellä olevat vaatimukset ja toteutetaan ne.

Rakennusiteraatio luokitellaan kahteen osaan, vahvistavaan testaukseen ja tutkivaan testaukseen. Vahvistavat testaustiivisteet varmistaakseen, että järjestelmä täyttää sidosryhmien tarkoitukset, jotka on kuvattu tiimille tähän mennessä, ja että tiimi suorittaa sen. Vaikka tutkiva testaus havaitsee ongelman, jonka vahvistusryhmä on ohittanut tai jättänyt huomiotta. Tutkivassa testauksessa testaaja määrittää mahdolliset ongelmat vikatarinoiden muodossa. Tutkiva testaus käsittelee yleisiä ongelmia, kuten integraatiotestausta, kuormitus-/rasitustestausta ja tietoturvatestausta.

Jälleen varmistustestauksessa on kaksi näkökohtaa kehittäjien testaus ja ketterä hyväksyntätestaus. Molemmat heistä ovat automatisoituja mahdollistamaan jatkuvan regressiotestauksen koko elinkaaren ajan. Varmistustestaus on ketterä vastine spesifikaatioiden mukaiselle testaukselle.

Ketterä hyväksyntätestaus on yhdistelmä perinteistä toiminnallista testausta ja perinteistä hyväksymistestausta kehitystiiminä, ja sidosryhmät tekevät sitä yhdessä. Kehittäjätestaus on sekoitus perinteistä yksikkötestausta ja perinteistä palveluintegraatiotestausta. Kehittäjätestaus varmistaa sekä sovelluskoodin että tietokantaskeeman.

Päätä peli tai siirtymävaihe

"Release, End Game" -ohjelman tavoitteena on ottaa järjestelmäsi käyttöön onnistuneesti tuotantoon. Tämän vaiheen toimintoja ovat loppukäyttäjien koulutus, tukihenkilöt ja operatiiviset henkilöt. Se sisältää myös tuotteen julkaisun markkinoinnin, varmuuskopioinnin ja palautuksen sekä järjestelmä- ja käyttäjädokumentaation viimeistelyn.

Viimeinen ketterän menetelmän testausvaihe sisältää täyden järjestelmätestauksen ja hyväksymistestauksen. Jotta lopputestausvaihe saadaan päätökseen ilman esteitä, sinun on testattava tuotetta tiukemmin, kun se on rakentamisen iteraatioissa. Loppupelin aikana testaajat työskentelevät sen vikatarinoiden parissa.

Tuotanto

Julkaisuvaiheen jälkeen tuote siirtyy tuotantovaiheeseen.

Ketterät testauskvadrantit

Ketterät testauskvadrantit erottavat koko prosessin neljään kvadranttiin ja auttavat ymmärtämään, kuinka ketterä testaus suoritetaan.

Ketterä kvadrantti I

Sisäisen koodin laatu on pääpaino tässä neljänneksessä, ja se koostuu teknologialähtöisistä testitapauksista, jotka on toteutettu tukemaan tiimiä.

• Yksikkötestit
• Komponenttitestit

Ketterä Quadrant II

Se sisältää yrityslähtöisiä testitapauksia, jotka on toteutettu tukemaan tiimiä. Tämä kvadrantti keskittyy vaatimuksiin. Tässä vaiheessa suoritettava testi on

• Mahdollisten skenaarioiden ja työnkulkujen esimerkkien testaus
• Käyttäjäkokemuksen, kuten prototyyppien, testaus
• Paritestaus

Ketterä Quadrant III

Tämä kvadrantti antaa palautetta kvadranteille yksi ja kaksi. Testitapauksia voidaan käyttää pohjana automaatiotestaukseen. Tässä kvadrantissa suoritetaan useita iteraatiotarkistuksia, jotka lisäävät luottamusta tuotteeseen. Tässä kvadrantissa suoritettavat testit ovat

• Käytettävyystestaus
• Tutkiva testaus
• Paritestaus asiakkaiden kanssa
• Yhteistyön testaus
• Käyttäjien hyväksyntätestaus

Ketterä Quadrant IV

Tämä kvadrantti keskittyy ei-toiminnallisiin vaatimuksiin, kuten suorituskykyyn, turvallisuuteen, vakauteen jne. Tämän neljänneksen avulla sovellus tehdään ei-toiminnallisten ominaisuuksien ja odotetun arvon tarjoamiseen.

• Ei-toiminnalliset testit, kuten stressi- ja suorituskykytestit
• Tietoturvatestaus suhteessa autentikointi ja hakkerointi
• Infrastruktuurin testaus
• Tietojen siirron testaus
• Skaalautuvuuden testaus
• Kuormitustestaus

QA haasteita ketterän ohjelmistokehityksen kanssa

• Virhemahdollisuudet ovat ketterämpiä, koska dokumentaatiolle annetaan vähemmän prioriteettia, mikä lisää lopulta painetta laadunvarmistustiimille
• Uudet ominaisuudet otetaan käyttöön nopeasti, mikä vähentää testitiimien käytettävissä olevaa aikaa selvittää, ovatko uusimmat ominaisuudet vaatimusten mukaisia ​​ja vastaako se todella yrityspukuja
• Testaajilta vaaditaan usein puolikehittäjän roolia
• Testin suoritussyklit ovat erittäin pakatut
• Hyvin vähemmän aikaa testisuunnitelman laatimiseen
• Regressiotestauksessa niillä on minimaalinen ajoitus
• Muutos heidän roolissaan laadun portinvartijasta laatukumppaniksi
• Vaatimusmuutokset ja päivitykset kuuluvat ketterään menetelmään, ja niistä on tulossa laadunvarmistuksen suurin haaste

Ketterän prosessin automatisoinnin riski

• Automaattinen käyttöliittymä tarjoaa korkean luottamustason, mutta ne ovat hitaita toteuttaa, hauraita ylläpitää ja kalliita rakentaa. Automatisointi ei välttämättä paranna merkittävästi testien tuottavuutta, elleivät testaajat osaa testata
• Epäluotettavat testit ovat suuri huolenaihe automaattisessa testauksessa. Epäonnistuneiden testien korjaamisen ja hauraisiin testeihin liittyvien ongelmien ratkaisemisen tulisi olla etusijalla väärien positiivisten tulosten välttämiseksi
• Jos automaattinen testi käynnistetään manuaalisesti CI:n (Continuous Integration) sijaan, on olemassa vaara, että niitä ei suoriteta säännöllisesti ja siksi testit epäonnistuvat.
• Automaattiset testit eivät korvaa tutkivaa manuaalista testausta. Tuotteen odotetun laadun saavuttamiseksi vaaditaan testityyppien ja -tasojen yhdistelmä
• Monet kaupallisesti saatavilla olevat automaatiotyökalut tarjoavat yksinkertaisia ​​ominaisuuksia, kuten manuaalisten testitapausten sieppauksen ja toistamisen automatisoinnin. Tällainen työkalu kannustaa testaamaan käyttöliittymän kautta ja johtaa luonnostaan ​​hauraisiin ja vaikeasti ylläpidettäviin testeihin. Myös testitapausten tallentaminen versionhallintajärjestelmän ulkopuolelle luo tarpeetonta monimutkaisuutta
• Ajan säästämiseksi automaatiotestisuunnitelma on usein huonosti suunniteltu tai suunnittelematon, minkä seurauksena testi epäonnistuu
• Testaus- ja purkumenettelyt jäävät yleensä väliin testiautomaation aikana, kun taas manuaalisen testauksen suorittaminen, testin asennus ja purkaminen kuulostaa saumattomalta
• Tuottavuusmittarit, kuten päivittäin luotujen tai suoritettujen testitapausten määrä, voivat olla hirveän harhaanjohtavia ja voivat johtaa suuriin investointeihin turhien testien suorittamiseen.
• Ketterän automaatiotiimin jäsenten on oltava tehokkaita konsultteja: helposti lähestyttäviä, yhteistyöhaluisia ja kekseliäitä, tai tämä järjestelmä epäonnistuu nopeasti
• Automaatio voi ehdottaa ja toimittaa testausratkaisuja, jotka vaativat liian paljon jatkuvaa ylläpitoa suhteessa tarjottuun arvoon
• Automaattisesta testauksesta voi puuttua asiantuntemusta tehokkaiden ratkaisujen suunnitteluun ja toimittamiseen
• Automaattinen testaus voi olla niin onnistunut, että tärkeät ongelmat loppuvat ratkaistaviksi ja muuttuvat siten merkityksettömiksi ongelmiksi.

Yhteenveto

Ketterä menetelmä ohjelmistotestauksessa sisältää testauksen mahdollisimman varhaisessa vaiheessa ohjelmistokehityksen elinkaari. Se vaatii suurta asiakkaiden osallistumista ja testauskoodia heti, kun se tulee saataville. Koodin tulee olla riittävän vakaa, jotta se voidaan viedä järjestelmätestaukseen. Laajalla regressiotestauksella voidaan varmistaa, että virheet on korjattu ja testattu. Pääasiassa tiimien välinen kommunikaatio tekee ketterästä mallitestauksesta menestystä!!!