tökéletes termék bemutatása az ügyfél számára minden szervezet végső célja. De tudtad, hogy volt idő, amikor a tesztelés még csak nem is része a szoftverfejlesztési életciklusnak (SDLC)?

semmi sem teszi ki az ügyfeleket, mint a hibával töltött felhasználói élményt. Tehát amikor a vállalkozások ezt felismerték,elkezdték a tesztelést az SDLC kötelező részeként. Azóta a tesztelés minden szervezet szerves részévé vált.

a tesztelés kompetenciája az elmúlt évtizedekben fejlődött. Jelenleg a tesztelés nem arról szól, hogy hibákat jelentsen a fejlesztőnek. Széles körű, kötelező szakasz a projekt kezdeti szakaszaiból.

az agile segítségével az alkalmazás tesztelési életciklusa folyamatorientáltabbá és sokoldalúbbá vált. Általában egy vállalkozás teljes fókusza csak az SDLC-re összpontosít. És ennek a folyamatnak egy részét vizsgálják. De itt az ideje, hogy a cégek rájöjjenek, hogy a szoftver tesztelésének saját életciklusa van.

ebben a bejegyzésben részletesen megvizsgáljuk a szoftver tesztelési életstílusának (STLC) szerepét. Tehát merüljünk be!

mi a szoftver tesztelési életciklusa?

először értsük meg az életciklus kifejezést, mielőtt belemennénk az összes részletbe. Az életciklus a változások sorrendje, amelyet az entitás az egyik formáról a másikra megy keresztül. Sok konkrét és homályos entitás megy keresztül egy sor változás az elejétől a végéig.

amikor a szoftver tesztelési életciklusáról beszélünk, a szoftver egy entitás. A szoftver tesztelési életciklusa a különböző tevékenységek végrehajtásának folyamata a tesztelés során.

Ezek a tevékenységek magukban foglalják a kifejlesztett szoftver ellenőrzését annak ellenőrzésére, hogy megfelel-e bizonyos követelményeknek. Ha bármilyen hiba van a termékben, a tesztelők a fejlesztőcsapattal dolgoznak. Bizonyos esetekben kapcsolatba kell lépniük az érdekelt felekkel, hogy betekintést nyerjenek a különböző termékspecifikációkba. A termék validálása és ellenőrzése szintén fontos folyamat az STLC-ben.

SDLC vs. STLC

a termék teljes utazását a kezdetektől a végtermékké válásig az SDLC gondoskodik. Az SDLC különböző fázisai közül a tesztelés az egyik legfontosabb. A szoftver tesztelése az SDLC része. Ennek a résznek megvan a saját életciklusa-STLC.

tehát hogyan különbözik az SDLC az STLC-től?

SDLC

• Összpontosítani épület egy termék
• Egy szülő folyamat
• Megértése felhasználó követelmény, valamint az épület egy termék, amely segít, hogy a felhasználók
• SDLC fázis befejeződött a vizsgálat előtt
• végső cél az, hogy telepíteni a magas minőségű termék, hogy a felhasználók segítségével

STLC

• Összpontosítani vizsgálat egy termék
• a gyermek SDLC folyamat
• Megértése, fejlesztési követelményeket, valamint biztosítja, hogy a termék működik, mint várható
• STLC fázis megkezdése után fázisai SDLC elkészült
• végső cél az, hogy megtaláljuk a bogarak a termék jelentés a Fejlesztőcsapatnak a hibajavításhoz

ezek az alapvető különbségek az SDLC és az STLC között. Most értsük meg alaposan az STLC-t.

mi az STLC szerepe?

most, hogy megvan a lényege annak, hogy mi a szoftver tesztelési életciklusa, vessünk egy pillantást arra, hogy miért elengedhetetlen. Még ha egy cég a legjobb programozók, fejlesztők, akkor köteles hibázni. Az STLC fő feladata, hogy megtalálja ezeket a hibákat, és kijavítsa azokat. Az STLC lebonyolításának fő célja a termékminőség fenntartása.

Elmúltak azok a napok, amikor a középszerű tesztelés volt a trend. A mai világban a vállalkozásoknak részletes vizsgálatokat kell végezniük.

