Annettu–Kun–Niin-hyväksymiskriteerit selitettynä
Muoto: Annettu–Kun–Niin-kriteerit määrittelevät selkeän ja testattavan ohjelmiston toiminnan, jotta tiimin jäsenillä on yhteinen ymmärrys.
Rakenne: Jokainen muodon skenaario sisältää kontekstin, käyttäjän toiminnon ja odotetun lopputuloksen selkeällä kielellä.
Parhaat käytännöt: Keskity yksinkertaisuuteen, yhteistyöhön ja yksityiskohtiin parantaaksesi hyväksymiskriteerien selkeyttä.
Yleiset virheet: Vältä skenaarioiden ahtamista yhteen, teknisten yksityiskohtien kirjoittamista ja reunatapausten laiminlyöntiä.
Edellytys–Kun–Silloin-hyväksymiskriteerit tarjoavat yksinkertaisen ja testattavan tavan kuvata, miten ohjelmiston tulisi toimia, jotta kehittäjillä, testaajilla ja sidosryhmillä on yhteinen ymmärrys. Kun hyväksymiskriteerit ovat epämääräisiä, tiimit tuhlaavat aikaa vaatimuksista väittelemiseen, väärän ratkaisun rakentamiseen ja puutteiden löytämiseen vasta myöhäisessä kehitysvaiheessa.
Tässä oppaassa käyn läpi Edellytys–Kun–Silloin-muodon, esittelen todellisia esimerkkejä yleisistä tilanteista, vertaan sitä muihin hyväksymiskriteerien lähestymistapoihin ja jaan käytäntöjä, joiden avulla ketterät tiimit voivat kirjoittaa selkeämpiä ja tehokkaampia käyttäjätarinoita.
Mitä Edellytys–Kun–Silloin-hyväksymiskriteerit ovat?
Edellytys–Kun–Silloin on kolmiosainen mallipohja käyttäjätarinan hyväksymiskriteerien kirjoittamiseen. Jokainen skenaario kuvaa yhden osan odotetusta toiminnasta selkokielisesti niin, että kehittäjät, testaajat ja sidosryhmät voivat kaikki lukea sen.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Rakenne toimii näin:
- Edellytys kertoo, minkä täytyy olla jo totta ennen kuin loppukäyttäjä tekee mitään.
- Kun esittelee toiminnon. Se kertoo, mitä käyttäjä tekee tai minkä tapahtuman järjestelmä käynnistää.
- Silloin paljastaa lopputuloksen. Se on tulos, joka osoittaa järjestelmän reagoineen oikein.
Näin kirjoitat Edellytys–Kun–Silloin-hyväksymiskriteerit
Näin kirjoitat jokaisen lausekkeen niin, että se kestää kehityksen ja ohjelmistotestauksen aikana.
Edellytys: Kontekstin ja ennakkoehtojen määrittäminen
Edellytyslause kuvaa, minkä täytyy olla jo totta. Tähän kuuluvat järjestelmän tila, käyttäjän rooli, dataehdot ja ympäristön asetukset. Vahvat edellytyslauseet ovat täsmällisiä. Vältä kirjoittamasta ”Edellytys käyttäjä on kirjautunut sisään”, jos skenaario riippuu roolista. Kirjoita sen sijaan ”Edellytys rekisteröitynyt asiakas, jolla on voimassa oleva tilaus, on tiliasetusten sivulla.”
Muutama ohje edellytyslauseen kirjoittamiseen:
- Mainitse käyttäjän rooli tai käyttäjätyyppi, kun sillä on merkitystä.
- Kuvaa järjestelmän ehdot, kuten ominaisuusliput, datan tilat tai yhteydet.
- Yhdistä useat ennakkoehdot sanalla ”Ja” sen sijaan, että ahtaisit ne yhteen lausekkeeseen.
Kun: Toiminnon tai käynnistimen määrittäminen
Kun-lause tallentaa toiminnon tai tapahtuman, joka käynnistää testaamasi toiminnan. Sen tulisi kuvata yhtä käyttäjän vuorovaikutusta tai järjestelmätapahtumaa, ei tapahtumasarjaa. Käytä aktiivimuotoa. Kirjoita ”Kun asiakas napsauttaa painiketta ’Käytä kuponkia’” sen sijaan, että kirjoittaisit ”Kun kuponkipainiketta napsautetaan”. Näin poistat epäselvyyden siitä, kuka suorittaa toiminnon.
Pidä tämä lauseke tiiviinä. Jos tarvitset useamman kuin yhden Kun-lauseen, kuvaat todennäköisesti kahta erillistä skenaariota. Jaa ne.
Silloin: Odotetun lopputuloksen määrittäminen
Silloin-lause kertoo, mitä käyttäjän pitäisi havaita tai mitä järjestelmän pitäisi tehdä toiminnon jälkeen. Kuvaa havaittavia tuloksia. ”Silloin hallintapaneeli latautuu” on heikko ilmaisu. ”Silloin järjestelmä näyttää asiakkaan hallintapaneelin kahden sekunnin kuluessa” on testattava. Sisällytä yksityiskohtia, kuten virheilmoitukset, uudelleenohjauksen kohteet, datan muutokset, sähköpostin käynnistymiset tai käyttöliittymän tilan muutokset.
Käytä sanaa Ja yhdistämään useita lopputuloksia, kun yksi toiminto tuottaa useamman kuin yhden havaittavan tuloksen. Esimerkiksi ”Silloin tilausvahvistussivu näytetään” Ja ”asiakas saa vahvistussähköpostin 60 sekunnin kuluessa.”
Edellytys–Kun–Silloin-esimerkkejä
Tässä on esimerkkejä Edellytys–Kun–Silloin-hyväksymiskriteereistä eri toimialoilta.
Käyttäjän kirjautuminen
Skenaario 1: Onnistunut kirjautuminen kelvollisilla tunnistetiedoilla
Edellytys rekisteröitynyt käyttäjä on kirjautumissivulla Kun käyttäjä syöttää kelvollisen sähköpostiosoitteen ja oikean salasanan sekä napsauttaa ”Kirjaudu sisään” Silloin järjestelmä ohjaa käyttäjän hänen tilinsä hallintapaneeliin
Edellytyslause on tässä tarkoituksella suppea, koska skenaario ei riipu tilaustasosta tai tilin tilasta. Huomaa yhdistetty Kun-lause: tunnistetietojen syöttäminen ja painikkeen napsauttaminen ovat yksi looginen toiminto (kirjautumislomakkeen lähettäminen), joten pidän ne yhdessä sen sijaan, että jakaisin ne erillisiksi skenaarioiksi jokaista näppäinpainallusta varten.
Skenaario 2: Epäonnistunut kirjautuminen virheellisillä tunnistetiedoilla
Oletetaan, että rekisteröitynyt käyttäjä on kirjautumissivulla Kun käyttäjä syöttää kelvollisen sähköpostiosoitteen ja virheellisen salasanan ja napsauttaa "Kirjaudu sisään" Silloin järjestelmä näyttää viestin "Virheellinen sähköpostiosoite tai salasana" Ja käyttäjä pysyy kirjautumissivulla
Silloin-lauseke määrittää virheilmoituksen tarkan tekstin. Toinen Ja-lauseke on tärkeä, koska se vahvistaa, ettei käyttäjää vahingossa ohjata muualle.
Ostoskori ja kassalle siirtyminen
Skenaario 1: Tuotteen lisääminen ostoskoriin
Oletetaan, että asiakas tarkastelee varastossa olevan tuotteen tietosivua Kun asiakas napsauttaa "Lisää ostoskoriin" Silloin ostoskorikuvake päivittyy näyttämään yhden tuotteen Ja vahvistusviestissä lukee "Tuote lisätty ostoskoriin"
Oletetaan-lauseke sisältää ilmauksen "varastossa", koska toiminta poikkeaa loppuunmyytyjen tuotteiden tapauksessa ja kyseessä on erillinen skenaario.
Skenaario 2: Kelvollisen alennuskoodin käyttäminen
Oletetaan, että asiakkaalla on ostoskorissa kaksi tuotetta, joiden yhteishinta on $80.00 Kun asiakas syöttää alennuskoodin "SAVE20" ja napsauttaa "Käytä" Silloin järjestelmä myöntää 20 %:n alennuksen Ja ostoskorin loppusummaksi päivittyy $64.00
Tarkat dollarimäärät tekevät väärintulkinnasta mahdotonta. Tällainen alennusskenaario voi auttaa havaitsemaan tuotannossa pyöristysvirheen, jossa prosenttialennus parittomasta summasta tuotti hinnan kolmella desimaalilla. Oletetaan-lausekkeen ($80.00) ja Silloin-lausekkeen ($64.00) tarkkuus tekee skenaariosta hyödyllisen.
Salasanan palautus
Skenaario 1: Salasanan palautuksen pyytäminen rekisteröidyllä sähköpostiosoitteella
Oletetaan, että käyttäjä on kirjautumissivulla Kun käyttäjä napsauttaa "Unohditko salasanan?", syöttää rekisteröidyn sähköpostiosoitteen ja napsauttaa "Lähetä" Silloin järjestelmä näyttää viestin "Palautuslinkki on lähetetty sähköpostiisi" Ja järjestelmä lähettää salasanan palautusviestin 60 sekunnin kuluessa
Tämän Kun-lausekkeen yhdistelmä edustaa yhtä loogista kulkua: palautuksen pyytämistä. Silloin-lausekkeen 60 sekunnin aikaraja on ratkaiseva. Ilman sitä 20 minuuttia myöhemmin saapuva palautusviesti täyttäisi teknisesti ehdon. Aikaan sidotut lopputulokset ovat yksi useimmin puuttuvista yksityiskohdista.
Skenaario 2: Vanhentuneen palautuslinkin käyttäminen
Oletetaan, että käyttäjä sai salasanan palautusviestin yli 24 tuntia sitten Kun käyttäjä napsauttaa viestissä olevaa palautuslinkkiä Silloin järjestelmä näyttää viestin "Tämä linkki on vanhentunut. Pyydä uusi palautus."
Oletetaan-lauseke sisältää aikarajoitteen, joka pakottaa keskustelemaan vanhenemisajan pituudesta.
Lomakkeen kelpoisuustarkistus
Skenaario 1: Pakollisia kenttiä puuttuvan lomakkeen lähettäminen
Oletetaan, että käyttäjä on rekisteröitymislomakkeella Kun käyttäjä jättää "Sähköposti"-kentän tyhjäksi ja napsauttaa "Lähetä" Silloin järjestelmä näyttää Sähköposti-kentän alapuolella tekstinsisäisen virheilmoituksen "Sähköposti on pakollinen" Ja lomaketta ei lähetetä
Silloin-lauseke määrittää virheen sijainnin ("Sähköposti-kentän alapuolella"), ei ainoastaan sitä, että virhe näkyy.
Skenaario 2: Tekstikentän merkkirajan ylittäminen
Oletetaan, että käyttäjä täyttää "Kuvaus"-kenttää, jonka merkkiraja on 500 merkkiä Kun käyttäjä syöttää 501 merkkiä Silloin järjestelmä estää lisäsyötteen Ja viestissä lukee "Enintään 500 merkkiä sallitaan"
GWT vs. tarkistuslistat vs. käyttötapaukset
Tässä on joitakin muita hyväksymiskriteerien tyyppejä ja tilanteita, joissa kutakin niistä voi käyttää:
| Näkökohta | Given-When-Then | Sääntöihin perustuva tarkistuslista | Käyttötapaus |
|---|---|---|---|
| Rakenne | Given, When, Then | Sääntöjen luettelomerkein esitetty luettelo | Numeroidut vaiheet kulkuineen |
| Sopii parhaiten | Toiminnalliset skenaariot, BDD | Liiketoimintasäännöt, käyttöliittymämääritykset | Monimutkaiset, useita kulkuja sisältävät ominaisuudet |
| Vahvuudet | Testattava, automatisoitava ja kontekstitietoinen | Nopea kirjoittaa, helppo silmäillä | Perusteellinen, kattaa reunatapaukset |
| Rajoitukset | Yksinkertaisiin muutoksiin nähden sanallinen | Ei skenaarion kulkua, vaikea automatisoida | Raskas, hidas ylläpitää |
| Kohderyhmä | Kehittäjät, laadunvarmistus, tuotehallinta | Tuotehallinta, suunnittelu, sidosryhmät | Ulkoiset tiimit, vaatimustenmukaisuus |
| Laajuus | Yksittäinen toiminta | Koko ominaisuus | Koko ominaisuus |
| Yksityiskohtien taso | Kolme lausetta | Joustava | Esiehdot, jälkiehdot, laukaisimet ja numeroidut vaiheet |
Olen havainnut, että käyttötapaukset toimivat parhaiten, kun järjestelmä on dokumentoitava sääntelyn vaatimustenmukaisuutta varten tai luovutettava ulkoiselle toimittajalle. Päivittäisessä sprinttityössä given-when-then on suppeampi ja nopeampi.
Given-When-Thenin parhaat käytännöt
Seuraavassa on joitakin parhaita käytäntöjä, joiden avulla voit käyttää GWT:tä tehokkaasti:
- Vältä epämääräistä tai monitulkintaista kieltä: Sen sijaan että kirjoittaisit ”Sivu latautuu nopeasti”, kirjoita ”Hakutulossivu latautuu kahdessa sekunnissa.” Korvaa ilmaisut kuten ”asianmukainen” tai ”olennainen” mitattavilla arvoilla. Jos sitä ei voi testata, muotoile se uudelleen.
- Pidä skenaariot yksinkertaisina ja rajattuina: Noudata yhden toiminnan sääntöä skenaariota kohden. Jokaisen skenaarion tulee testata täsmälleen yhtä asiaa. Kun yhdistät useita toimintoja tai lopputuloksia, luot testitapauksia, joita on vaikea selvittää ja ylläpitää. Jos skenaariossa on then-osiossa enemmän kuin kaksi and-lausetta, kysy itseltäsi, testaatko yhtä vai kahta toimintaa.
- Järjestä kolmen amigoksen istunto: Kolmen amigoksen istunto on lyhyt ja keskittynyt keskustelu, jossa tuotehallinnan edustaja (tuoteomistaja tai liiketoiminta-analyytikko), kehittäjä ja testaaja tarkastelevat tulevia tarinoita yhdessä ennen sprintin alkua. He kirjoittavat GWT-kriteerit tai viimeistelevät niitä ryhmänä, mikä ehkäisee uudelleentyötä.
- Säilytä terminologian ja tyylin johdonmukaisuus: Valitse vakiintuneet termit ja käytä niitä johdonmukaisesti kaikissa tarinoissa. Jos käytät yhdessä skenaariossa sanaa ”asiakas” ja toisessa sanaa ”käyttäjä”, aiheutat sekaannusta. Luo tarvittaessa pieni sanasto. Käytä lausekkeissasi samaa lauserakennetta.
Viisi yleistä haitallista käytäntöä
Seuraavassa on joitakin yleisiä virheitä, joita tulee välttää kirjoitettaessa given-when-then-hyväksymiskriteerejä:
- Toteutuksen yksityiskohtien kirjoittaminen toiminnan sijaan: Esimerkiksi ”Kun API-kutsu palauttaa tilakoodin 200” kuvaa teknistä toteutusta, ei käyttäjän toimintaa. Kirjoita se uudelleen käyttäjän näkökulmasta: ”Kun tuoteluettelo on latautunut etusivulla.” Säästä tekniset yksityiskohdat testiautomaation koodiin.
- Useiden skenaarioiden ahtaminen yhteen: Skenaario, jossa testataan kirjautumista, navigointia ja kassaprosessia samassa kokonaisuudessa, on integraatiotesti, ei hyväksymiskriteeri. Pilko jokainen toiminta omaksi skenaariokseen. Näin saat selkeämmät tulokset ja ongelmien jäljittäminen helpottuu.
- Negatiivisten ja poikkeustapausten skenaarioiden ohittaminen: Ketterät kehitystiimit kirjoittavat usein onnistuneen peruspolun ja unohtavat, mitä tapahtuu, kun asiat menevät pieleen. Kysy jokaisen onnistuneen skenaarion kohdalla: entä jos syöte on virheellinen? Entä jos verkkoyhteys katkeaa? Entä jos tiedot puuttuvat? Kirjoita vähintään yksi negatiivinen skenaario jokaista tarinaa kohden, jotta löydät ongelmat ennen niiden päätymistä tuotantoon.
- GWT:n pitäminen ainoana hyväksyttävänä muotona: Käytä GWT:tä toiminnan kuvaamiseen ja tarkistuslistoja kaikkeen muuhun. Jos pakotat jokaisen tarinan given-when-then-muotoon, mukaan lukien painikkeiden värien muutokset, tekstisisällön päivitykset ja infrastruktuurin määritykset, päädyt joihinkin absurdeihin tuloksiin (esimerkiksi ”Kun etusivu on olemassa, kun käyttäjä tarkastelee sitä, niin otsikon fonttikoko on 16 pikseliä.).
- Skenaarioiden kirjoittaminen erillään: Älä kirjoita GWT-kriteerejä yksin. Muodon arvo syntyy sen herättämästä keskustelusta. Jos vähintään kaksi eri alaa ei keskustele skenaarioistasi ennen ohjelmistokehityksen aloittamista, käytät GWT:tä dokumentointimuotona, vaikka sen todellinen voima on yhteistyömuotona.
Mitä seuraavaksi?
Selkeät given-when-then-hyväksymiskriteerit ovat vain yksi osa onnistuneiden projektien toimittamista. Rakenna tämän perustan päälle ilmaisella DPM-jäsenyydellä ja saat käyttöösi käytännöllisiä malleja, asiantuntijaresursseja ja hyväksi todettuja viitekehyksiä, jotka auttavat muuttamaan tarkasti määritellyt vaatimukset sujuvammaksi toimitukseksi ja paremmiksi tuloksiksi.
