A tesztelési stratégia bevált gyakorlatai egy Scrum csapat számára

A Scrum mínusz a vizsgálati terv megegyezik a szteroidok POC-jával.

Manapság a legtöbb sikeres projekt a koncepció bizonyításával (POC) kezdődik, egy ötlet viszonylag kis méretű értékelésével, ahol először a kiválasztott technológiát és funkciócsomagot ellenőrzik, értékelik az üzleti felhasználókra gyakorolt ​​lehetséges hatásokat, majd amint bebizonyosodik. befektetésre érdemes, egy teljes méretű projektcsapatot bíznak meg a teljes értékű termék megtervezésével és leszállításával, valamint a termelésbe történő bevezetésével.

Ez a tökéletes eset egy Scrum csapat számára. A csapat gyorsan fejlesztheti a prototípust, minden egyes sprintben jelentős új funkciókat adva hozzá, míg az üzleti felhasználók valós idejű, gyors előrehaladást és az ötlet felépítését a semmiből mindössze 10 sprint alatt láthatják. Erős benyomást hagy maga után (ami egyébként a POC fő célpontja), de van egy jelentős tulajdonsága is – minimális vagy semmilyen tesztelési tevékenység, és a tesztelési folyamatra gondolni is csak vicc lenne.

Ez nem szórakoztató tevékenység egy Scrum csapaton belül, és az embereknek leginkább tetszeni fog az ötlet, hogy lelassítási folyamatok nélkül kell fejleszteni. Alapvetően ez az, amit minden tesztelési tevékenység implicit módon végez. És ki az, aki szükségtelen lassúságra vágyik azalatt az idő alatt, amikor a legjobban le kell nyűgöznünk a végfelhasználót?

Azt az állapotot, ami akkor következik be, ha a projektcsapat a POC periódus lejárta után is ugyanúgy folytatja a munkát, amit a szteroidokon használt POC-nak szoktam nevezni – egy termelési rendszer, amely méretében és jellemzőiben növekszik, de továbbra is úgy viselkedik, mint egy POC – egy teljes termék, rejtett hibák és feltáratlan saroktokok, amelyek csak komoly összeomlásra várnak.

Ám mielőtt áttérne, a csapatnak nehezebb dolga lesz sprintről sprintre lépést tartani a stabil kiadásokkal, mivel a gördülő problémák megoldása csak bonyolultabb lesz.

Íme néhány olyan technika, amelyek beváltak, amikor hasonló problémákkal küzdöttem, és amelyekről úgy gondolom, hogy a szilárd tesztelési folyamatok végrehajtásának legjobb gyakorlataiként nevezhetők, anélkül, hogy túlságosan megzavarnák a fejlesztési folyamatot – mert mindannyian ez akarunk lenni egy Scrum csapat.

Ossza el a fájdalmat

Hol máshol kezdjük a fölösleges zaklatást, mint a fájdalom felosztását :).

És ez alatt azt értem, hogy olyan tervet kell készíteni, amely itt-ott kis további tevékenységet igényel a fejlesztőktől, de amely idővel nagymértékben hozzájárul a közös cél eléréséhez, fokozatosan, de következetesen.

#1. Készítsen egységteszt kódot minden létrehozott új kódrészlethez

Ha sikerül meggyőznie a scrum csapatait, hogy a Definition Of Done záradékába egységteszteket adjanak hozzá a sprint során létrehozott minden egyes új kódhoz, akkor ez hosszú távon nagy eredménynek számít.

Az okok meglehetősen nyilvánvalóak:

Ez arra kényszeríti a fejlesztőket, hogy gondolkodjanak a kód különféle nem szabványos útvonalain. –

  • Az ilyen egységtesztek automatizált DevOps-folyamatokhoz csatlakoztathatók, és minden egyes fejlesztői vagy tesztkörnyezetbe történő telepítéskor végrehajthatók. Ezenkívül a folyamatból származó metrikák könnyen exportálhatók, majd felhasználhatók az üzleti felhasználók számára a forráskódhoz közvetlenül kötött tesztesetek százalékos lefedettségének bemutatására.
  Hogyan böngészhet a rejtett kategóriák között a Netflixben [Chrome]