a tervezéstől és a kutatástól a végrehajtásig és a karbantartásig minden fázis döntő szerepet játszik egy termék tesztelésében.

az SDLC a termék minőségének biztosításáról szól. Minden alkalmazásnak különböző tulajdonságai vannak, mint például a megbízhatóság, a funkcionalitás és a teljesítmény. Az STLC pedig segíti ezeket a tulajdonságokat, és megkönnyíti az ideális végtermék szállítását.

a kiváló minőségű termék hosszú távon alacsonyabb karbantartási költségeket eredményez. Az alkalmazás vagy szoftver stabilitása elengedhetetlen az új felhasználók csábításához. Ezen kívül a következetesen megbízható termékek segítenek a meglévő ügyfélkör megtartásában is. Ahhoz, hogy egy termék az üzleti életben maradjon, fontos, hogy az STLC minden fázisára összpontosítson.

A szoftver tesztelési életciklusának fázisai

a szoftver vagy alkalmazás minden moduljának validálása elengedhetetlen a termék pontosságának és pontosságának biztosításához. Mivel maga a szoftver tesztelése bonyolult folyamat, a tesztelők fázisokban végzik el. A bonyolultságok felbukkanhatnak, ha a tesztelésnek nincs szervezete. A bonyolultság magában foglalhatja a megoldatlan hibákat, a nem észlelt regressziós hibákat, vagy a legrosszabb esetben egy modult, amely kihagyta a tesztelést, mert a határidő közelebb került.

az STLC minden fázisának van egy konkrét célja és célja. Ez magában foglalja a vizsgálati folyamat megindítását, végrehajtását és megszüntetését.

vessünk egy pillantást a szoftver tesztelési életciklusának különböző fázisaira részletesen.

Követelményelemzés

az értékes szoftver tesztelőinek meg kell nézniük, tanulmányozniuk és elemezniük a rendelkezésre álló specifikációkat és követelményeket. Bizonyos követelmények eredményeket hoznak azáltal, hogy bemeneti adatokkal táplálják őket. Ezek a követelmények tesztelhető követelmények. A tesztelők mind a funkcionális, mind a nem funkcionális követelményeket tanulmányozzák. Ezt követően ki kell választaniuk a tesztelhető követelményeket.

ebben a fázisban a tevékenységek közé tartozik a követelményelemzés és a vizsgálati követelmények azonosítása és rangsorolása. Ezek magukban foglalják mind az automatizált, mind a kézi tesztelésre vonatkozó követelményeket is.

van néhány dolog, amit tesztel, még akkor is, ha kifejezetten nem említik. Egy kattintás egy aktív gombra kell tennie valamit, a szöveges mező telefonszám nem fogadja ábécé benyújtott. Ezek a dolgok univerzálisak, és mindig tesztelni kell őket. De a követelményelemzési szakaszban a termékkel kapcsolatos konkrétabb részletek megismeréséről szól. Meg kell tanulnod, hogy a terméknek ideális állapotban kell lennie.

összefoglalva:

• értsd meg a termék várható kimenetét.
• azonosítsa a specifikációkban lévő kiskapukat.
• prioritások gyűjtése.
• automatizálási megvalósíthatósági ellenőrzések végrehajtása.

Teszttervezés

a második lépés a teszttervezés, a QA csapata pedig az összes szükséges tesztelési követelmény elemzése után hozza létre ezt a tervet. A termékkör megértése után körvonalazzák a hatókört és a célkitűzéseket. A csapat ezután elemzi a kockázatokat, és meghatározza az időbeosztásokat és a tesztkörnyezeteket, hogy stratégiát alkosson.

ezután a menedzsment véglegesíti az eszközöket, és szerepeket és felelősségeket rendel az egyénekhez. Egy hozzávetőleges idővonal is meghatározásra kerül, amellyel az egyes modulok tesztelését be kell fejezni.

összefoglalva:

• készítse el a vizsgálati terv dokumentációját.
• becsült idő és erőfeszítések.
• véglegesítése eszközök és platform.
• feladatok hozzárendelése csapatokhoz és egyénekhez.
• azonosítsa a képzési követelményeket

teszt tok tervezése és fejlesztése

