Bevezetés a szoftver tesztelő munkájába
Mi az első, ami eszébe jut, amikor egy szoftver tesztelési munkára gondol? Nem kódoló mű? Vagy egy olyan szakma, amely nagyon egyszerű, mivel lehetőséget ad arra, hogy mások munkájában hibákat találjon (a hibák megtalálása, amikor másokban mindannyiunk számára a legegyszerűbb feladat)? Vagy úgy véli, hogy ez olyan szakma, amely a termék helyességének ellenőrzésével foglalkozik? Ezek a gondolatok helyesek és a szoftver tesztelőinek mindennapi tevékenységei. A szoftver tesztelése azonban nem csak ezekre a tevékenységekre korlátozódik.
Az alkalmazás megértése
Az alkalmazás bárhonnan elérhető lehet - egészségügy, biztosítás, pénzügy stb. - Az alkalmazási tartomány megtanulása nagyon fontos minden olyan szoftver esetén, amely megnyitja az ajtót a különböző szögekből és a felhasználói perspektívákból való gondolkodáshoz az alkalmazás tesztelése közben. Ennek alapvető elvárása mindig a nyilvánvaló és nem annyira nyilvánvaló alkalmazási utak feltárása és érvényesítése. Az alkalmazás mélyreható ismerete segít a termék hatékony érvényesítésében, ugyanakkor a tesztelő eszközévé válhat egy olyan projektben, amelyben a termék viselkedésével szemben az egyik elsődleges tudásforrásnak tekintik.
Míg a domain és a funkcionalitás megtanulása folyamatos folyamat, a másik fontos tényező a tesztelési folyamat ismerete.
Tesztelési folyamat
A tesztelés folyamata vállalkozásonként vagy projektenként is változhat. Manapság különféle szoftverfejlesztési modellek vannak, mint például a V modell, a prototípus modell vagy egy teljesen más módszer, mint például a szoftverfejlesztés agilis megközelítése. A fejlesztési modell változásával a követendő tesztelési megközelítés is változik. A V modellben végzett munka jól definiált folyamatokkal jár, míg az agilis módszertanban végzett munka várhatóan folyamatosan változó körülmények között teszteli majd.
A munka még nem zajlik az elfogadható domain ismeretekkel és a tesztelési folyamat megértésével. A következő kihívás, amely életével jár, a különféle eszközök tanulása.
Eszközök
Az eszközök tesztkezelő eszközöket, hibaelhárító eszközöket, adatbáziskezelő eszközöket és így tovább tartalmaznak.
Különböző hibanapló-szoftverekkel, azok tulajdonságaival és eszközeivel, néhány nyílt forráskódú és mások licencével, mindig előnyt jelent, ha több eszköz ismerete van. Segít abban, hogy könnyedén átalakítson projekteket vagy csoportokat, különféle eszközöket követve. A terület, a folyamat és az eszközök megfelelő ismerete mellett a Szoftvertesztelő munkája többet jelent, ami munkanapjait kihívásokkal teli és izgalmassá teszi. A csapatokon belüli együttműködés minden projekt sikerének egyik fontos tényezője, és a hatékony együttműködés érdekében a kommunikáció nagyon fontos szerepet játszik.
Ajánlott tanfolyamok
- Teljes J2EE átfogó tanfolyam
- Online R programozási tréning
- Menj programozási kurzusra
- Online tanúsítási képzés Haskell programban
közlés
A kommunikáció nagyon fontos szerepet játszik a szoftver szempontjából, mivel ez a szoftverfejlesztés kezdeti szakaszától kezdve a tesztelő csoport tagjait bevonja (mint a legjobb gyakorlatot) a követelmények megbeszélésébe, az üzleti elemzőket megkérdőjelezi, ha bármilyen kérdés vagy hiány van-e a követelményekben. A hatékony kommunikációs készséggel rendelkező vírus hatékonyan képes kommunikálni a kockázatokat, hatékonyan kommunikálhat a fejlesztői csapattal, és hatékonyan kommunikálhatja a teszt eredményeit és a tesztelési jelentéseket.
A szoftver tesztelő működésének tervezése
Ahogy a neve is sugallja, a teszttervezés az a szakasz, amikor a tesztelésre felkészülnek. A zsigerekre való felkészülés különféle tevékenységeket fog magában foglalni, amelyeket a vitorlázó hajt végre a hatékony alkalmazás érdekében. Ez elősegíti az alkalmazás validálását és az alkalmazás hibáinak hatékony feltárását. A tervezés megkezdése érdekében egy teszt átviszi a követelményeket, hogy megértse az elvárásokat.
1. Követelmények
A tesztelő csoportnak követelményeket lehetne drótvázak, storyboards, excel lapok formájában adni. Ezen dokumentumok célja az ügyfelek igényeinek hatékony és könnyen érthető bemutatása. A drótvázas dokumentum nem más, mint egy olyan dokumentum, amely PowerPoint-prezentáció formájában lehet, amely az ügyfél igényeit ábrázolja. Ugyanezen vonalakon a forgatókönyvek általában ábrázolják a képernyők kívánt megjelenését / kialakítását. Manapság különféle eszközök állnak rendelkezésre a piacon, amelyek felhasználhatók a szükséges dokumentumok elkészítésére. A szükséges dokumentumok elkészítése az üzleti elemző elsődleges felelőssége. Egy íz várhatóan alaposan megérti a követelményeket. Annak érdekében, hogy a tesztelõk és a fejlesztõk is megértsék a követelményeket, az üzleti elemzõk nyitva tartják a fórumot, hogy mindenki felvehesse és megválaszolja a kérdéseket a követelmények bármelyikével kapcsolatban. A nyitott kérdések és kérdések megvitatására és kommunikálására szolgáló platform projektenként eltérő. Lehet, hogy e-mailek láncát, konferenciahívást vagy akár megosztott meghajtó-tárolót tart fenn, amely nyomon követi az összes nyitott kérdést és válaszokat, az üzleti elemző által megadott módon.
A tiszta kommunikáció és a kommunikáció rögzítése nagyon fontos szerepet játszik a bizonyításban. A követelmény kis feltételezése néha a termék súlyos hibájához vezethet. A szoftver tesztelőjének minden szakaszában ajánlott olyan tulajdonságokkal rendelkezni, hogy a kommunikáció tiszta maradjon. Szoftvertesztelő Munkakommunikáció lehet üzleti elemzőkkel vagy akár egy csapaton belül is. A tiszta kommunikáció segíti a feltételezések távol tartását a tervezés és a végrehajtás során. Ugyanakkor ajánlott a kommunikáció nyilvántartása (lehetőleg e-mail kommunikáció). A követelésekkel kapcsolatos írásbeli kommunikáció segít a teszt végrehajtásának későbbi szakaszaiban, ahol a funkcionalitást valószínűleg nem fejlesztették ki, amint azt a rögzített kommunikáció megerősíti.
2. Forgatókönyv
Miután megértették a követelményeket, a tesztelő elkezdi dokumentálni a forgatókönyveket a tesztforgatókönyv dokumentumban. A név szerint a forgatókönyv egy olyan funkciós folyamat, amelyet a felhasználó követ egy feladat elvégzéséhez.
Példák forgatókönyvekre -
- A felhasználónak képesnek kell lennie a sikeres bejelentkezésre.
- A felhasználónak képesnek kell lennie jegyek foglalására a rendszerben.
- A felhasználónak képesnek kell lennie arra, hogy törölje a jegyeket a rendszerben.
- A felhasználónak képesnek kell lennie a profil részleteinek megtekintésére / frissítésére.
Ezeket a logikai feladatokat végzi el a felhasználó a rendszerben. Ezek a logikus feladatok, ha össze vannak csoportosítva, segítik a közmondást az összes lehetséges forgatókönyv feljegyzésében, amelyeket a felhasználó elvár. Ezeket a forgatókönyveket általában az Excel lapokban dokumentálják, vagy néha néhány eszközzel. Egy közmondó sikeresen kinyer minden ilyen forgatókönyvet a követelménydokumentumokból. Az ilyen forgatókönyveket tartalmazó dokumentum neve Teszt szcenárió dokumentum (vagy valahol magas szintű forgatókönyv dokumentum). Ez a dokumentum bemeneti dokumentumként szolgál a teszt esetek tervezéséhez.
3. Eset
Ez az eset a Software Tester munkahelyi forgatókönyvének részletesebb változata, ahol a forgatókönyvet részletesebb lépésekre bontják, amelyeket a felhasználó ténylegesen végrehajt az alkalmazás használata közben. A fent említett forgatókönyveken alapuló egyszerű példa:
Forgatókönyv - A felhasználónak képesnek kell lennie a sikeres bejelentkezésre.
Teszt esetek:
- Ellenőrizze, hogy a felhasználó be tudja-e adni a helyes felhasználónevet.
- Ellenőrizze, hogy a felhasználó képes-e megadni a jelszót.
- A felhasználónév és jelszó megadása után a Bejelentkezés gombra kattintással ellenőrizze, hogy a felhasználó sikeresen be tud-e jelentkezni.
Ezeknek az eseteknek a felsorolása magában foglalhatja az érvényesítés ellenőrzését minden mezőben, a negatív forgatókönyvek ellenőrzését és így tovább.
Az alábbiakban néhány példát találunk ezekre az esetekre -
- Ellenőrizze, hogy a felhasználónév nincs megadva - a rendszer megfelelő hibát okoz.
- Ellenőrizze a jelszót, ha nem adta meg, a rendszer megfelelő hibát idéz elő.
- Ellenőrizze a felhasználónevet és a jelszót, ha nem adja meg, a rendszer megfelelő hibát okoz.
- Ellenőrizze, hogy helytelen jelszó megadása esetén a rendszer megfelelő hibaüzenetet küld.
- Ellenőrizze, hogy helytelen felhasználónevet ír be - a rendszer megfelelő hibaüzenetet küld.
4. Követelménykövetési mátrix (RTM)
A követelmények nyomonkövethetőségi mátrixa, ahogy a neve is sugallja, segít bebizonyítani, hogy ellenőrizni és beépíteni a vállalkozások által biztosított követelményeket a tesztelési dokumentumokba, például forgatókönyvek és teszt esetek.
Legjobb gyakorlatként ez egy külön dokumentum, amely bemutatja a követelmény számának és az ezt a követelményt magában foglaló forgatókönyvek / esetek leképezését.
Ezt a dokumentumot nem használhatják mindenféle projekt, de használatának köszönhetően nagyban segíti a magas szintű forgatókönyvek nyomon követését a követelményekhez. Ez jelzi a lefedettséget, és felhasználható annak ellenőrzésére, hogy legalább egy ilyen eset fennáll-e minden követelménynek. Az RTM-dokumentum létrehozását és karbantartását a legjobb gyakorlatnak tekintik, azonban nem mindenféle program (például az Agile) szoftver használata bizonyítja a Work dokumentumot. Ha a követelmények nagyon gyakran változnak, akkor e dokumentum fenntartását meghallhatjuk. Annak érdekében, hogy elkerüljük ezt a fölösleget, és ugyanakkor módot találjunk a követelmények nyomon követésére, egyes projektek beépítik a nyomonkövethetőséget a Software Tester munkabe vagy a forgatókönyvbe.
Fontos szempont az, hogy módjuk legyen a forgatókönyvek / esetek igényeihez való viszonyításához és fordítva. A jól dokumentált követelmények megkönnyítik a Prover feladata ezen dokumentumok létrehozását és karbantartását. A kétértelmű követelmények, a folyamatosan változó követelmények sokkal nagyobb kihívást jelentenek a próféta életében, és következetlen kézbesíthető dokumentumokhoz vezethetnek, amelyek eredményeként hiányoznak bizonyos érvényesítések, és ezáltal a végtermékben hibát mutatnak.
A tesztelő eddig megtett útját a tesztelésre tervezte és felkészítette. Mivel a háború előkészítése a warJ része, ugyanez vonatkozik itt. Minél tömörebben ezek a dokumentumok készülnek, annál könnyebb a próféta számára a funkcionalitás érvényesítése és szinte az összes hiba feltárása. A tesztelő útjának következő szakasza a végrehajtás.
A szoftver tesztelő működése működik
Ebben a szakaszban az összes fent említett dokumentum kerül felhasználásra. A követelményeket a forgatókönyv létrehozásához használták, a forgatókönyvet az esetek létrehozásához használták. ez az ügydokumentum itt az önellátó dokumentum az alkalmazás érvényesítésének megkezdéséhez. A Prover megkezdi az alkalmazás érvényesítését az esettanulmány lépéseinek végrehajtásával. Ezek közül az esetek közül többet lehet felhasználni egyetlen forgatókönyv validálására, vagy akár egyetlen teszt eset is megfelelhet egyetlen teszt forgatókönyvnek. Minden attól függ, hogy a forgatókönyvek bonyolultak-e, vagy néha a tesztcsoportban követett szabványtól függ. Ezért egy tesztüzeneti dokumentum 20-50 teszt esetet tartalmazhat, vagy lehet 100-120 teszt esetet. Ezek a számok csak magyarázó célokat szolgálnak, vadul különbözhetnek projektenként. Ennek a fázisnak a eredménye a teszthiba. Az ebben a szakaszban felmerült érvényes hibák száma jó képet ad az alkalmazás stabilitásáról, a tesztelés minőségéről, az építés minőségéről és sok olyan tényezőről, amelyek közvetlenül befolyásolják a terméket. Ez a fázis a legfontosabb szakasz, mivel a tesztelő felgyorsul, hogy lefedi az összes teszt esetet (majdnem minden szükséges felhasználói utat érvényesítve), és ugyanakkor minél több érvényes hibát felvegyen. A vállalkozás számára felkínált minden felkészülés, kommunikációs készség és kérdés a tesztelés ezen szakaszában működik.
A szoftver tesztelőjének hibái működnek
Az eset végrehajtása során minden olyan viselkedést, amely nem egyenlő a várt eredménnyel, felveszik hibaként. Mindegyik tesztnek van leírása, várt eredménye és oszlopa a tényleges eredményhez. Míg a tervező szoftver tesztelő munkadokumentuma leírást és várható eredményeket tartalmaz, valamint egy üres oszlopot tartalmaz a tényleges eredményekhez. A teszt esetek végrehajtása közben a tesztelőnek kitöltenie kell a tényleges eredmény oszlopot. Ugyanakkor, ha a tényleges nem egyenlő a várt eredménnyel, akkor a hibát naplózza. A hiba naplózása nem csak azt jelenti, hogy a fejlesztőt tájékoztatják a problémáról. Ez ismét egy formális folyamat, amelyet általában egy eszköz segítségével hajtanak végre. Jelenleg különféle eszközök vannak a piacon, némelyik nyílt forráskódú, mások engedéllyel rendelkeznek. Bármely hiba naplózási eszköz a következő mezőkkel rendelkezik -
- Projekt / kiadás neve
- Hibaösszegzés
- Hiba részletes leírása
- Hiba súlyossága
- Hiba prioritás
- Fázisban találták a hibát
- Hozzárendelve
- Mellékletek
Mint látjuk, ezeknek a mezőknek az a célja, hogy formális folyamatokkal bonyolítsák le a talált kérdést. Ez elősegíti a fejlesztőknek, hogy reprodukálják a hibát a környezetükben, és kijavítsák. Az alábbiakban ezeknek a mezőknek a rövid leírása található -
- Projekt / kiadás neve - A kiadás neve, ahol a hibát találták, általában a projektnek több kiadása van, és ugyanazon projektnek több alprojektje lehet. Ez a mező elősegíti egy adott kiadás kérdésének felvetését.
- Hibaösszefoglaló - A talált hiba rövid egysoros leírása.
- Hiba részletes leírása - Ez a hiba részletes leírása, tartalmaznia kell olyan részleteket, mint például a környezet, ahol a hibát megtalálták, és a felhasznált teszteredményeket, a tényleges eredmények elvárják az eredményt, és minden további információt, amely értékes információkat ad az érdekelt felek számára a disszidál.
- Hiba súlyossága - azt jelzi, hogy a hiba súlyos. Általában a kritikus, magas, közepes, alacsony vagy numerikus értékekhez hasonló értékekkel rendelkezik, például 4, 3, 2, 1.
- Hiba prioritás - azt jelzi, hogy mennyire sürgõs a hiba elhárítása.
- A hiba megállapításának fázisa - Mivel számos szakaszban lehet naplózni a hibát, egységteszt fázis, SIT (rendszerintegrációs tesztelés), UAT (felhasználói elfogadási tesztelés) vagy akár gyártási fázis.
- Hozzárendelt: - A fejlesztő vagy a fejlesztő vezetője.
- Mellékletek - Ez lehetőséget adott a tesztelőnek a képernyő pillanatképének csatolására, ahol a probléma merült fel.
A teszt végrehajtása és a hiba naplózása az a szakasz, ahol számos kihívással szembesülhet a tesztelő. Néhányan hatékonyan kommunikálnak a fejlesztőkkel. Vitathatjuk, hogy a hiba naplózása minden szükséges információval nem elegendő ahhoz, hogy a fejlesztők megértsék a hibát?
Ez bizonyos esetekben további magyarázatot / megbeszélést igényel a fejlesztőkkel. Vannak esetek, amikor a tesztelő váratlan viselkedést tapasztal, amelyben valószínűleg nem biztos abban, hogy hiba. Ezeket a körülményeket általában olyan próbálkozók szembesítik, akik újak a csapatban, korlátozott domain ismeretekkel rendelkeznek vagy kétértelműek a követelményekkel kapcsolatban. Nos, a tesztelőt itt nem kell hibáztatni, ha szűk határidők és folyamatosan változó követelmények vannak, és az esetek többségében a próbaverzió megismerkedik a domainről, miközben ténylegesen megtervezi és végrehajtja a tesztüzemeket. Amint láthatjuk a tesztelő útját, nem olyan könnyű, mint azt észlelik. Folyamatos tanulási hozzáállásra, jó kommunikációs készségekre, jó együttműködési készségekre és készségre van szükség az alkalmazkodáshoz olyan körülmények között, ahol változások történnek a használt területeken, eszközökben és folyamatokban. Míg a kézi tesztelők utazásáról beszéltünk, az általános folyamat az automatizálási tesztelőkre is vonatkozik. Az automatizálás másrészt jelentős változásokkal jár a folyamatban, mivel a tesztelés és a tervezés terjedelme, a végrehajtás jelentősen eltér.
Figyelembe véve a próféta utazását, amint azt fentebb tárgyaltuk, még mindig elmondhatjuk, hogy a szoftver tesztelõ tulajdonságai könnyebbek, mint a fejlesztõknél?
Elmondható, hogy a tesztelő v / s fejlesztői szerepek összehasonlításán túl hasznosabb lesz megbeszélést folytatni arról, hogy a kettő együttműködése hogyan eredményezheti a termék egészének nagy sikerét. Néha elfelejtjük, hogy a tesztelő feladata az, hogy problémákat találjon az alkalmazásban, és ne utaljon a fejlesztők hibáira. Amikor elfelejtjük a munkánk gondolatát, néha szükségtelen vitákhoz vezet. Megfigyelték ugyanakkor, hogy léteznek ugyanolyan jó tesztelési, fejlesztési csapatok, ahol mindenki megérti, hogy a végső cél az, hogy az alkalmazás a várt módon működjön. Reméljük, hogy mindenki a tesztelés pozitív oldalára, mint a termék tisztítását segítő szerepre, nem pedig arra, amely csak hibákat talál!
Ajánlott cikkek
Ez egy útmutató volt a nyilvánvaló és nem annyira nyilvánvaló alkalmazási útvonalak feltárására és érvényesítésére, amely mindig a szoftver tesztelő munkájának elsődleges elvárása. Ez a következő tesztelési munkához kapcsolódó külső link.
- Hiba az életciklus a szoftver tesztelésében
- 6 legcsodálatosabb szoftver tesztelő interjúkérdés
- Karrier a szoftver tesztelésében