A legfontosabb az, hogy nagyon hamar elkezdjük. Minél később kezdik el fejleszteni az egységteszteket, annál zavaróbb lesz a fejlesztők számára, hogy egy sprinten belül hozzáadják őket.

  • Jelentős erőfeszítést igényel a már meglévő kód egységteszteinek visszafelé történő fejlesztése. Előfordulhat, hogy a kód egyes részeit egy másik fejlesztő hozta létre, és a jelenlegi fejlesztő számára nem teljesen világos, hogy pontosan hogyan kell működnie minden egyes kódrészletben. Egyes esetekben odáig fajulhat, hogy egy egységteszt hozzáadása a módosított kódhoz több időt vesz igénybe, mint a sprint jellemzőváltásának kidolgozása (amit a sprinttervezés során biztosan senki nem számolt ki).

#2. Készítsen rutint az egységtesztek minden részének végrehajtására a fejlesztői környezetben

Még az új kód Master ágba történő egyesítésére vonatkozó lehívási kérés létrehozása előtt is szokásos tevékenységnek kell lennie a szolgáltatáskód és az egységteszt kódjának tesztelése a fejlesztői környezetben. Ezzel biztosítható, hogy:

  • Az egységteszt kódja valójában minden alkatrésznél működik (végül, ez csak egy újabb kód, amelyet ellenőrizni kell). Ezt a lépést gyakran teljesen kihagyják. Valahogy azt feltételezik, hogy ha az egységteszt amúgy is csatlakoztatva van a DevOps-folyamathoz, akkor végül alapértelmezés szerint végre kell hajtani és tesztelni kell valahol. Ez azonban nem más, mint a problémákat a sprinttevékenység felsőbb szintjeire tolni, ahol a csapatnak általában kevesebb ideje és több stressze van minden elkötelezett történet befejezésére.
  • Az új funkciókódot a fejlesztő tesztelte az alapvető funkciók szempontjából. Nyilvánvalóan ettől a teszttől nem várható el, hogy az üzleti funkcionalitás teljes mértékben ellenőrizve legyen, de legalább ez a teszt megerősíti, hogy a kód a fejlesztő szándéka szerint viselkedik (egyelőre figyelmen kívül hagyva azt a tényt, hogy az üzleti logika helytelenül érthető a fejlesztés során).

#3. Az egységteszt végrehajtása a kód fő ágba való egyesítése után várható

Az egy dolog, hogy a helyi ágon van funkcionális kód (ahol a fióktulajdonoson kívül senki nem fejleszt új szolgáltatást), de teljesen más, ha ugyanaz a kód működik a pull kérés után, és beolvad a master ágba.

A fő ág tartalmaz változtatásokat a Scrum csapat többi tagjától, és még ha az ütközések meg is oldódtak, és minden rendben van, a kód az összevonás és a konfliktusok feloldása után alapvetően még mindig nem tesztelt kódrészlet, és kockázatos továbbküldeni anélkül, hogy ellenőrizné. még mindig jól működik.

Tehát ami itt hatékonynak bizonyult, az az, hogy egyszerűen megkérjük, hogy ugyanazt az egységtesztet hajtsák végre – már korábban a fejlesztői környezetben – a környezeten is, amely a fő ágkód verzióból épül fel.

A fejlesztők számára ez egy további lépés lehet, amit be kell építeniük az életükbe, de ez nem olyan nagy erőfeszítés, hiszen ebben az esetben semmi újat nem kell kitalálni – elég újra végrehajtani azt, amit egyszer már megcsináltak.

Nos, ez a lépés egy adott esetben kihagyható:

  • A DevOps folyamatokban lévő automatizált egységtesztek olyan átfogóak, hogy már lefedik a teljes manuális tesztelést, amit ráadásul végrehajtanak.

Bár ennek az állapotnak az elérése mindenképpen megvalósítható, a való életben nem tapasztaltam ilyen állapotot. Valószínűleg túl időigényes lenne a fejlesztők számára ilyen mélyen részletes automatizált egységtesztek létrehozása. Könnyen elfogadhatatlanná válhat, hogy a termék tulajdonosa ennyi időt hagyjon a csapatnak erre a tevékenységre, mivel ez kifejezetten befolyásolná az egy sprinten belül leadott történetek számát.

  Hogyan frissítsünk Ubuntu 21.04-re

A sprinttartalom preferálása azonban soha nem lehet ürügy arra, hogy ne végezze el az egységteszteket, vagy akár minimalizálja azokat. Ezzel a csapat ismét olyan állapotba konvertálja, hogy a kódból túl sok egységteszt-lefedettség hiányzik, és akkor a felzárkózáshoz már túl késő lehet (megint az egységteszt elvégzésének nagyobb erőfeszítése, mint a tényleges kódváltás sprinthez).