fejlesztés és tervezés után itt az ideje, hogy a kreatív gyümölcslevek áramoljanak! A tesztterv alapján a tesztelők megtervezik és fejlesztik a teszteseteket. A vizsgálati eseteknek kiterjedteknek kell lenniük, és szinte az összes lehetséges esetet ki kell terjedniük. Minden alkalmazandó permutációt és kombinációt össze kell gyűjteni. Ezeket a teszteseteket rangsorolhatja azzal, hogy megvizsgálja, melyik közülük a leggyakoribb, vagy melyik befolyásolja a legjobban a terméket.

ezután jön a megadott követelmények ellenőrzése és érvényesítése a dokumentációs szakaszban. Az automatizálási szkriptek és tesztesetek felülvizsgálata, frissítése és jóváhagyása is e szakasz alapvető folyamatai. Ez a szakasz magában foglalja a különböző vizsgálati feltételek meghatározását bemeneti adatokkal és várható eredményekkel.

összefoglalva:

• kutatás és a termékkel kapcsolatos lehetséges intézkedések összegyűjtése.
• tesztesetek létrehozása.
• a tesztesetek rangsorolása.
• Készítsen automatizált szkripteket a tesztesetekhez.

Test Environment Setup

a tesztelési tevékenységeknek bizonyos környezeti tényezőkre—például szerverekre, keretrendszerekre, hardverekre és szoftverekre—van szükségük a fejlett tesztesetek végrehajtásához. Ennek a fázisnak a fő összetevői a szoftver-és hardverkonfiguráció, valamint a tesztadatok beállítása. És kötelező a füst teszt, és felszerelni a tesztelők hibajelző eszközök.

A fejlesztői közösségben gyakori, hogy “futott a rendszeremen, de nem fut a tiéden”. Ezért fontos, hogy a tesztkörnyezet lefedi az összes olyan környezetet, amelyet a felhasználó használna.

például néhány olyan szolgáltatás, amely a Google Chrome-ban működik, nem működik az Internet Explorerben. A funkciók működése a szoftver-és hardverkövetelmények alapján is eltérő. Egy funkció zökkenőmentesen működhet 4 GB RAM-on, de problémákat okozhat az 1 GB RAM-mal. A végfelhasználók által használt környezetek kutatása segít a tesztkörnyezetek rangsorolásában.

a csapatot felügyelő QA menedzser feladata, hogy gondoskodjon a tesztkörnyezet beállításáról.

összefoglalva:

• értsd meg a minimális követelményeket
• felsorolja a különböző teljesítményszintekhez szükséges szoftvert és hardvert.
• Rangsorolni teszt környezetben
• Beállítás teszt környezetben
• a Füst teszt az épített környezetben

Teszt Végrehajtása

az alkalmazás készen áll a tesztelésre, ha a csapat már a korábbi szakaszok. A vizsgálati terv szerint a tesztelők teszteseteket hajtanak végre. Emellett azonosítják, felismerik és naplózzák a hibákat, így jelentik a hibákat. A csapat felelős azért is, hogy összehasonlítsa a várt eredményeket a valós eredményekkel. Ha bármilyen hibát találnak, azokat dokumentálni kell, hogy továbbadják a Fejlesztőcsapatnak a javításhoz.

miután a fejlesztői csapat eltávolít egy hibát, megkezdődik a regressziós tesztelés. A regressziós tesztelés biztosítja, hogy a szoftver vagy az alkalmazás még a módosítás telepítése után is működjön. A hibajavítás utáni tesztelés során tesztelje újra a teljes terméket. Mivel a hiba kijavítása hibát okozhat a termék más részén. Mivel ugyanazokat a teszteket kell futtatni újra és újra minden javítás és telepítés után, ajánlott szkriptek vagy automatizált tesztelő eszközök használata.

összefoglalva:

• tesztesetek futtatása.
• azonosítsa a termék várható viselkedésétől való eltérést.
• Log sikertelen esetek részletek
• teszt után újra hibajavítások.

Tesztzárás

és ez elvezet minket az STLC utolsó szakaszához: tesztzárás.

