7 Test Case Writing Vinkkejä parantaa ERP Ohjelmistojen testaus prosessi

Test cases ovat erittäin tärkeitä laadun varmistamiseksi ERP ohjelmistojen testaus prosessi. Ne ovat testisyklin ensimmäiset vaiheet, ja jos testitapaukset eivät ole riittävän laadukkaita, koko projekti “kuormittuu”. “Suurten” koejuttujen kirjoittaminen on taito, joka muotoutuu pelkällä tekemisellä. Mutta se on erittäin kätevä on joitakin oivalluksia, jotka voivat auttaa sinua. Tämän artikkelin haluan tavoittaa sinut ja antaa ehdotuksia, jotta se olisi helpompaa, hauskempaa ja parempaa. Annettavat vinkit liittyvät erityisesti ERP-järjestelmien hyväksymistesteissä tapahtuviin testitapauksiin.

Mitä ovat testitapaukset?

ohjelmistotestauksen maailmassa on paljon määritelmiä testitapauksille. Tämän vuoksi on tärkeää nimetä määritelmämme. Filosofiamme testitapaukset ovat (perustuu IEEE610: een): “joukko testituloksia, suoritusolosuhteita ja odotettuja tuloksia, jotka on kehitetty tiettyä tavoitetta varten.”Hyvien testijuttujen kirjoittamisen osaaminen on erittäin hyödyllistä kaikille, jotka haluavat testata. Olipa kyseessä toiminnallinen testi, käyttäjän hyväksymistesti, verkkosovelluksen testaus tai ERP-järjestelmän moduuli. Kaikissa edellä kuvatuissa tilanteissa testitapaukset määrittävät, mihin asti tulokset antavat tuomion ennalta asetetuista tavoitteista.

miksi koejuttujen kirjoittaminen on niin vaikeaa?

kuten määritelmässä on kuvattu, testitapaukset auttavat testaajia testiohjeiden avulla määrittämään, täyttääkö ohjelmisto ennalta määritellyt vaatimukset. Testitapausten suorittaminen auttaa meitä keräämään ja löytämään tietoa kyseisen tavoitteen tai kohteen toteuttamiseksi. Ensimmäinen suoraan kohtaamamme ongelma on mahdollisten kohteiden moninaisuus. Ja koska on erilaisia testejä ja tavoitteita, on erilaisia vastaavia testitapauksia.

toinen ongelma liittyy varsinaisen testiohjeen tai-vaiheiden sisältöön. Näiden ohjeiden taso riippuu siitä, minkä tyyppinen testaaja joutuu tulkitsemaan näitä tietoja ja antamaan lausunnon. Ammattimainen testaaja tarvitsee erilaisia ohjeita verrattuna loppukäyttäjään, joka osallistuu ERP-järjestelmän hyväksymistestaukseen

Tip 1: Määrittele tavoitteesi ja mitä haluat raportoida

mieti, mitä haluat raportoida, jotta voit määrittää derivaattatavoitteesi. Kun käytät sitä pohjana, näet testikappaleen ääriviivat. On monia erilaisia tavoitteita, joissa meidän on aina kysyttävä itseltämme, mitä yritämme oppia tai saavuttaa, kun aiomme suorittaa testin. Tässä muutamia esimerkkejä:

• vikojen löytäminen: tämä on testauksen klassinen tarkoitus. Testi suoritetaan paljastaa vikoja.
• maksimoi vikojen määrä: Ero “maksimoida vikojen määrä” ja “löytää vikoja” on, että kokonaismäärä vikoja on tärkeämpää kuin kattavuus.
• Estä ennenaikaiset tuotejulkistukset: tämän testin tavoitteena on löytää ennenaikaisesti mahdollisimman monta vakavaa vikaa (showstoppers), jotta kukaan ei ota tuotetta tuotantoon.
• tue esimiehiä go/no-go-päätöksillään: esimiehet tekevät päätöksiä riskien perusteella. Riskinilmaisut testin kattavuutena, havaittujen ongelmien vaikutuksina jne. Anna heille parempi tausta, johon he voivat perustaa päätöksensä.
• arvioi vaatimustenmukaisuus eritelmän mukaisesti: väitetyt eritelmät tarkistetaan niiden toiminnan osalta. Kaikki seikat, jotka eivät liity eritelmiin, jätetään huomiotta.
• arvioi laatua: tämä on vaikea tavoite, koska laatu on moniulotteinen. Laatu riippuu tuotteen luonteesta. Laadun arvioimiseksi olisi laadittava selkeät kriteerit, jotka on määritelty siten, että ne voidaan todella tehdä mitattaviksi.

