täydellisen tuotteen esitteleminen asiakkaalle on jokaisen organisaation päätavoite. Mutta tiesitkö, että oli aika, jolloin testaus ei ollut edes osa ohjelmistokehityksen elinkaarta (SDLC)?

mikään ei rasita asiakkaita enemmän kuin bugien täyttämä käyttökokemus. Kun yritykset tajusivat tämän, ne alkoivat sisällyttää testauksen pakolliseksi osaksi SDLC: tä. Sen jälkeen testauksesta on tullut olennainen osa jokaista organisaatiota.

testauksen osaaminen on kehittynyt viime vuosikymmeninä. Tällä hetkellä testauksessa ei ole kyse vikailmoituksesta kehittäjälle. Sen soveltamisala on laaja, ja se on pakollinen vaihe, joka on toteutettava projektin alkuvaiheista alkaen.

ketterän myötä sovelluksen testauksen elinkaari muuttui prosessipainotteisemmaksi ja monipuolisemmaksi. Yleensä yrityksen koko painopiste on pelkästään SDLC: ssä. He harkitsevat testaamista osana sitä prosessia. Mutta yritysten on korkea aika ymmärtää, että ohjelmistotestauksella on oma elinkaarensa.

tässä viestissä käydään yksityiskohtaisesti läpi ohjelmistotestauksen elämäntyyliä (stlc) ja sen vaiheita. Joten sukelletaan suoraan asiaan!

mikä on ohjelmistojen testauksen elinkaari?

selvitetään ensin termi elinkaari ennen kuin päästään kaikkiin yksityiskohtiin. Elinkaari on muutosten sarja, jonka olio käy läpi muodosta toiseen. Monet konkreettiset ja hämärät kokonaisuudet käyvät läpi sarjan muutoksia alusta loppuun.

kun puhutaan ohjelmistojen elinkaarta testaavasta ohjelmistosta, ohjelmisto on kokonaisuus. Ohjelmistotestauksen elinkaari on prosessi, jossa suoritetaan erilaisia toimintoja testauksen aikana.

näihin toimintoihin kuuluu kehitetyn ohjelmiston tarkistaminen, täyttääkö se tietyt vaatimukset. Jos tuotteessa on vikoja, testaajat työskentelevät kehitystiimin kanssa. Joissakin tapauksissa heidän on otettava yhteyttä sidosryhmään saadakseen tietoa tuotteen eri ominaisuuksista. Tuotteen validointi ja todentaminen ovat myös STLC: n tärkeitä prosesseja.

SDLC vs. STLC

tuotteen koko matkasta sen alusta lopputuotteeksi asti huolehtii SDLC. SDLC: n eri vaiheiden joukossa testaus on yksi tärkeimmistä. Ohjelmistojen testaus on osa SDLC: tä. Ja tämä osa on saanut oman elinkaaren-STLC.

miten SDLC eroaa STLC: stä?

SDLC

• Focus on building a product
• a parent process
• Understanding user requirement and building a product that is helping to users
• SDLC phases are completed before testing
• End goal is to deploy a high quality product that users can use

STLC

• Focus on testing a product
• a Child of SDLC process
• understanding development requirements and ensure the product is working as expected
• stlc phases start after phases of SDLC are completed
• end goal is to find bugs in product and report bug fix

nämä ovat peruseroja SDLC: n ja STLC: n välillä. Nyt, Katsotaanpa ymmärtää STLC perusteellisesti.

mikä on STLC: n rooli?

nyt kun meillä on ydin siitä, mikä on ohjelmistojen testauksen elinkaari, katsotaan, miksi se on välttämätöntä. Vaikka yrityksellä olisi parhaat ohjelmoijat ja kehittäjät, he tekevät väistämättä virheitä. STLC: n tärkein tehtävä on löytää ne virheet ja saada ne korjatuiksi. STLC: n johtamisen päätavoitteena on säilyttää tuotteen laatu.

ovat ne ajat, jolloin keskinkertainen testaus oli trendi. Nykymaailmassa yritysten on tehtävä yksityiskohtaisia testejä.

suunnittelusta ja tutkimuksesta toteutukseen ja ylläpitoon jokaisella vaiheella on ratkaiseva merkitys tuotteen testaamisessa.

