Vika elinkaari - Kuten jo nyt tiedät, testin suorittaminen on vaihe, jossa testaaja tosiasiallisesti suorittaa testiskriptit. Testikomentosarjojen suorittamisprosessi vaihtelee yrityksittäin ja saattaa olla erilainen myös saman yrityksen erilaisissa projekteissa.
Nyt päivinä on saatavana työkaluja testien suorittamiseen, työkaluja, kuten - Quality Center, Microsoft Visual Studio ja niin edelleen. Kunkin vaiheen suorittamisen todellinen toteutusprosessi todellisen ja odotetun tuloksen vertaamiseksi pysyy samana toiminnalliselle testaajalle käytetyistä työkaluista riippumatta.
- Entä jos todellinen käyttäytyminen ei ole yhtä kuin odotettu käyttäytyminen?
Kun testaaja havaitsee, että todellinen testitulos ei ole sama kuin odotettu tulos, virhe kirjataan.
- Kuinka vika kirjataan?
Nykyään on saatavana useita työkaluja päivien ajan. Jotkut vikojen kirjaamistyökaluista ovat IBM: n ClearQuest, HP: n Quality Center, avoimen lähdekoodin työkalut, kuten virheiden elinkaari JIRAssa ja niin edelleen.
Jotkut pakollisista kentistä ovat yhteisiä kaikille viankeruutyökaluille, nämä kentät ovat -
- Viallisen elinkaaren kuvaus
- Viallisen elinkaaren yhteenveto
- Vika kirjautunut
- Vika on osoitettu
- Vian vakavuus
- Vian prioriteetti
- Lisäkuvat
- Julkaisun numero / nimi
Viallinen elinkaari
Vian elinkaari alkaa uuden vian kirjaamisesta. Aina kun vika kirjataan, se menee “uuteen” tilaan.
Testeri - Uusi vika
Kenelle uusi vika määritetään?
Testeri voi antaa vian kehittäjälle tai kehitysjohdolle. Tämä vianmäärityspäätös vaihtelee projektikohtaisesti. Joillakin työpaikoilla on vika elinkaariprosessissa sen osoittamiseksi suoraan vastaavalle kehittäjälle, ja joissain paikoissa vika osoitetaan ensin dev-johdolle ja dev-johto puolestaan osoittaa sen kehittäjälle.
Vianmääritys (uusi) - viallisen elinkaaren kehittäjä
Vianmääritys (uusi) - Dev Leadà -kehittäjä
Vianmääritys
Kehittäjä analysoi vian tarkistaakseen, onko se toistettavissa. Testaajan tärkein panos on tässä, että kaikki tarvittavat yksityiskohdat sisällytetään vikaan. Vikayhteenveto, vian yksityiskohtainen kuvaus ovat kentät, jotka auttavat sidosryhmiä ymmärtämään vika yhdellä kertaa. Vikayhteenvedossa tulisi aina olla vain korkeat tiedot vikasta. Samalla sillä tulisi olla riittävästi tietoa kuvaamaan yleistä virhettä yhdellä rivillä.
Vikakuvaus on paikka, jossa testaajan odotetaan sisältävän kaikki tarvittavat tiedot, kuten ympäristö, skenaario, käytetyt testitiedot, odotettu tulos, todellinen tulos, viittaus tiedostoihin / tietoihin ja viittaus tilannekuvaan.
Tässä on lyhyt kuvaus vian eri osista - Yksityiskohtainen kuvaus -
ympäristö
Testiympäristö, josta vika löytyi. Usein projekteilla on useita testiympäristöjä, joissa testitiimi suorittaa testauksen. Esimerkiksi - AT (kokoonpanon testausympäristö), PT (tuotteen testausympäristö), UAT (käyttäjän hyväksymä testausympäristö) ja niin edelleen. Erilaisten ympäristöjen tarkoituksena on, että se tarjoaa joustavuuden kehitys- ja testitiimissä, jotta koodi voidaan asentaa mihin tahansa käytettävissä olevaan ympäristöön testauksen aloittamiseksi ajoissa.
Toisinaan tuotetesti (jota kutsutaan myös järjestelmätesteiksi) ja UAT-testi ovat päällekkäisiä, joten testaamisen jatkamiseksi rinnakkain on pakko olla useita ympäristöjä.
Joissain tapauksissa kehitysryhmä tarvitsee lisäympäristön testausryhmän ilmoittamien ongelmien vianmääritykseen. Lisäksi kehitysryhmällä on oma ympäristö ympäristötestausta varten.
Siksi useissa ympäristöissä on puutteessa mainittava tietty ympäristö, josta aihe löytyi.
skenaario
Skenaario on testaaja suorittama vaiheiden sarja, joka johti virheeseen. Testaajan odotetaan mainitsevan kaikki vaiheet, jotka kehittäjä voi suorittaa vian toistamiseksi. Usein on aikoina, jolloin testaaja ilmoittaa virheestä, mutta kehittäjä ei pysty replikoimaan samaa, joten virhe hylätään. Tämä voi tapahtua kuvauksessa mainittujen väärien vaiheiden / puuttuvien vaiheiden takia. Selkeät vaiheet auttavat kaikkia ymmärtämään vian ja toistamaan sen ilman, että on riippuvaista tavoittaa testaaja testataksesi tuloja. Hyvin dokumentoidussa skenaariossa on helppo lukea, helppo ymmärtää ja tarkat vaiheet, joita on noudatettava virheen toistamiseksi.
Testitiedot
Testaajan on tarkoitus mainita tiedot, jotka käytettiin testivirran aikana, joka johti ongelmaan. Nämä tiedot antavat kehittäjälle mahdollisuuden käyttää samankaltaisia tietoja virheen toistamiseen ja saman syyn löytämiseen.
On joitain tilanteita, joissa testaaja löytää vian tietyn datan avulla, mutta samaa ongelmaa ei voida toistaa samanlaista dataa käyttämällä. Tämä voi tapahtua tietojen vioittumisen vuoksi, joten tietojen syöttäminen antaa mahdollisuuden selvittää vian perimmäinen syy. Kehittäjä ei ehkä kaivaa kooditasoa, jos kyse on tietojen vioittumisesta. Tällainen vika voidaan muuntaa tietovirheeksi.
Odotettu ja todellinen tulos
Tämä on yksityiskohtaisen kuvauskentän kohokohta, jossa testaaja todistaa havaitun virheen olevan todella vika. Odotetun tuloksen selkeä mainitseminen tekee asioista selkeän, että kaikki sidosryhmät pitävät virhettä virheenä. Kuvittele, että virhe on kirjautunut kaikkiin yksityiskohtiin, mutta se ei määrittele skenaarion odotettua lopputulosta!
Testaaja syöttää yleensä vain odotetun tuloksen, joka voi olla viivalla tai toisella, mutta on erittäin tärkeää mainita odotetun tuloksen lähde. Lähde tässä viittaus asiakirjaan, jossa odotettu tulos mainitaan. Tämä voi olla vaatimusasiakirja tai kuvakäsikirjan viite.
Viittaus tiedostoihin / tietoihin
Joskus vika liittyy tiedoston luomiseen tai syöttöön tiedostoina. Tällaisissa tilanteissa testaajan on tarkoitus antaa tietoja käytetystä tiedostosta, joka aiheutti ongelman sovelluksessa. Nämä tiedostot voidaan liittää vianhallintatyökalulla tai viittaus siihen voidaan antaa. Kaikkien sidosryhmien tulisi olla pääsy näihin vertailupaikkoihin.
Viittaus valokuviin
Valokuvissa on erittäin tärkeä rooli, kun haluat näyttää heille tarkan sivunvaihdosvirhesanoman näytöllä näkyvänä tai kun haluat näyttää näytön navigoinnin yksityiskohdat. Snapshot antaa nopean kuvan havaitusta vikasta, näytöstä, jolla vika löytyi, näytöllä käytetystä tiedosta ja niin edelleen. Jokaisessa vianhallintatyökalussa on mahdollisuus liittää kuvia. Joskus testaaja saattaa liittää myös Excel-laskentataulukoita tai tekstiasiakirjoja.
Nämä olivat vikojen kirjaamisen eri komponentteja ja parhaita käytäntöjä jokaiselle niistä. Palaavan vian elinkaareen, kun vika on osoitettu kehittäjälle, hän analysoi sen vikakohdassa annettujen tietojen avulla. Jos analyysin mukaan kirjattu ongelma on todellakin vika, kehittäjä "avaa" vian työskennelläkseen sen korjaamiseksi.
Suositellut kurssit
- Verkkopalvelut Java-koulutuspaketissa
- Pelien kehittämisen koulutus C ++: ssa
- Täydellinen eettisen hakkeroinnin koulutus
- Vegas Pro 13 -kursseja
Uusi - avoin
Vika avoimessa tilassa osoittaa, että se on kehityslevyllä ja kehittäjät työskentelevät sen korjaamiseksi. Jos analyysi toteaa, että kirjattu ongelma ei ole vika, tämä voi tapahtua, kun järjestelmän odotetussa käyttäytymisessä on ymmärrettäviä aukkoja. Jos analyysi kertoo, että vika on virheellinen, kehittäjä hylkää vian. Terminologia on ”Hylätty” tai “Palaa testaukseen”.
Uusi - Palaa testaukseen.
Kuinka testaaja tarkistaa, onko vika todella virheellinen?
Tässä tilanteessa tarkka vaatimusasiakirja auttaa kaikkia ryhmän jäseniä päättämään, onko kirjattu vika virheellinen tai pätevä. Vaatimusasiakirjoihin viittaaminen auttaa testaajaa ja kehittäjää pääsemään samaan johtopäätökseen, ja se todella helpottaa keskustelua.
On skenaarioita, joissa suunnittelu- ja vaatimusasiakirjojen oikeellisuus kyseenalaistetaan, kun viitataan näihin asiakirjoihin virhekeskustelujen aikoina, ja silloin takaisin Business Analyst -yritykseen katsotaan olevan paras vaihtoehto kyselyjen selventämiseksi.
Parhaan käytännön muodossa vaatimus- ja suunnitteludokumenttien tulisi olla aina ajan tasalla, jotta niihin voidaan viitata ilman epäselvyyksiä.
“Open” -tilassa kehitysryhmä pyrkii korjaamaan vian, kun vika on korjattu, tila muuttuu “Ready for Deployment” -valmiuteen.
Open - valmis käyttöönottoon
Käyttöönotto on prosessi, jossa muutokset ladataan palvelimelle, jotta testausryhmä voi työskennellä koodin kiinteän version kanssa. Yleensä jokaisella projektilla on erillinen käyttöönottoryhmä tätä tehtävää varten.
Joten korkealla tasolla ohjelmistotiimi koostuu pääasiassa näistä 3 ryhmästä -
- kehitys
- Vika elinkaaren aikana
- Käyttöönotto (tai joskus kutsutaan rakennustiimiksi)
Kun kokoonpano on otettu käyttöön ja vika on jälleen käytettävissä uudelleentestaukseen, se osoitetaan asianmukaiselle testaajalle uudelleentestaustehtävän suorittamiseksi.
Vika määritetty - testijohto.
Testijohto - yksittäinen testaaja.
Vika määritetty - yksittäinen testaaja.
Joillakin työpaikoilla vika osoitetaan ensin testijohdolle ja hän puolestaan osoittaa sen yksittäiselle testaajalle, mutta joissain paikoissa vika osoitetaan suoraan testaajalle, joka testaisi sitä, tai sille, joka oli aiheuttanut vian.
Tila muuttuu tässä vaiheessa valmista käyttöönottoon - Valmis SIT -testaus.
Nyt vika on testauslautasessa. Testausryhmä vahvistaa vian ja on 2 vaihtoehtoa, joko korjaus toimisi oikein tai sama ongelma kohdataan uudelleen. Tuloksesta riippuen vika voi siirtyä seuraaviin tiloihin -
Valmis SIT -testaus - suljettu
Valmis SIT -testaus - avaa uudelleen
Molemmissa yllä mainituissa tilanteissa testaaja on velvollinen lisäämään suoritetun testauksen kommentit. Tähän sisältyy testattujen skenaarioiden ja käytettyjen tietojen mainitseminen. Jos vika avataan uudelleen, testaajan tulee antaa tarkat suoritetut vaiheet, jotka taas johtivat virheeseen.
Avaa uudelleen tila on sama kuin ”uusi” vikatila.
Kun vika on avattu uudelleen, se seuraa samaa jaksoa uudelleen.
Viat elinkaaren haasteet
- Vian vakavuudesta päättäminen - tämä on yksi yleisimmistä keskusteluaiheista (usein taisteluista) testaajien v / s-kehittäjien keskuudessa.
- Vika ei ole toistettavissa kehittäjän järjestelmässä.
- Skenaariossa havaittu virhe, jota ei mainita vaatimuksissa ja suunnitteludokumenteissa.
- Vika löytyy, mutta sitä ei voida nostaa, koska skenaarion esiintyminen tuotantoympäristössä ei ole mahdollista.
Kuinka testaajan tulisi voittaa haasteiden yläpuolella?
- Vakavuus on suoraan verrannollinen vaikutukseen, jonka vika aiheuttaa sovellukselle, jos testaaja ei voi jatkaa vian takia, se on varmasti merkitty suurimmalla vakavuudella.
- Jos testin jatkamiseksi on olemassa kiertotapa, se on merkittävä keskipitkäksi. Sen lisäksi, että otetaan huomioon lisävian elinkaaritestauksen vaikutukset, vakavuudesta voidaan päättää myös tilanteessa, jossa koko moduuli on vikaantunut, tässä tapauksessa vaikka toisen moduulin testaus voidaan suorittaa, mutta vakavuus nykyiseen moduuliin on korkea joten vika on merkittävä erittäin vakavasti.
- Jos vikaa ei voida toistaa kehittäjän järjestelmässä, on mahdollista, että kehitys- ja testiympäristö eivät ole synkronoidut. Testausjärjestelmässä toistettavaa vikaa pidetään aina pätevänä virheenä.
- On tilanteita, joissa vika kirjataan yleisen liiketoimintaskenaarion perusteella, mutta suoraa skenaariota ei mainita vaatimuksissa tai suunnitteludokumentissa. Aina pidetään parhaana käytäntönä harkita todellisia liiketoimintaskenaarioita sen sijaan, että vain seurata testivaiheita. Kommunikoinnilla liike-elämän analyytikkojen ja muiden tuoteryhmien kanssa on tärkeä rooli tällaisten vikojen kirjaamisessa.
- On tilanteita, joissa testaaja havaitsee aukon liiketoimintalogiikassa testausvaiheen aikana. Tällaisten aukkojen löytämistä pidetään jälleen suurena plussaa testaajalle. Suunnitteluaukot hoidetaan yleensä parannusten avulla.
- Parannus - Jos käyttäytymistä on muutettava ohjelmiston elinkaaren testausvaiheen aikana, luodaan parannus, joka voidaan ottaa käyttöön nykyisessä tai seuraavassa julkaisussa ottaen huomioon kehitys- ja testitiimien aikataulut ja kaistanleveys.
- On joitain skenaarioita, joita testaaja voi testata ad-hoc -testauksen aikana. Ne voivat tosiasiassa olla virheellisiä skenaarioita ottaen huomioon niiden esiintymisen mahdollisuus tuotannossa.
Kuka on testaajan paras ystävä?
Mihin testaajan pitäisi mennä epäselvyyden vuoksi? Vastaus riippuu kyselyn tyypistä. Jos kysely koskee vaatimuksia, on suositeltavaa keskustella ensin ryhmässä, jotta järjestelmä voidaan ymmärtää oikein, kuulemalla vanhempia jäseniä. Seuraavan yhteyspisteen tulisi olla yritysanalyytikot.
Jos kysely koskee testausprosessia, on suositeltavaa ottaa yhteyttä testausjohtoon tai testipäällikköön.
Jos kysely koskee sovelluksen teknisten ominaisuuksien ymmärtämistä, kehitysryhmän jäsen voi olla oikea henkilö, johon mennä.
Koska testaus on prosessi, joka vaatii järjestelmän yleistä ymmärtämistä, viestintä auttaa testaajaa saamaan nopeaa vastausta kyselyihin, se riippuu vain oikeiden kysymysten esittämisestä oikeille henkilöille. Uhruus kysymyksiin esittämisestä oikeaan aikaan voi johtaa virheeseen, joka vuotaa tuotantoympäristöön.
Kuinka tärkeä testaajan rooli yrityksessä on nykyään?
On projekteja, joissa testausryhmä on yhtä tärkeä kuin kehitysryhmä, ja joissain tapauksissa riippuvuus on enemmän testiryhmästä kuin kehitysryhmästä. Myöhempi skenaario on harvinainen, mutta sitä on jo joillakin työpaikoilla. Tämä on tapahtunut ajan kuluessa ja saattaa olla tietyllä ajanjaksolla, jolloin kehitysryhmällä ei ole paljon kokemusta verrattuna testausryhmään. Jotkut ihmiset ymmärtävät yleisen virtauksen ja toiminnallisuuden paremmin kuin useimmat muut ryhmän jäsenet. Tällainen henkilö voi olla osa testaus- / kehitysryhmää. Tämä on yksi tekijä, joka päättää riippuvuuden ryhmästä / yksilöstä tietyssä projektissa.
Mikä on testaaja urapolku?
Henkilö voi viedä jonkin aikaa ymmärtää yleistä testausprosessia, verkkotunnusta ja muita tehtäviä, joissa hänen odotetaan työskentelevän päivittäisessä elämässä. Tämän ymmärryksen perusteella on suositeltavaa tehdä päätös tutkia muita alueita, joihin testaaja voi ryhtyä. Prosessissa on aina mahdollisuuksia automatisoida erilaisia virtauksia. Pienten apuohjelmien luominen voi myös auttaa joukkuetta suurella tavalla. Jos testaaja osaa ohjelmoida hyvin, sitä pidetään suurena plussana. Tämä avaa mahdollisuuksia automaatiorooleille. Suorituskykytestaus on myös yksi testaajien urapolkuista. Liiketoiminta-analyytikko on toinen vaihtoehto. Hyvä verkkotunnuksen tuntemus ja hyvät kommunikaatiotaidot ovat liiketoiminta-analyytikoiksi vaadittavat taitojoukot. Testaus avaa testaajille monia mahdollisuuksia työskennellä eri aloilla, työkaluilla, prosesseilla ja niin edelleen. Se riippuu vain siitä, että henkilö poimii ja alkaa mennä syvälle yhden testauksen ydinalueen sisäpuolelle. Eri työkaluille on olemassa useita erityisiä sertifikaatteja erikoistua yhdelle testausalueelle. Vakiotoimittajan sertifikaattien saaminen on etu uran parantamiseksi, mutta pelkästään todistus ei voi auttaa sinua pitkällä tähtäimellä, ellei sitä yhdtetä oikeaan työkokemukseen.
Suositellut artikkelit
Tässä on artikkeleita, jotka auttavat sinua saamaan lisätietoja ohjelmistotestauksesta, joten mene vain linkin läpi.
- 6 hämmästyttävintä ohjelmistotestauksen haastattelua koskevaa kysymystä
- Ura ohjelmistotestauksessa
- Kuinka parantaa uran kasvua ohjelmistojen testaajan työssä