testitapauksista saadut testitulokset antavat suoraan relevanttia tietoa tavoitteesta.

Vihje 2: varaa riittävästi suunnitteluaikaa

Varaa riittävästi aikaa testijuttujen suunnitteluun, jotta ne vastaavat tavoitteitasi. Huonot testitapaukset kummittelevat koko testiprosessin ajan. Testitulosten vertailu, useiden testikierrosten raportointi jne. Määräytyvät lähinnä laatu testitapauksia.

jos suunnitteluaikasi on jo loppumassa, mutta haluat silti aloittaa testauksen, varmista, että olet ainakin määritellyt tärkeimmät riskit. Jos 10 testaajaa joutuu tarkastelemaan 5 testitapausta yhdellä testivaiheella, tuloksena on 50 testitulosta. Ei ole väliä mitä nämä 50 tulokset antavat enemmän tietoa laadusta sitten tehdä mitään. Tämä ei todennäköisesti ole tyhjentävä, mutta se on ensimmäinen askel. Siitä voidaan määrittää tiettyjen osien yksityiskohtaisuus.

mielestämme on parempi, että miettii hyvissä ajoin, miten testi on suunniteltava, ja että testin tulokset antavat todellisen vastauksen tavoitteeseen. Mutta todellisuudessa tämä on joskus kuritonta.

Vihje 3: Nimitestitapaus

testitapausten nimeäminen on tärkeää. Keskimääräisessä TOIMINNANOHJAUSTESTISSÄ on helposti yli 500 testitapausta. Ymmärrät, että looginen nimirakenne parantaa löydettävyyttä. Kirjallisuudessa puhutaan usein mahdollisimman täydellisestä nimestä, jossa testattava prosessi, moduuli, objekti jne. Ovat kaikki mukana nimessä. Voitte kuvitella, että 500 testitapauksen tarjoaminen näin täydellisellä otsikolla antaa kaoottisen hallinnon. Yksinkertaisella Excel-arkki, voit helposti menettää yleiskuvan. Testinhallintatyökalut tarjoavat rakenteen, johon voit liittää testitapauksia uudelleenkäytettäviin esineisiin ilman, että ne “saastuttavat” nimeä. Sinulla on myös testi rekisteröinti työkaluja, jotka järjestävät nämä suhteet eri tavalla.

esimerkiksi Testmonitorissa keksimme erilaisen ratkaisun. Työkalussa voit määritellä tarroja tai tunnisteita, jotka voit linkittää testitapauksiin. Testmonitorissa testitapaukset liittyvät yhteen tai useampaan liiketoimintaprosessiin-, riskiin-, vaatimukseen – tai sovellusmerkintöihin. Näin testitapaukset voidaan ryhmitellä ja hakea eri näkökulmista.

Testmonitorin testitapauksen nimelle riittää selkeä kuvaus testitapauksen tarkoituksesta. Yksinkertaistaaksenne kuvailette toimintaa, johon liittyy implisiittisiä odotuksia.

esimerkkitapauksen nimi:
“vuokrasopimuksen irtisanominen-itsenäinen koti”
“Luo asiakas” “Väliaikainen varauskuitti”
jne.

esimerkki testitapauksesta “alustava varauskuitti” , joka liittyy useisiin merkintöihin:

• liiketoimintaprosessi “vastaanottavat tavarat”
• vaatimus “Sopimusvaatimus”
• riski “operatiivinen riski”
• soveltaminen “ERP’

on tärkeää kuvata odotettu tulos testitapausta kohti. Testaaja tietää sitten, mihin suuntaan “vastauksen” on oltava, ja saa suoraan nimenomaisen testauskehyksen.

Tip 4: Test step description

as described in the definition test cases on kokoelma testiohjeita, jotka auttavat meitä löytämään tietoa tietyn tavoitteen saavuttamiseksi.

Testitapauksella on oltava selkeä alku ja loppu sen määrittämiseksi, onko testitapaus läpäissyt vai epäonnistunut. Lisäksi testitapaus koostuu yhdestä tai useammasta testiohjeesta tai-vaiheesta, joissa on useita polkuja mahdollista halutun tuloksen saavuttamiseksi. Vain onnistumisen tien testaaminen on usein riittämätöntä. Tietyissä tilanteissa seuraavat ei-menestys polkuja voi vain tehdä eron.