SDLC: ssä on kyse tuotteen laadun varmistamisesta. Jokaisella sovelluksella on erilaisia ominaisuuksia, kuten luotettavuus, toimivuus ja suorituskyky. Ja STLC auttaa parantamaan näitä ominaisuuksia ja helpottaa ihanteellisen lopputuotteen toimittamista.

laadukas tuote johtaa pidemmällä aikavälillä alhaisempiin ylläpitokustannuksiin. Sovelluksen tai ohjelmiston vakaus on välttämätöntä uusien käyttäjien houkuttelemiseksi. Sen lisäksi, että johdonmukaisesti luotettavia tuotteita myös auttaa pitämään olemassa asiakaskunta. Jotta tuote pysyy liiketoiminnan valtakunnassa, on tärkeää keskittyä STLC: n jokaiseen vaiheeseen.

ohjelmistotestauksen elinkaaren vaiheet

jokaisen ohjelmiston tai sovelluksen moduulin validointi on välttämätöntä tuotteen tarkkuuden ja tarkkuuden varmistamiseksi. Koska ohjelmistojen testaus itsessään on monimutkainen prosessi, testaajat suorittavat sen vaiheittain. Monimutkaisuutta voi ilmaantua, jos testauksesta puuttuu organisaatio. Monimutkaisuuksiin voi kuulua ratkaisemattomia vikoja, havaitsemattomia regressiovirheitä tai pahimmassa tapauksessa moduuli, joka jätti testauksen väliin, koska määräaika läheni.

STLC: n jokaisella vaiheella on tietty tavoite ja suoritukset. Siihen kuuluu testausprosessin aloittaminen, suorittaminen ja lopettaminen.

Tarkastellaanpa ohjelmistotestauksen elinkaaren eri vaiheita yksityiskohtaisesti.

Vaatimusanalyysi

arvokkaiden ohjelmistotestaajien on katsottava, tutkittava ja analysoitava käytettävissä olevia spesifikaatioita ja vaatimuksia. Tietyt vaatimukset tuottavat tuloksia syöttämällä niihin syöttötietoja. Nämä vaatimukset ovat testattavia vaatimuksia. Testaajat tutkivat sekä toiminnallisia että ei-toiminnallisia vaatimuksia. Sen jälkeen heidän on valittava testattavat vaatimukset.

tämän vaiheen toimiin kuuluu aivoriihi vaatimusanalyysia varten sekä testivaatimusten tunnistaminen ja priorisointi. Niihin kuuluu myös sekä automatisoidun että manuaalisen testauksen vaatimusten poiminta.

on muutamia asioita, joita olet testannut, vaikka niitä ei olisi erikseen mainittu. Napsauttamalla aktiivista painiketta pitäisi tehdä jotain, tekstikenttä puhelinnumeron pitäisi hyväksyä aakkoset lähetetty. Nämä asiat ovat yleismaailmallisia ja niitä pitäisi aina testata. Mutta vaatimusanalyysivaiheessa se tietää tarkempia yksityiskohtia tuotteesta. Sinun täytyy oppia, miten tuotteen pitäisi olla ihanteellisessa tilassaan.

yhteenvetona:

• ymmärrä odotettu tuotos tuotteesta.
• tunnista eritelmien mahdolliset porsaanreiät.
• kerää prioriteetit.
• Suorita automaation toteutettavuustarkistuksia.

Testisuunnittelu

toinen vaihe on testisuunnittelu, ja LAADUNVARMISTUSRYHMÄ luo tämän suunnitelman analysoituaan kaikki tarvittavat testausvaatimukset. Ne hahmottelevat soveltamisalan ja tavoitteet tuotealueen ymmärtämisen jälkeen. Tämän jälkeen tiimi analysoi riskit ja määrittelee aikataulut ja testausympäristöt strategian luomiseksi.

sen jälkeen johto viimeistelee työkalut ja antaa tehtävät ja vastuut yksilöille. Lisäksi määritellään likimääräinen aikajana, jonka mukaan kunkin moduulin testaus tulee suorittaa.

yhteenvetona:

• valmistele testaussuunnitelman asiakirjat.
• arvioi aikaa ja pyrkimyksiä.
• Viimeistele työkaluilla ja alustalla.
• antaa tehtäviä joukkueille ja yksilöille.
• tunnista koulutusvaatimukset

Testitapauksen suunnittelu ja kehittäminen

