olvasási idő: 7 perc
bármely projekt sikere attól függ, hogy a fejlesztő csapat képes-e kielégíteni ügyfele igényeit. Az ügyfél és a fejlesztőcsapat közötti kommunikáció létfontosságú szerepet játszik a termék-és piaci igényeknek megfelelő megoldás megvalósításában., A problémák akkor merülnek fel, ha az ügyfelek túl homályosan magyarázzák meg igényeiket, a csapat pedig nem érti az egyértelmű követelményeket, végül pedig a mögöttük álló üzleti problémát. Képzelje el, hogy megkéri a csapatát, hogy engedélyezze a felhasználók számára, hogy kategóriák szerint keressenek egy terméket egy online könyvesboltban. Arra számít, hogy világos felületet kap a kategórialinkekkel, hogy rákattintson rájuk (például Fantázia, nem fikció, történelmi stb.) Két hét fejlesztés után egy keresősáv funkciót kap, amelyben a felhasználóknak az előzetesen felsorolt kategóriák böngészése helyett be kell írniuk az érdeklődő kategóriát., Bár ez is működik, a kezdeti cél az volt, hogy ki az összes rendelkezésre álló kategóriák, majd hagyja, hogy a felhasználók vizsgálja tovább.
Ez az, amikor a kiváló minőségű szoftverdokumentáció segíthet elkerülni a problémát. Felhasználói történetek és elfogadási kritériumok (AC), mint a követelmények dokumentálásának fő formátumai. A felhasználói történet egy szolgáltatás természetes nyelvi leírása. Általában Elfogadási Kritériumok kísérik.
Elfogadási Kritériumok (AC) azok a feltételek, amelyeknek egy szoftverterméknek meg kell felelnie ahhoz, hogy egy felhasználó, egy ügyfél vagy más rendszer elfogadja., Minden egyes felhasználói történethez egyediek, és a szolgáltatás viselkedését a végfelhasználó szemszögéből határozzák meg. A jól megírt elfogadási kritériumok segítenek elkerülni a váratlan eredményeket a fejlesztési szakasz végén, és biztosítják, hogy minden érdekelt és felhasználó elégedett legyen azzal, amit kap.
az Elfogadási Kritériumok a legalacsonyabb szintű funkcionális követelmények
Elfogadási Kritériumok a fő célok
Az érdekelt felek követelményeinek tisztázása magas szintű cél. Annak érdekében, hogy az AC céljai világosabbak legyenek, bontsuk le őket.,
A szolgáltatás hatókörének detalizációja. AC határozza meg a felhasználói történetek határait. Pontos részleteket adnak a funkcionalitásról, amelyek segítenek a csapatnak megérteni, hogy a történet befejeződött-e, és a várt módon működik-e.
negatív forgatókönyvek leírása. A yor AC megkövetelheti a rendszertől, hogy felismerje a nem biztonságos jelszóbeviteleket, és megakadályozza, hogy a felhasználó továbbhaladjon. Az érvénytelen jelszóformátum az úgynevezett negatív forgatókönyv példája, amikor a felhasználó érvénytelen bemeneteket hajt végre, vagy váratlanul viselkedik. Az AC meghatározza ezeket a forgatókönyveket, és elmagyarázza, hogyan kell a rendszernek reagálnia rájuk.
kommunikáció beállítása., Az Elfogadási Kritériumok szinkronizálják az ügyfél és a fejlesztőcsapat elképzeléseit. Biztosítják, hogy mindenki tisztában legyen a követelményekkel: a fejlesztők pontosan tudják, milyen viselkedést kell mutatnia a funkciónak, míg az érdekelt felek és az ügyfél megértik, hogy mi várható a funkciótól.
az elfogadás tesztelésének egyszerűsítése. AC a felhasználói történet elfogadási tesztelésének alapja. Minden elfogadási kritériumnak függetlenül tesztelhetőnek kell lennie, így egyértelmű átállási vagy sikertelen forgatókönyvekkel kell rendelkeznie. Ezeket fel lehet használni a történet automatikus tesztekkel történő ellenőrzésére is.
jellemző becslés., Az Elfogadási Kritériumok meghatározzák, hogy pontosan mit kell fejlesztenie a csapatnak. Miután a csapatnak pontos követelményei vannak, megoszthatják a felhasználói történeteket olyan feladatokra, amelyek helyesen becsülhetők.
elfogadási kritérium típusok és struktúrák
AC lehet írni különböző formátumokban. Két leggyakoribbak, a harmadik lehetőség az, hogy dolgozzon a saját formátum:
- forgatókönyv-orientált (Adott/Ha/Akkor)
- szabály-orientált (ellenőrző lista)
- egyéni formátumok
Mint az első, majd a második formátumok nagyon különleges struktúrák, majd többnyire rájuk koncentrálni., Előfordulhat azonban, hogy más formátumok jobban illeszkednek a termékhez, így röviden megérintjük őket is.
forgatókönyv-orientált Elfogadási Kritériumok
Az AC írás forgatókönyv-orientált formátuma az adott / When / Then (GWT)típus.
- adott néhány előfeltétel
- amikor néhány műveletet
- akkor azt várom, hogy néhány eredmény
Ez a megközelítés örökölt viselkedés-vezérelt fejlődés (BDD), és egy következetes struktúra, amely segít a tesztelők meghatározni, hogy mikor kell kezdeni, és a végén tesztelés egy adott funkció., Csökkenti a tesztesetek írására fordított időt is, mivel a rendszer viselkedését előre leírják.,
Az ebben a formátumban írt minden elfogadási kritériumnak a következő kijelentései vannak:
- forgatókönyv – A
- leírandó viselkedés neve – a forgatókönyv kezdeti állapota
- mikor – a felhasználó által
- akkor – a művelet kimenetele a “mikor”
- és – a három korábbi állítás bármelyikének folytatására használják
egy feladat elvégzése és az eredmény megtapasztalása szükséges.
nézzünk néhány példát.,
példa 1
felhasználói történet: felhasználóként szeretnék visszaállítani a jelszót a fiókomba, hogy hozzáférhessek a fiókomhoz, ha elfelejtettem a jelszót.,amikor: a felhasználó kiválasztotta Elfelejtett jelszó opció
és: beírt egy érvényes e-mailt, hogy kap egy linket jelszó helyreállítása
akkor: a rendszer elküldte a linket a megadott e-mail
adott: a felhasználó megkapta a linket az e-mail
amikor: a felhasználó navigált a linken keresztül kapott az e-mail
akkor: a rendszer lehetővé teszi a felhasználó számára, hogy új jelszót
2.példa
felhasználói történet: mint felhasználó, azt akarom, hogy képes legyen kérni a pénzt a számlámról ATM-ben, hogy képes lesz arra, hogy megkapja a pénzt a számlámról gyorsan, különböző helyeken.,fedél
Illetve: az adagoló tartalmaz készpénz
Ha: az ügyfél kéri a pénzt
Akkor: győződjön meg a számláját megterhelik
Illetve: győződjön meg a pénzt megkapja
Illetve: biztosítja a kártya visszatért
Elfogadási kritériumok 2:
Adott: a számla mínuszba
Illetve: a kártya érvényes
Ha: az ügyfél kéri a pénzt
Akkor: biztosítja az elutasító üzenet jelenik meg,
Illetve: győződjön meg a pénz nem nélkülözhető
Szabály-orientált elfogadási kritériumok format
egyes esetekben, nehéz, hogy illeszkedjen elfogadási kritérium, hogy az Adott/Ha/Akkor szerkezete., Például a GWT aligha lenne hasznos a következő esetekben:
- olyan felhasználói történetekkel dolgozik, amelyek leírják a rendszerszintű funkciókat, amelyek más minőségbiztosítási módszereket igényelnek.
- az Elfogadási Kritériumok célközönségének nincs szüksége a teszt forgatókönyvek pontos részleteire.
- a GWT forgatókönyvek nem felelnek meg egy szolgáltatás tervezési és felhasználói élménybeli korlátainak leírására. A fejlesztők számos kritikus részletet hiányozhatnak.
ezeket az eseteket szabályorientált AC formátumban kezelheti.,
a szabályorientált forma azt jelenti, hogy van egy szabálykészlet, amely leírja a rendszer viselkedését. E szabályok alapján konkrét forgatókönyveket rajzolhat.
általában az ezzel az űrlappal összeállított kritériumok egyszerű golyólistának tűnnek. Vessünk egy pillantást egy példára.
példa
felhasználói történet: felhasználóként egy keresési mezőt szeretnék használni egy város, név vagy utca beírásához, hogy megtaláljam a megfelelő szállodai lehetőségeket.,
alapvető keresési felület elfogadási kritériumai
- a keresési mező a felső sávra kerül
- a keresés akkor kezdődik, amikor a felhasználó rákattint a”Keresés “
- a mező szürke színű szöveggel rendelkező helyőrzőt tartalmaz: “hová mész?”
- A helyőrző eltűnik, ha a felhasználó elkezdi beírni
- Keresés ha a felhasználói típusok, város, szálloda neve, utca, vagy kombinált
- Keresés az angol, francia, német, ukrán
- A felhasználó nem írja be több mint 200 szimbólumok
- A keresés nem támogatja a speciális szimbólumok (karakter)., Ha a felhasználó beírt egy speciális szimbólumot, jelenítse meg a figyelmeztető üzenetet: “a keresési bemenet nem tartalmazhat speciális szimbólumokat.”
egyéb formátumok
a legtöbb felhasználói történetet a fent említett két formátum fedheti le. Ön azonban kitalálhatja saját elfogadási kritériumait, mivel azok a céljaikat szolgálják, világosan angolul íródnak, és nem lehet félreértelmezni. Egyes csapatok egyszerű szöveget is használnak.,
néha a kritériumokat a rendszer viselkedésének példájaként lehet megadni:
Mark Levison egyszerű AC-készlet az erős jelszavak számára agilepainpainrelief.com
Ez a megközelítés egyértelmű iránymutatásokat ad a jelszó funkció teszteléséhez.
felelős szerepek és az Elfogadási Kritériumok létrehozásának módja
a kritériumok egy részét a termék tulajdonosa határozza meg és írja meg, amikor létrehozza a termék lemaradását. A többieket pedig a csapat tovább határozhatja meg a sprinttervezés utáni felhasználói történetek megbeszélései során., Nincsenek szigorú ajánlások a kritériumok írásáért felelős személy kiválasztására. Az ügyfél dokumentálhatja azokat, ha bőséges műszaki és termékdokumentációs ismeretekkel rendelkezik. Ebben az esetben az ügyfél a kölcsönös félreértések elkerülése érdekében tárgyalja a kritériumokat a csapattal. Ellenkező esetben a kritériumokat Terméktulajdonos, üzleti elemző, követelményelemző vagy projektmenedzser hozza létre.,
A folyamat azzal kezdődik, hogy a felhasználó történet rangsorolása, a végén tárgyalási részletek az egész csapat
Fő kihívások, valamint a legjobb gyakorlatok az írás elfogadási kritériumok
Elfogadási kritériumok, mintha ők nagyon könnyű írni. Az egyszerű formátumok ellenére az írás sok csapat számára kihívást jelent. Vessünk egy mélyebb pillantást a legjobb gyakorlatokra, amelyek segítenek elkerülni a gyakori hibákat.
dokumentum kritériumok a fejlesztés előtt. Az elfogadási kritériumokat a tényleges fejlesztés megkezdése előtt dokumentálni kell., Ily módon a csapat valószínűleg előre megragadja az összes ügyféligényét. Kezdetben elegendő néhány felhasználói történet kritériumait beállítani, hogy kitöltse a holtjátékokat két sprintre(ha Scrumot vagy hasonló módszert gyakorol). Mindkét félnek meg kell állapodnia. Ezután a dokumentált elfogadási kritériumokat a fejlesztők használják a műszaki folyamat megtervezéséhez.
ne tegye túl szűkre az AC-t. Az Elfogadási Kritériumok túlságosan specifikusak lehetnek a fejlesztők számára. Ennek elkerülése érdekében ne feledje, hogy az AC-nek közvetítenie kell a szándékot, de nem végleges megoldást., Ráadásul, keskeny AC lehet megfosztott több felhasználói viselkedés, amely nem terjed ki.
tartsa a kritériumokat elérhető. Ez a pont szorosan metszi az előzőt. A hatékony Elfogadási Kritériumok meghatározzák az elfogadható minimális funkcionalitást, amelyet képes szállítani. De abban az esetben, ha megadja magát az összes apró részlet leírásához, fennáll annak a veszélye, hogy csapata több száz kis feladattal elakad.
az AC mérhető és nem túl széles. A széles körű Elfogadási Kritériumok homályossá teszik a felhasználói történetet., A hatékony Elfogadási Kritériumoknak körvonalazniuk kell a munka körét, hogy a fejlesztők megfelelően megtervezhessék és becsülhessék erőfeszítéseiket.
kerülje a műszaki részleteket. Mint már említettük, az elfogadási kritériumokat egyszerű angol nyelven kell írni. Ez mindenki számára egyértelművé és könnyen érthetővé teszi őket: előfordulhat, hogy az érdekelt felek vagy a vezetők nem rendelkeznek technikai háttérrel.
konszenzus elérése. Ugyanez a probléma lehet megoldani másképp egy csapat és az érdekeltek, attól függően, hogy azok vantage pontokat. Győződjön meg róla, hogy kommunikálta az AC-t az érdekelt felekkel, és kölcsönös megállapodásra jutott., Ugyanez vonatkozik a csapat tagjaira is. Mindenkinek felül kell vizsgálnia az AC-t, meg kell erősítenie, hogy megérti és egyetért minden sorral.
írható tesztelhető AC. Ez lehetővé teszi a tesztelők számára, hogy ellenőrizzék, hogy minden követelmény teljesül-e. Ellenkező esetben a fejlesztők nem fogják megérteni, hogy a felhasználói történet befejeződött-e.
Final word
ne hagyja figyelmen kívül az elfogadási kritériumokat, mivel azok-egyszerűek és megközelíthetőek – egyszerre több problémát is megoldanak., Dokumentálják az ügyfelek elvárásait, biztosítják a végfelhasználói perspektívát, tisztázzák a követelményeket, megakadályozzák a kétértelműséget, végül segítenek a minőségbiztosításban annak ellenőrzésében, hogy teljesülnek-e a fejlesztési célok. Függetlenül attól, hogy agilis módszereket használ-e vagy sem, feltétlenül válassza ki a legjobb formátumot, vagy kísérletezzen a sajátjaival. A különböző típusú felhasználói történetek és végül funkciók megkövetelhetik, hogy eltérjenek az Ön számára működő újak tesztelésétől, ez egy jó gyakorlat.