Mitä on työnkulun testaus ohjelmistotestauksessa? esimerkkien kanssa
Thomas Hamilton
⚡ Älykäs yhteenveto
Työnkulun testaus varmistaa, että jokainen sovelluksen sisäinen vaihesarja heijastaa edelleen sitä liiketoimintaprosessia, jota varten se on rakennettu, tarkistamalla jokaisen vaiheen, luovutuksen ja riippuvuuden ensimmäisestä toiminnosta lopputulokseen asti.
Mitä on työnkulun testaus?
Työnkulun testaus on ohjelmistotestauksen tyyppi, joka tarkistaa, että jokainen ohjelmiston työnkulku heijastaa tarkasti tiettyä liiketoimintaprosessia. Työnkulku on sarja tehtäviä, jotka tuottavat halutun tuloksen, ja se sisältää yleensä useita vaiheita tai askeleita. Kaikissa liiketoimintaprosesseissa näiden peräkkäisten vaiheiden testausta kutsutaan työnkulkutestaukseksi.
Merkittävä ero on laajuus. Yksittäinen testitapaus kysyy, palauttaako yksi funktio oikean vastauksen. Työnkulkutesti kysyy, tuottaako kymmenen näistä funktioista, suoritettuina siinä järjestyksessä, jossa todellinen käyttäjä niitä seuraa, edelleen liiketoiminnan odottaman tuloksen. Tästä syystä työnkulkutestaus kuuluu prosessikeskeisten merkintöjen joukkoon ohjelmistotestauksen tyypit luettelon eikä yksikkötason tekniikoiden avulla.
Esimerkki työnkulun testauksesta
Varmista esimerkiksi, että järjestelmä voidaan asentaa käyttäjän alustalle ja että se toimii oikein.
Rikkaempi esimerkki on verkkotilaus. Asiakas lisää tuotteen ostoskoriin, käyttää alennuskoodia, valitsee toimitusvaihtoehdon, maksaa ja saa vahvistussähköpostin, kun taas varasto vastaanottaa keräilyohjeen. Jokainen näistä vaiheista voi kulkea erikseen ja silti epäonnistua ketjuna: alennus ei välttämättä selviä maksuvaiheesta tai varastoviesti ei välttämättä koskaan poistu jonosta.
Työnkulun testaus tehdään vaiheittain. Näin suoritat työnkulun testauksen.
- AloitusvaiheTämä vaihe sisältää alustavan testisuunnittelun ja prototyyppitestauksen.
- ValmistusvaiheTämä vaihe sisältää testiarkkitehtuurin perustason määrittämisen.
- RakennusvaiheTämä vaihe sisältää merkittävää testausta jokaisen koontiversion yhteydessä.
- SiirtymävaiheTämä vaihe sisältää regressiotestit ja testaa korjaukset uudelleen.
Työnkulun testauksen suorittaminen
Yllä oleva vaihemalli kuvaa, milloin työ tapahtuu. Alla oleva sekvenssi kuvaa, mitä testaaja todellisuudessa tekee kussakin näistä vaiheista.
- Kartoita liiketoimintaprosessi. Piirrä työnkulku täsmälleen sellaisena kuin yritys sitä käyttää, mukaan lukien jokainen päätöksentekopiste, hyväksyntä ja luovutus osastojen välillä. Liiketoiminta-analyytikko on yleensä nopein reitti tarkkaan karttaan, ja liiketoiminnan analyytikko dokumentaatio on se viite, jota vasten karttaa tarkistetaan.
- Aseta sisään- ja ulosmenokriteerit. Kirjaa muistiin tila, jossa järjestelmän on oltava ennen työnkulun alkamista, sekä tila, joka todistaa sen päättymisen. Ilman molempia testaajat ovat eri mieltä siitä, onnistuiko ajo.
- Suunnittele testitapaukset. Kirjoita yksi tapaus kutakin työnkulun polkua kohden, älä yhtä ruutua kohden. Numero vaiheet, ilmoita kunkin odotettu tulos ja anna jokaiselle tapaukselle yksilöllinen tunniste, jotta viat voidaan tunnistaa. tracpalasi takaisin polulle.
- Valmistele realistinen testidata. Käytä uudelleen anonymisoituja tuotantomuotoisia tietueita keksittyjen arvojen sijaan. Alennuskoodit, verosäännöt ja osoitemuodot ovat tyypillisiä paikkoja, joissa synteettinen data kätkee todellisia virheitä.
- Suorita ensisijainen polku ensin. Varmista, että työnkulku suoritetaan loppuun asti, ennen kuin mitään tahallisesti rikki. Epäonnistuminen tässä mitätöi kaikki sitä seuraavat negatiiviset tulokset.
- Katkaise ketju tarkoituksella. Peruuta kesken, lähetä virheellinen arvo päätösvaiheessa, aikakatkaise istunto ja hylkää hyväksyntä. Mielenkiintoiset viat sijaitsevat näissä keskeytetyissä poluissa, eivät ensisijaisessa polussa.
- Raportoi, korjaa ja testaa uudelleen. Kirjaa jokainen vika sen vaiheen kohdalle, joka sen aiheutti, ja suorita sitten koko työnkulku uudelleen korjauksen jälkeen. Korjattu vaihe siirtää usein vikaa eteenpäin ketjussa.
Vakaat työnkulut, jotka toistuvat jokaisessa julkaisussa, ovat vahvimpia ehdokkaita automatisoinnille, koska samat järjestetyt vaiheet suoritetaan identtisesti joka kerta ja skripti maksaa itsensä takaisin muutamassa syklissä.
Kuka suorittaa työnkulkutestauksen?
Työnkulun testaus on jaettua työtä, koska yksikään rooli ei näe koko ketjua. Neljä roolia kantaa taakan, jokaisella on omat vastuualueensa.
- Testinsinööri
- Suunnittele testitavoitteet ja aikataulu
- Määritä testitapaukset ja -menettelyt
- Arvioi testitulokset
- Komponentti-insinööri
- Testikomponenttien kehittäminen
- Automatisoi jotkin testimenettelyt
- Integraatiotestaaja
- Esittävä integraatiotestit ja vikojen raportointi
- Järjestelmän testaaja
- Esittävä järjestelmätestit ja vikojen raportointi
Mitä työnkulussa testataan
Ohjelmiston työnkulut on dokumentoitu liiketoimintavaatimusten dokumentissa, ja kyseinen dokumentti on kattavuuden totuuden lähde. Työnkulun testaus sisältää myös osia järjestelmä- ja integraatiotesteistä.
Työnkulun täydellinen läpikäynti tarkastelee muutakin kuin käyttäjän näkemiä näyttöjä.
- järjestyksessä: Vaiheet suoritetaan dokumentoidussa järjestyksessä, eikä niitä voi ohittaa tai toistaa väärällä vuorolla.
- Tiedon luovutus: Ketjun alkuvaiheessa syötetyt arvot säilyvät muuttumattomina viimeiseen vaiheeseen ja kaikkiin jatkojärjestelmiin.
- Roolit ja käyttöoikeudet: Jokainen vaihe on käytettävissä vain siihen valtuutetulle roolille.
- Keskeytetyt polut: Peruutus, aikakatkaisu, hylkäys ja uudelleenyritys jättävät kaikki työnkulun määritettyyn tilaan.
- Artefaktit: Työnkulun testausmalli kattaa testitapaukset, testiproseduurit, testikomponentit ja testialijärjestelmät, joten jokainen näistä todennetaan vuorollaan.
- Ilmoitukset: Sähköpostit, hälytykset ja jonotusviestit lähetetään kerran, oikealla sisällöllä ja oikeassa vaiheessa.
Työnkulkutestaus vs. kokonaisvaltainen testaus vs. järjestelmätestaus
Nämä kolme tekniikkaa ovat päällekkäisiä niin paljon, että ne voivat hämmentyä, mutta ne vastaavat eri kysymyksiin. Taulukko asettaa rajat.
| Aspect | Työnkulun testaus | Kokonaisvaltainen testaus | Järjestelmätestaus |
| Kysymykseen vastattu | Vastaako ohjelmisto liiketoimintaprosessia? | Toimiiko koko matka kaikissa yhdistetyissä järjestelmissä? | Täyttääkö koottu järjestelmä vaatimukset? |
| Kattavuusyksikkö | Yksi liiketoimintaprosessi, askel askeleelta | Yksi käyttäjäpolku, käyttöliittymästä taustajärjestelmään | Täydellinen sovelluksen rakenne |
| Ensisijainen viite | Liiketoiminnan vaatimusasiakirja | Käyttäjäpolun kartta | Järjestelmävaatimusten määrittely |
| Tyypillinen omistaja | Testi-insinööri, jolla on liiketoiminta-analyytikon panos | Automaatio- tai laadunvarmistusinsinööri | Järjestelmän testaaja |
Käytännössä työnkulkutesti on usein spesifikaatio ja päästä päähän -testi on rakennettu, kun taas järjestelmän testaus tarjoaa vakaan koontiversion, jonka pohjalla työnkulku toimii.
Parhaat käytännöt ja yleiset haasteet
Työnkulun testauksesta arvoa saavat tiimit noudattavat yleensä samoja pieniä tapoja.
- Priorisoi tuloja tai sääntelyyn liittyviä riskejä sisältävät työnkulut ennen harvinaisia.
- Kuvaile jokainen vaihe ja odotettu tulos selkeällä ja yksiselitteisellä kielellä.
- Pidä yllä uudelleenkäytettävää ja realistista testidatajoukkoa, jotta testiajot pysyvät vertailukelpoisina eri ympäristöissä.
- Testaa jokainen työnkulku valideilla ja virheellisillä syötteillä jokaisessa päätöksentekopisteessä.
- Päivitä testitapaukset heti, kun taustalla oleva liiketoimintaprosessi muuttuu.
Toistuvat esteet ovat aivan yhtä ennustettavia.
- Dokumentoimattomat prosessit: Työnkulku elää ihmisten päässä, joten testaajat tarkistavat oletuksia.
- Pitkät suoritusajat: Hyväksyntöjä kattava työnkulku voi kestää tunteja, mikä rajoittaa manuaalisten suoritusten tiheyttä.
- Ympäristön ajautuminen: Ketjun alavirran järjestelmät ovat tukossa tai vanhentuneita, ja vikoja ilmenee vasta tuotannossa.
- Hauras automaatio: Näytön asetteluun sidotut skriptit katkeavat aina, kun käyttöliittymä muuttuu, vaikka prosessi ei muuttuisikaan.
- Tietojen törmäykset: Rinnakkaisajot käyttävät samoja tietueita, mikä aiheuttaa virheitä, jotka näyttävät tuotevirheiltä.