on tärkeää määritellä testivaiheet mahdollisimman selkeästi, jotta käyttäjän hyväksymistestin loppukäyttäjä tietää tarkalleen, mitä hänen on tehtävä. Tietenkin on olemassa ennakkoehtoja keksiä, kuten toiminnallisen tason testaaja, uuden järjestelmän tuntemus, mahdollisten mukautettujen liiketoimintaprosessien tuntemus jne. Mutta pohjimmiltaan kaikkien pitäisi ymmärtää kaikki testin vaiheet.

Oletetaan, että kuvailemme vielä testitapausta” Lease termination – independent home ” yksinkertaiselle menestyspolulle:

1. Valitse yksikkö ja aloita vuokrasopimuksen päättäminen. Määräysvalta, jos on olemassa edellytyksiä, joiden joukossa vuokrasopimuksen irtisanominen voidaan / ei voida hyväksyä,ja kirjattava tämä.
2. varaa aika lopputarkastukseen.
3. täytä tiedot vuokrasopimuksen päättymisestä ruudussa. Tarkista vuokralaisen tiedot vuokrasopimuksen päättymiskortista.
4. rekisteröi vuokrasopimuksen päättyminen ja lähetä sopimuskirje. Tarkista, onko vahvistuskirje tullut digitaalisesta arkistosta.
5. Tarkista sopimusrekisteristä yksiköltä, että nykyinen sopimus on irtisanottu, että irtisanottu sopimus liittyy vuokrasopimuksen päättymiseen ja että on syntynyt Uusi avoin työsopimus.
6. tarkista Uusi (avoin)sopimus vuokrapolitiikan ja elementtipohjien perusteella.

mitä huomaat?

• jokainen testivaihe alkaa verbillä
• , jota seuraa aihe
• , joka päättyy yksityiskohtiin ja mahdollisesti kontrollikysymyksiin. Voit halutessasi laittaa valvontakysymykset erillisiin testivaiheisiin, mutta käytäntö osoittaa, että valvontakysymys on toiminnan hienosäätö ja sitten loogisesti, kirjoitetaan ylös testivaiheena.

edellä mainitussa esimerkissä oletetaan, että tietyn alan asiantuntija arvioi testivaiheen. Ja koska hän on asiantuntija, hänelle ei anneta mitään panosehtoja eikä esitetä selkeitä odotuksia, koska asiantuntijalla on vielä omat tapaustutkimuksensa hihassaan ja hänen odotuksensa ovat kristallinkirkkaat.

jos sinulla ei tällä hetkellä ole asiantuntijaa, voit laajentaa testivaiheita syöttöolosuhteilla ja nimenomaisilla odotuksilla.

esimerkiksi testivaihe 1 testijutussa “vuokrasopimuksen irtisanominen – itsenäinen koti” tarkemmilla tiedoilla.

1. Valitse yksikkö “Fleet street 677” ja aloita vuokrasopimuksen irtisanominen. Ehdoilla varmistetaan, ettei tätä yksikköä voida irtisanoa ennen kuin rästit on maksettu.
2. jne.

kärki 5: Enintään 10 testiohjetta 1 testitapauksessa

törmäämme säännöllisesti testiprojekteihin, joissa >50 testivaihetta osoitetaan yhteen testitapaukseen. Tämä on liikaa muutamasta syystä:

• kaikki testivaiheet on toteutettava erikseen (tai nimenomaisesti läpäistävä) ennen kuin testitapaus saa tuomion.
• testitapauksen lopullinen arvio määräytyy “huonoimman” pistemäärän perusteella. Voi siis hyvin olla, että 49 testivaihetta arvioidaan “hyväksi” ja yksi “vääräksi”, mikä johtaa “väärään” testitapaukseen. Testivaiheiden mittausten on oltava samanlaiset. Tarkoitan tällä sitä, että lähes jokaisen testivaiheen on vastattava arvioinnin vaikutusta. Jos sinulla on 10 testivaihetta, joita sinun on noudatettava, mukaan lukien 2 pientä testivaihetta, jotka ovat suhteettomia muihin 8 testivaiheeseen verrattuna, sinun on muotoiltava ne uudelleen. Sama pätee toisinpäin kovassa testivaiheessa.
• testaaja eksyy nopeasti liian monella testivaiheella testitapauksen sisällä. Emme ole tehneet tieteellistä tutkimusta siitä, mutta käytäntö osoittaa, että testitapaukseen ei pitäisi sisältyä enempää kuin 10 testivaihetta. Voidaan ajatella monia poikkeuksia (muuntaminen valvonta, jne), mutta käytännössä käyttäjän hyväksymistesti ERP järjestelmä tämä toimii parhaiten.
• kehittäjien on vaikea toistaa havaittua virhettä. Monien testivaiheiden avulla Kehittäjä menettää paljon aikaa yrittäessään toteuttaa tilanteen uudelleen.
• suurten testitapausten Uusinnat tai uusintatestit vievät liikaa aikaa. Kun testaaja havaitsee vian, vastaava testitapaus on testattava uudelleen. Uusintatesti edellyttää, että hyvin vaihe arvioidaan uudelleen, haluat estää regressiovirheet ilmeisesti. Jos otat liikaa testivaiheita, todennäköisesti testaat liikaa. Näin testiprosessi kestää kauemmin ja voi lopulta ylikuormittaa testaajat.

sen rinnalla on myös testirekisteröintityökalut, joilla testitapaukset voidaan esittää testaajalle eri muodoissa. Esimerkiksi testmonitorilla on kaksi erilaista näkymää. Testmonitorissa on näyttö, joka näyttää kaikki testivaiheet erikseen sivua kohti, ja näyttö, jossa testitapaukset esitetään sivua kohti sisältäen kaikki testivaiheet.Ensimmäisen näytön etuna on, että jokainen testaaja voi saada lisätietoja jokaisesta testivaiheesta. Haittana, jos testaaja on kokeneempi hän on klikkaa “Seuraava” joka kerta, kun hän haluaa edetä seuraavaan testivaiheeseen. Toisen näkemyksen mukaan kunkin testitapauksen edut ja haitat ovat päinvastoin.

Vihje 6: ei-suunnittelijan/toimittajan arvostelu

käytännössä näemme säännöllisesti ohjelmistotoimittajan ohjelmoijien laatimia testikäsikirjoituksia. Kun näitä testikäsikirjoituksia tarkistetaan mahdollisilla testaajilla, on yleensä enemmän kysymyksiä kuin vastauksia. Kääntäen, tämä toimii sama testi skriptejä laatinut oman työntekijän. Se antaa todellista lisäarvoa tarkistaa näitä ohjelmistotoimittaja. He katsovat valmiita testikäsikirjoituksia eri silmin ja keksivät aina mielekkäitä lisäyksiä tai muutoksia.

pienellä ideoinnilla ohjelmistotoimittajien asiantuntijoiden ja asiakasorganisaation kanssa saat nopeasti fokuksen siihen, mitä pitää testata. Sitten ottaa aikaa harkita testitapauksia, ei-menestys skenaarioita ja näet, että testi malli on nopeasti tulee laajempi ja yksityiskohtainen. Sen lisäksi, saat enemmän tietoa laadusta sitten olet katsonut mahdolliseksi.

Vihje 7: TestMonitor

vieressä, jotka hyödyntävät ammattimaista testialustaa ja tekevät laadusta todella oivaltavaa. Pyydä ilmainen kokeiluversio TestMonitor tänään ja nähdä ja kokea ero itse.

jos on uusi tulokas testaamisen maailmassa, hukkuu helposti siihen, että kaikki testaustermit heittelehtivät ympäriinsä. Tässä artikkelissa, yritämme selittää joitakin ammattikieltä saatat kohdata jokapäiväisessä testaus elämässä, vain tehdä kaikki hieman ymmärrettävämpi.

Aloita testaus testmonitorilla

eikö TestMonitor ole vielä käyttäjä? Hyvä ja helppo testaus on etusijalla laadunvarmistuspäälliköille, testimanagereille, IT-johtajille, testipäälliköille ja release managerille. TestMonitor tekee testaamisesta helppoa ja hauskaa myös testikäyttäjille.

so let ‘ s get you started. Kannattaa katsoa video tai ladata pakkausseloste. Mutta tietenkin, ilmainen kokeiluversio voit todella kokea helppokäyttöisyys TestMonitor itse.

pidetäänkö yhteyttä? Seuraa Testmonitoria Twitterissä ja LinkedInissä.