a vizsgálat befejezése és a végtermék szállítása jelzi a vizsgálat lezárási fázisának kezdetét. A QA csapat ellenőrzi a teszt eredményeit, és megbeszéli azokat a csapat többi tagjával. Néhány egyéb tényező, amelyet figyelembe vesznek, a termék minősége, a teszt lefedettsége és a projekt költsége. Ha eltérés van a becsült értékektől, további elemzéseket lehet végezni annak megállapítására, hogy mi nem ment a várt módon.

alapvető gyakorlat a tesztelők számára, hogy a tesztelés után megbeszéljék a következtetést. A tesztelés során felmerülő kérdéseket, a stratégiák hibáit itt lehet megvitatni. Azt is dolgozni jön egy jobb megközelítés tesztelés alapján a tanulságok tesztelés során. Ha követi a DevOps vagy a canary release gyakorlatot, a tesztelés gyakori. Eldöntheti, hogy milyen gyakran kell jelentéseket küldeni, és milyen részleteket kell megemlíteni, miközben jelentéseket küld a különböző érdekelt feleknek.

Ezen kívül a csapat figyelembe veszi a tesztmutatókat, a célok teljesítését, valamint a határidők betartását. Miután teljesen megértették, mi történt, értékelhetik a teljes tesztelési stratégiát és folyamatot.

összefoglalva:

• ellenőrizze, hogy az összes teszt befejeződött-e.
• olyan tényezőket értékel, mint a minőség, a teszt lefedettség, az Idővonal és a költség.
• dokumentálja a következtetést.
• beszélje meg a tanulást, és derítse ki, hogy javítható-e a tesztelési folyamat.
• vizsgálati zárójelentés készítése.

mik a vizsgálat belépési és kilépési kritériumai?

a szoftver tesztelési életciklusának mind a hat fázisában vannak belépési vagy kilépési kritériumok. A tesztelőknek meghatározott időn belül be kell fejezniük a tesztesetek végrehajtását. Emellett meg kell őrizniük a végtermék minőségét, funkcionalitását és hatékonyságát. Ezért a belépési és kilépési kritériumok meghatározása kötelező. Most ezt fogjuk tenni.

belépési kritériumok

nevezési kritériumok jelzik, hogy a csapatnak milyen követelményeket kell teljesítenie a vizsgálati eljárás megkezdése előtt. A tesztelés megkezdése előtt kötelező az összes követelmény átlépése.

vannak folyamatban lévő tevékenységek és feltételek, amelyeknek jelen kell lenniük a tesztelés megkezdése előtt. Először be kell vezetnie a fejlesztői csapatot. Meg szeretné vizsgálni a teszttervet, a teszteseteket és az adatokat, a tesztkörnyezetet és a kódját is.

Exit Criteria

Exit criteria state the requirements and actions to complete before the testing ends. Más szóval, ezek közé tartoznak a feladatok listájának átlépéséhez szükséges elemek,valamint a tesztelés megkezdése előtt elvégzendő folyamatok.

a kilépési kritériumok magukban foglalják a kiemelt fontosságú hibák azonosítását. Azokat azonnal rendbe kell hoznod. A tesztelőknek különböző vizsgálati eseteket kell teljesíteniük, és biztosítaniuk kell a teljes funkcionális lefedettséget.

következtetés

az SDLC utolsó szakaszában a hibák egyszerű azonosítása már nem hatékony gyakorlat. Vannak más napi tevékenységek is, amelyekre a cégnek összpontosítania kell. Szentel túl sok a drága időt, hogy a tesztelés és a hibák kijavítása akadályozhatja a hatékonyságot. Végül is több időt vesz igénybe, hogy kevesebb kimenetet generáljon.

a tesztelési folyamat megkönnyítése érdekében fontos az idő és az erőforrások hatékony felhasználása. A szisztematikus STLC után nem csak gyors hibajavítást eredményez, hanem javítja a termék minőségét is. A növekvő vevői elégedettség, élvezni fogja a megnövekedett ROI és továbbfejlesztett márka jelenlétét.

ezt a bejegyzést írta Arnab Roy Chowdhury. Arnab egy UI Fejlesztő szakma és a blogolás rajongó. Erős szakértelemmel rendelkezik a legújabb UI / UX trendek, projekt módszertanok, tesztelés, scripting.

mit kell olvasni a következő

mi a Shift bal tesztelés? Útmutató a QA javításához