Mindezen okok miatt azt javaslom, hogy habozás nélkül hajtsák végre újra az egységteszteket a mesterkód verzión. Ez olyan alacsony erőfeszítés ahhoz képest, hogy milyen értéket fog hozni.

Ez elvégzi az utolsó ellenőrzést a fő ág készenlétére a kiadási tesztelési fázisra. Ezenkívül segít megtalálni a legtöbb technikai hibát (pl. olyan hibákat, amelyek megakadályozzák a forráskód sikeres végrehajtását a sikeres végéig), így a következő szakaszban csak az üzleti funkciók ellenőrzésére kell koncentrálni.

Készüljön fel a funkcionális tesztelésre

Az összes korábbi tesztelési tevékenységnek egy konkrét következtetéshez kell vezetnie – a fő ág kódja mentes a technikai hibáktól, és problémamentesen végrehajtható a végpontok közötti funkcionális folyamok számára.

Ez egy olyan fázis, amelyet egyetlen ember is könnyedén lefed, és ehhez még technikai háttér sem kell.

Valójában sokkal jobb, ha ezt olyan valaki hajtja végre, aki nem kapcsolódik a fejlesztőhöz, de funkcionálisan tisztában van azzal, hogy az üzleti felhasználók milyen viselkedést várnak el a kódtól. Két fő tevékenységet kell végrehajtani:

#1. Új sprinttörténetek célzott funkcionális tesztje

Ideális esetben minden sprintnek valamilyen új funkciót kell hoznia (sprint cél növekmény), amely korábban nem volt, és ezért azt ellenőrizni kell. Fontos, hogy az új szoftver olyan mértékben működjön, hogy most már az üzleti felhasználók is örüljenek neki, hiszen nyilván az utolsó sprintben is alig várták :).

Olyan szomorú élmény, amikor végre bejelentették a (rég) ígért funkció megjelenését, de a napokban kiderül, hogy valójában nem működik jól.

Ezért kulcsfontosságú az új sprintfunkciók megfelelő tesztelése. Ennek sikere érdekében bevált gyakorlat, ha előre összegyűjtjük a fontos tesztelési eseteket az érintett érdekelt felektől (akár a termék tulajdonosától, akár a végfelhasználóktól), és listát készítünk az összes ilyen tesztesetről, amelyek a belső tartalomhoz szükségesek. a sprint.

Ez első pillantásra elsöprőnek tűnhet, de tapasztalataim szerint ismét teljesen kezelhető egyetlen ember által. Mivel a sprintek többnyire meglehetősen rövidek (például két hetes periódus rövidek), szinte soha nincs túl sok új tartalom, mivel a sprint további tevékenységeket is tartalmaz, például technikai adósságtörténeteket, dokumentációt, tervezési/spike történeteket stb.

Ezután teszteseteket hajtanak végre azzal a céllal, hogy elsősorban a kívánt funkcionalitást ellenőrizzék. Ha bármilyen probléma adódik az eredménnyel, csak a megfelelő fejlesztőt (azt, aki az adott hibához kapcsolódó változtatások tulajdonosa) keresik meg, hogy remélhetőleg gyorsan megoldják a problémát.

Ily módon a fejlesztők minimális időt töltenek a funkcionális teszteléssel, és továbbra is a leginkább kedvelt tevékenységekre koncentrálhatnak.

#2. Regressziós tesztesetek végrehajtása

A funkcionális tesztelés másik része annak biztosítása, hogy minden, ami eddig működött, a következő kiadás után is működni fog. Erre valók a regressziós tesztek.

A regressziós tesztek tesztesetei a legjobbak, ha rendszeresen karbantartják és minden kiadás előtt újra átnézik őket. A konkrét projekt sajátosságai alapján a legjobb, ha ezek egyszerűek, ugyanakkor lefedik az egész rendszeren áthaladó alapvető funkciók és fontos végpontok közötti folyamatok többségét.

Általában minden rendszerben vannak olyan folyamatok, amelyek sok különböző területet érintenek, ezek a legjobb jelöltek a regressziós tesztesetekhez.

  Hogyan nézzünk amerikai tévét az Egyesült Államokon kívülről

Egyes esetekben a regressziós tesztek implicit módon a sprint új jellemzőit is lefedik, például ha a sprintben az új történet megváltoztatja a meglévő folyam egy bizonyos részét.