kehittämisen ja suunnittelun jälkeen on aika antaa luovien mehujen virrata! Testaajat suunnittelevat ja kehittävät testitapauksia testisuunnitelman pohjalta. Testitapausten tulisi olla laajoja, ja niiden tulisi kattaa lähes kaikki mahdolliset tapaukset. Kaikki sovellettavat permutaatiot ja yhdistelmät olisi koottava. Voit priorisoida näitä testitapauksia tutkimalla, mitkä niistä ovat yleisimpiä tai mitkä niistä vaikuttaisivat tuotteeseen eniten.

seuraavaksi tulee dokumentointivaiheessa määriteltyjen vaatimusten todentaminen ja vahvistaminen. Myös automaatio-skriptien ja testitapausten tarkistaminen, päivittäminen ja hyväksyminen ovat tämän vaiheen olennaisia prosesseja. Tähän vaiheeseen kuuluu myös erilaisten testiolosuhteiden määrittely syöttötiedoin ja odotetuin tuloksin.

tiivistäen:

• Tutki ja kerää mahdolliset toimenpiteet tuotteeseen.
• luo koetapauksia.
• priorisoi testitapaukset.
• valmistele automaattiset skriptit testitapauksia varten.

testiympäristön Asetukset

testaustoimintaan tarvitaan tiettyjä ympäristötekijöitä—kuten palvelimia, kehyksiä, laitteistoja ja ohjelmistoja—kehitettyjen testitapausten suorittamiseen. Ohjelmisto-ja laitteistokokoonpanot sekä testitietojen asetukset ovat tämän vaiheen pääkomponentteja. Ja on pakollista tupakoida testi ja varustaa testaajat vikailmoitustyökaluilla.

kehittäjäyhteisössä on tavallista kuulla ”it ran on my system, but it ’s not running on yours”. Siksi on tärkeää, että testiympäristösi kattaa kaikki käyttäjän käyttämät ympäristöt.

esimerkiksi jokin Google Chromessa toimiva ominaisuus ei toimi Internet Explorerissa. Ominaisuuksien toimivuus vaihtelee myös ohjelmisto-ja laitteistovaatimusten perusteella. Ominaisuus saattaa toimia sujuvasti 4 GB RAM, mutta saattaa aiheuttaa ongelmia 1 GB RAM. Loppukäyttäjien käyttämien ympäristöjen tutkiminen auttaisi sinua priorisoimaan testiympäristösi.

tiimiä valvovan LAADUNVARMISTUSPÄÄLLIKÖN tehtävä on huolehtia testiympäristön asettamisesta.

yhteenvetona:

• ymmärrä minimivaatimukset
• listaa alas eri suoritustasoihin vaadittavat ohjelmistot ja laitteistot.
• priorisoi testiympäristöt
• Setup testiympäristöt
• Savutesti rakennetut ympäristöt

testin suoritus

sovellus on valmis testattavaksi, kun tiimi on tehnyt kaikki aiemmat vaiheet. Testaussuunnitelman mukaan testaajat toteuttavat testitapauksia. He myös tunnistavat, havaitsevat ja kirjaavat viat ja ilmoittavat näin vioista. Tiimi vastaa myös odotettujen tulosten vertaamisesta todelliseen lopputulokseen. Jos vikoja löytyy, ne on dokumentoitava, jotta ne voidaan siirtää kehitystiimille korjattavaksi.

kun kehitystiimi poistaa vian, alkaa regressiotestaus. Regressiotestauksella pyritään varmistamaan, että ohjelmisto tai sovellus toimii myös muutoksen käyttöönoton jälkeen. Kun testaat vikakorjauksen jälkeen, testaa koko tuote uudelleen. Koska korjaus vialle voi luoda vian johonkin muuhun osaan tuotetta. Ja koska samat testit on suoritettava uudelleen ja uudelleen jokaisen korjauksen ja käyttöönoton jälkeen, on suositeltavaa käyttää komentosarjoja tai automatisoituja testaustyökaluja.

summaa:

• Juokse testitapaukset.
• tunnista poikkeama tuotteen odotetusta käyttäytymisestä.
• Loki epäonnistui tapauksissa, joissa yksityiskohdat
• testaa uudelleen virheenkorjausten jälkeen.

testin sulkeminen

ja siitä päästään STLC: testin viimeiseen vaiheeseen.

