- Bevezetés a balra váltás fogalmába
- Mi az a Shift Left tesztelés?
- Hogyan befolyásolja a Shift Left a szoftverfejlesztést?
- Mit kell másképp csinálniuk a tesztelőknek a Shift Leftben?
- A Shift Left tesztelés előnyei
- Következtetés
- Ajánlott olvasmányok
A koncepció Szoftvertesztelés fokozatosan került bevezetésre, amikor a gyártásból származó hibák kezdték megterhelni a projekt költségvetését, és így a "funkcionális tesztelés" egy nagyon sovány tesztelői csapattal lépett életbe. Abban az időben mindössze két tesztelő voltunk egy 20 fős fejlesztői csapattal szemben.
Az informatikai ipar a vízeséses modell szerint kezdte el a szoftverfejlesztést, amelyben, mint tudjuk, a szoftverfejlesztési életciklus a következő sorrendben halad.
Ha tehát balról jobbra haladunk, akkor a tesztelési fázis a szoftverfejlesztési életciklus jobb szélén helyezkedik el.
Bevezetés a balra váltás fogalmába
Egy idő után az emberek rájöttek, hogy milyen fontosak a Szoftvertesztelés és a "tesztelési fázis" jobb szélsőjobbra vagy a szoftverfejlesztési életciklus végén tartásának hatása. Ez a felismerés azért történt, mert a jobb szélsőjobbra és a végén azonosított hibák költsége nagyon magas volt, és óriási erőfeszítéseket tettek, és túl sok időt igényelt a javításuk.
Voltak olyan esetek, amikor a szoftverre fordított sok idő és erőfeszítés után, a végén azonosított kritikus hiba miatt a kritikus fontosságú szoftvert nem lehetett piacra dobni, ami hatalmas veszteséget eredményezett.
Ezért a hiba azonosítása miatt az utolsó szakaszban vagy késett a kiadás, vagy időnként a szoftvert elvetették, figyelembe véve a javításukhoz szükséges erőfeszítéseket, ami nem igazán érte meg.
"A hibák kevésbé költségesek, ha korán észlelik őket.
Ez a felismerés és a nagy lecke, amit megtanultunk, nagy forradalmat hozott a szoftveriparban, és egy új koncepciót hozott létre, amit úgy hívnak. 'Balra váltás' , ami azt jelenti, hogy a "tesztelési fázist" jobbról balra kell tolni, vagy a tesztelést minden szakaszban be kell vonni, és a tesztelőket végig be kell vonni.
A Shift Left tesztelés azt is jelenti, hogy ne csak a végén teszteljünk, hanem folyamatosan.
Mi az a Shift Left tesztelés?
Először is, a "balra tolódás" elve támogatja a A tesztelő csapat együttműködik az összes érdekelt féllel a korai szakaszban. A szoftverfejlesztés fázisában. Ezért világosan megértik a követelményeket és megtervezik a teszteseteket, hogy a szoftver "gyorsan hibázzon", és a csapat a lehető leghamarabb kijavíthassa a hibákat.
A Shift Left megközelítés nem más, mint a tesztelők sokkal korábbi bevonása a szoftverfejlesztési életciklusba, ami viszont lehetővé tenné számukra, hogy megértsék a követelményeket, a szoftvertervezést, az architektúrát, a kódolást és annak funkcionalitását, kemény kérdéseket tegyenek fel az ügyfeleknek, az üzleti elemzőknek és a fejlesztőknek, tisztázzák a helyzetet, és ahol csak lehet, visszajelzést adjanak a csapat támogatására.
Ez a részvétel és megértés arra készteti a tesztelőket, hogy teljes körű ismereteket szerezzenek a termékről, átgondolják a különböző forgatókönyveket, és valós idejű forgatókönyveket tervezzenek a szoftver viselkedése alapján, ami segít a csapatnak a hibák azonosításában még a kódolás előtt.
Hogyan befolyásolja a Shift Left a szoftverfejlesztést?
A Shift Lift megközelítés több szempontból is befolyásolja a szoftverfejlesztést.
Az alábbiakban a Shift Left néhány kulcsfontosságú pontja található:
- A Shift Left megközelítés a következőkre összpontosít a tesztelők bevonása minden, de leginkább a kritikus szakaszokba a program Ez lehetővé teszi a tesztelők számára, hogy a hibák felderítéséről a hibák megelőzésére összpontosítsanak, és a program üzleti céljainak megvalósítására.
- A shift Left megközelítés biztosítja, nagy jelentőséggel bír a tesztelés amivel a tesztelők szerepe és felelősségi köre óriási mértékben megnövekszik.
- A tesztelői csapat felelősségének növekedésével a csapat egyszerűen nem koncentrál a következőkre "A szoftver tesztelése a hibák azonosítására , de proaktívan együttműködik a csapattal már a kezdeti szakaszoktól kezdve a robusztus és hatékony tesztelési stratégia megtervezésében és kiépítésében, nagyszerű tesztvezetést és útmutatást nyújtva a csapatnak, a termék hosszú távú jövőképére összpontosítva, ahelyett, hogy csak a tesztelési munkáért vállalná a felelősséget.
- A Shift Left megközelítés a lehetőség a tesztelők számára, hogy először megtervezzék a teszteket , ahol a tesztek teljes mértékben az ügyfélélményre és az elvárásaikra összpontosítanak, ami viszont lehetővé teszi a fejlesztők számára, hogy a szoftvert e tesztek alapján fejlesszék, és így megfeleljenek az ügyfél igényeinek.
- A Shift Left megközelítés nem csak a tesztelőkkel ér véget. A bérbeadásra való áttérés és a tesztelési tevékenységek folyamatos végrehajtása szintén a fejlesztők nagyobb felelősséget vállalhatnak a kódjukat, és növeljék a teszteléssel kapcsolatos felelősségüket.
- A shift Left megközelítés a következőket is ösztönzi A tesztelők a viselkedésvezérelt fejlesztés (BDD) és a tesztvezérelt fejlesztés (TDD) bevezetése. , ami segít megelőzni a hiba szoftverbe való beépülését.
- Shift Left Tesztelés az agilis környezetben: A Shift Left megközelítés támogatja a formálódást Agilis Scrum csapatok, amelyek kötelezően tartalmaznak tesztelőket is a többi szereppel együtt, és magában foglalja a tesztelők rendszeres stand up hívások, egyéb interakciók, felülvizsgálati ülések, amelyek a tesztelők több információt a programmal kapcsolatban, és így lehetővé tette számukra, hogy átadják és bevonják a szoftver részletes elemzésébe, és gyors visszajelzést adnak, ami segítene a szoftverben megalapozott hibák megelőzésében.
A Shift Left tesztelés során a tesztelőknek a következőket kell elvégezniük 'Vegyen részt korán' , a lehető legkorábban, és vegyen részt a megbeszéléseken, és működjön együtt az ötletekkel, követelményekkel kapcsolatban minden olyan szakaszban, ahol a szakasz eredménye hatással van a végső eredmény értékére, valamint segítsen a projektnek a kockázatok előzetes azonosításában és mérséklésében.
Mit kell másképp csinálniuk a tesztelőknek a Shift Leftben?
Az alábbiakban néhány kulcsfontosságú tényezőt kell megjegyezni, hogy a tesztelők mit csinálnak másképp a következőkben. Balra váltás stratégia:
#1) A tesztcsapatnak a következőkre van szüksége már a projekt indításától kezdve a rendszer korai szakaszában bekapcsolódni a rendszerbe a csapat többi tagjával és az üzletággal való integráció fejlesztése érdekében, hogy minden szakaszban hasznos inputokat szolgáltat a szoftverfejlesztés.
#2) A tesztcsapatnak együtt kell működnie a Business & Operations csapattal és a a program tisztázása és világos képet adnak az igényekről, valamint segítenek a hatékony tervezésben az erőforrások felfutási igényei, a képzési igények és a tesztelési eszközigények tekintetében a program jóval előre.
#3) A tesztcsapatoknak már a szoftverfejlesztés korai szakaszában kapcsolatba kell lépniük az összes üzleti érdekelttel, hogy a termék világos láthatósága & egységes tesztelési stratégia kialakítása és tervezze meg az optimalizált tesztelési erőfeszítéseket, elemezze a tesztkörnyezetektől, harmadik felektől, csonkoktól stb. való függőséget, valamint készítsen robusztus automatizálási stratégiát és keretrendszert, és készítsen hatékony tesztadat-kezelési tervet.
#4) A tesztcsapatnak együtt kell működnie a csapat többi tagjával a következők biztosításában nagyszerű tesztvezetés és útmutatás a csapat számára ezáltal szem előtt tartva a termék hosszú távú jövőképét, ahelyett, hogy csak a tesztelési tevékenységekért vállalná a felelősséget.
#5) A követelmények minden program sikerének kulcsa és alapja, és a jól meghatározott követelmények határozzák meg a projekt sikerét. A követelmények tervezési fázisában a tesztelők át kell tekinteni és elemezni kell a követelményeket bármilyen kétértelműség, jobb egyértelműség, teljesség, tesztelhetőség, elfogadási kritériumok meghatározása stb. miatt.
Azonosítani kell a hiányzó követelményeket is (ha vannak), és meg kell érteni a függőségeket és a végrehajtási stratégiákat. A világos követelmények segítenek a szoftvernek a "gyors meghibásodásban" és a hibák legkorábbi kijavításában.
#6) A követelmények kellő egyértelműségét és pontosságát a következők kiemelésével valós példák amelyek a használatban lévő funkciókat illusztrálják.
#7) A tesztelőknek részt vesz a tervfelülvizsgálati üléseken rendszeresen és megérti a terméktervezést és -architektúrát, és azonosítja a tervezési hibákat, alternatív tervezési lehetőségeket javasol, azonosítja a kiskapukat, és ennek megfelelően tesztforgatókönyveket hoz létre a tervek megtöréséhez.
#8) A tesztelőknek statikus tesztelést végez (felülvizsgálatok) jó előre, és adjon visszajelzést a kulcsfontosságú projektdokumentumokról, hogy a hibák ne kerüljenek be a szoftverbe, és ne szélesítsék ki később annak hatását.
#9) A tesztelő csapatnak együtt kell működnie a tervező és fejlesztő csapattal. a tesztelési forgatókönyvek előzetes biztosítása a kód fejlesztéséhez és minden lehetséges valós idejű forgatókönyvvel és üzleti folyamattal foglalkozik.
#10) A tesztcsapatnak meg kell terveznie erős és robusztus tesztforgatókönyvek hogy a tesztelés során csak néhány hiba kerüljön azonosításra, és a nagyobb hibák megelőzhetők legyenek a tesztelési fázisba való belépéskor.
#11) A tesztelőknek A lehető legkorábbi tesztelés , akár önálló, akár helyi rendszeren, hogy a hiba ne kerüljön a későbbi szakaszokba.
A "Shift Left" koncepció lényege a tesztelők számára az, hogy minden lehetséges eszközzel a lehető leghamarabb megtalálják a hibákat.
A Shift Left tesztelés előnyei
A Shift Left megközelítés az agilis manifesztum alapján működik, és számos előnnyel is rendelkezik.
Ezek a következők:
- Egyének és kölcsönhatások a folyamatok és eszközök felett.
- Működő szoftver átfogó dokumentációval szemben.
- Ügyfél-együttműködés a szerződéstárgyalások felett.
- Reagálás a változásra a terv követése helyett.
Láthatjuk, hogy míg a jobb oldali tételek értéket képviselnek, addig a bal oldali tételeket jobban értékeljük.
Nos, a Shift Left a tesztelés gondolatát a folyamat korábbi szakaszába helyezi, ami jobb és hatékonyabb tesztelést és a szoftver minőségének javítását eredményezi.
Dióhéjban a Shift Left tesztelési folyamat a következő:
- A hibák korai felderítése, ezáltal a projekt költségeinek csökkentése.
- Folyamatos tesztelés újra és újra a hibák csökkentése érdekében.
- Mindent automatizálni és javítani a piacra jutási időt.
- Az ügyfelek igényeire való összpontosítás és az ügyfélélmény javítása.
Következtetés
A 'Shift Left' koncepció hatalmas átalakulást hozott a teljes "tesztelési" szerepkör számára. Addig a tesztelés egyetlen fókusza csak a "hibák felderítése" volt, most pedig a "balra váltás" célja a tesztelés szempontjából egy olyan utazás, amely a következőkre irányul "Korai hibaérzékelés a statikus teszteléshez .
A Shift Left tehát egy nagy ugrás a szoftveriparban a szoftverfejlesztési módszertanban a piacra jutás gyorsasága, a szoftverminőség javítása és a "Time to Market" csökkentése felé.
A szerzőről: Ezt a cikket az STH csapattag írta Gayathri Subrahmanyam. A '90-es évek óta van a szoftvertesztelésben, éppen akkor, amikor a tesztelői szerepkör bevezetésre került az iparágban. Tesztelői karrierje során rengeteg TMMI értékelést, teszt-iparosítási munkát és TCOE felállításokat végzett, emellett tesztkiszállításokat kezelt és DevOps gyakorlatokat vezetett be egy hatalmas megbízás esetében. De elmondása szerint a tanulás sosem áll meg...
Ossza meg velünk gondolatait/javaslatait az alábbi megjegyzés rovatban.
PREV Tutorial