A legtöbb esetben tehát egyáltalán nem túl bonyolult regressziós tesztek elvégzése az új sprint történetek funkcionalitástesztjei mellett, különösen akkor, ha ezt minden éles kiadás előtt rendszeresen megteszik, és az éles kiadások gyakorisága sem túl kicsi.

Ragaszkodjon a minőségbiztosítási tesztek végrehajtásához minden gyártási kiadás előtt

A minőségbiztosítási (QA) teszt az utolsó lépés a gyártásba való bevezetés előtt, és gyakran ezt a tesztet kihagyják, mivel nem fontos. Főleg, ha a scrum csapatot agresszíven irányítják az új tartalomért.

Még az üzleti felhasználók is azt mondják, hogy az új funkciók iránt érdeklődnek, nem annyira a funkcionalitás megőrzése vagy a hibák számának alacsonyan tartása iránt. De még egyszer – idővel ez a fő oka annak, hogy a fejlesztőcsapatnak végül le kell lassítania, és akkor az üzleti felhasználók úgysem kapják meg, amit kérnek.

A minőségbiztosítási tesztet kizárólag a Scrum csapatán kívüli személyek hajthatják végre, ideális esetben maguk az üzleti felhasználók egy dedikált környezetben, amely a lehető legközelebb van a jövőbeli termeléshez. Alternatív megoldásként a termék tulajdonosa helyettesítheti itt a végfelhasználókat.

Mindenesetre ennek egy tiszta, működőképes tesztnek kell lennie a végfelhasználó szemszögéből, anélkül, hogy bármiféle kapcsolat lenne a dev Scrum csapatával. Ez egy végső képet ad a termékről, és olyan módon kerül felhasználásra, amire a scrum csapatból senki sem számított (egyáltalán nem ideális eset, de biztosan megtörténhet). Még van idő az utolsó pillanatban történő korrekciókra.

Alternatív megoldásként kiderülhet, hogy a scrum csapata nem értette meg jól az elvárásokat, és ebben az esetben legalább egy nyomon követési tervben tudunk megegyezni, még jóval a tényleges gyártási megjelenés előtt. Ez ismét nem egy ideális eset, de sokkal jobb, mintha beismernénk a kudarcot közvetlenül a sikeres gyártási kiadás bejelentése után.

Innen merre tovább?

Ha ezeket a gyakorlatokat alkalmazza a napi scrum-munkában, akkor komolyan stabilabb és kiszámíthatóbb sprintkiadási szokásokhoz vezethet, anélkül, hogy késlelteti a gyártási kiadásokat, vagy az egész sprintet csak a következő kiadásra való felkészüléssel töltené, vagy akár anélkül, hogy a scrum csapat minden tagját arra kényszerítené, hogy tegyen valamit, amit nem. Nem igazán szeretem, vagy nem tudom, hogyan kell hatékonyan csinálni a sprint nagy részében.

De itt biztosan nem kell megállnia.

A teljesítményteszt bevonása az egyik téma, amelyet itt meg kell nevezni. Ezeket gyakran figyelmen kívül hagyják, vagy szükségtelennek tartják, és a „scrum-tevékenységek optimalizálásának” első körében elveszik. Mindazonáltal mindig is kételkedtem abban, hogyan várható el a gyártási rendszer idővel történő fejlődése, ha nem ellenőrzik rendszeresen a teljesítményét.

Egy szinttel feljebb lépni az automatizált tesztek bevezetését is jelenti.

Az automatizált tesztek egy csoportjával már foglalkoztam (a folyamatban lévő egységtesztek). Mindazonáltal teljes körű, teljes körű regressziós teszteket fejleszthet ki, amelyek teljesen automatizáltak, és a tesztkörnyezetbe történő minden egyes telepítés után maguk is végrehajthatók. Ez még jobban felszabadítaná a fejlesztői scrum csapatot, de az ilyen automatizált tesztek fejlesztéséhez és karbantartásához dedikált csapatra van szükség. Ez állandó munkává válna, mivel a termelési kód megváltoztatásakor egyes meglévő automatizált tesztek érvénytelenné válhatnak, ezért frissíteni kell őket, hogy tovább működjenek a folyamatban. Ez egy olyan erőfeszítés, amelyet csak kevesen hajlandóak fizetni, a dev scrum csapat számára azonban óriási előnyök származnának.

Ezek olyan témák, amelyek messze túlmutatnak a jelen cikk hatókörén, és kitalálják a megfelelő ütemezést és időzítést az egyes itt említett teszttípusokhoz – így egy sprint ablakon belül megteheti. Legközelebb is szívesen merülök!