testin suorittamisen ja lopputuotteen toimituksen päättyminen merkitsee testin sulkemisvaiheen alkamista. QA-tiimi tarkistaa testitulokset ja keskustelee niistä muiden tiimin jäsenten kanssa. Joitakin muita tekijöitä he pitävät tuotteen laatu, testi kattavuus, ja projektin kustannukset. Jos estimoiduista arvoista on poikettu, voidaan tehdä lisäanalyysejä, jotta voidaan tunnistaa, mikä ei mennyt odotetusti.

on olennainen käytäntö, että testaajat kokoontuvat keskustelemaan lopputuloksesta testauksen jälkeen. Kaikista testauksen aikana kohdatuista ongelmista, strategioiden puutteista voidaan keskustella täällä. Voit myös työstää parempaa lähestymistapaa testaukseen testauksen aikana saatujen oppien perusteella. Jos noudatat DevOps tai canary release practice, testaus on usein. Voit päättää, kuinka usein raportteja lähetetään ja mitä yksityiskohtia on mainittava, kun lähetät raportteja eri sidosryhmille.

sen lisäksi työryhmä pohtii myös testimittareita, tavoitteiden täyttymistä ja määräaikojen noudattamista. Kun heillä on täydellinen käsitys siitä, mitä tapahtui, he voivat arvioida koko testausstrategian ja prosessin.

yhteenvetona:

• Tarkista, että kaikki testit on tehty.
• arvioi sellaisia tekijöitä kuin laatu, testin kattavuus, Aikajana ja kustannukset.
• dokumentoi johtopäätös.
• Keskustele oppimisesta ja selvitä, voiko testausta parantaa.
• valmistele testin sulkemisraportti.

mitkä ovat testauksen sisään-ja Poistumiskriteerit?

kaikissa ohjelmatestauksen elinkaaren kuudessa vaiheessa on liittymis-tai poistumiskriteerit. Testaajien on suoritettava testitapaukset määräajassa. Lisäksi niiden on säilytettävä lopputuotteen laatu, toimivuus ja tehokkuus. Siksi on välttämätöntä määritellä maahantulo-ja maastapoistumiskriteerit. Niin me teemme nyt.

osallistumiskriteerit

Osallistumiskriteereissä kerrotaan, mitkä vaatimukset ryhmän on hoidettava ennen testauksen aloittamista. Ennen testauksen aloittamista on pakko ylittää kaikki vaatimukset.

on joitakin käynnissä olevia toimintoja ja olosuhteita, joiden on oltava olemassa ennen testauksen aloittamista. Ensin tarvitaan kehitystiimin panosta. Sinun kannattaa myös tutkia testaussuunnitelma, testitapaukset ja-tiedot, testausympäristö ja koodi.

Exit Criteria

Exit criteria määrittelee vaatimukset ja toimet, jotka on suoritettava ennen testauksen päättymistä. Toisin sanoen ne sisältävät tehtäväluettelosta ylitettäviä kohteita ja prosesseja, jotka on suoritettava ennen kuin testaus pysähtyy.

Poistumiskriteereihin kuuluu tärkeiden vikojen tunnistaminen. Ne pitää korjata heti. Testaajien on läpäistävä erilaisia testitapauksia ja varmistettava täysi toiminnallinen kattavuus.

johtopäätös

pelkkä SDLC: n viimeisen vaiheen virheiden tunnistaminen ei ole enää tehokas käytäntö. On olemassa useita muita päivittäisiä toimintoja yrityksen on keskityttävä. Jos käytät liikaa arvokasta aikaasi vikojen testaamiseen ja korjaamiseen, se voi haitata tehokkuutta. Loppujen lopuksi otat enemmän aikaa tuottaa vähemmän tuotantoa.

testauksen helpottamiseksi on tärkeää käyttää aikaa ja resursseja tehokkaasti. Seuraavat systemaattinen STLC ei vain johtaa nopeasti vika vahvistamisesta, mutta se myös parantaa tuotteen laatua. Lisäämällä asiakastyytyväisyyttä voit nauttia kasvaneesta sijoitetun pääoman tuotosta ja paremmasta brändin läsnäolosta.

tämän postauksen kirjoitti Arnab Roy Chowdhury. Arnab on ammatiltaan käyttöliittymien kehittäjä ja bloggaamisen harrastaja. Hänellä on vahva asiantuntemus uusimmista UI / UX-trendeistä, projektimenetelmistä, testauksesta ja käsikirjoittamisesta.

mitä seuraavaksi

mikä on vaihto vasemmalle-testaus? A Guide to Improving Your QA