Hibás életciklus - Mint már tudatában lehet annak, hogy a teszt végrehajtása az a fázis, amelyben a tesztelő ténylegesen végrehajtja a teszt szkripteket. A teszt szkriptek végrehajtásának folyamata vállalkozásonként eltérő, és ugyanazon vállalaton belüli különböző projektekben is eltérő lehet.
Napok óta rendelkezésre állnak eszközök a teszt végrehajtásához, olyan eszközök, mint a - Quality Center, a Microsoft Visual Studio és így tovább. Az egyes lépések tényleges végrehajtási folyamata a tényleges és a várt eredmény összehasonlítása érdekében változatlan marad a funkcionális tesztelő esetében, függetlenül a használt eszközöktől.
- Mi lenne, ha a tényleges viselkedés nem felel meg a várt viselkedésnek?
Ha egy tesztelő úgy találja, hogy a tényleges vizsgálati eredmény nem egyezik meg a várt eredménnyel, akkor a hibát naplózza.
- Hogyan lehet naplózni egy hibát?
Napjainkban számos eszköz elérhető, néhány hibanapló-eszköz az ClearQuest az IBM-től, a HP Minőségközpontjától, nyílt forráskódú eszközök, például a hiba életciklusa a JIRA-ban és így tovább.
Vannak olyan kötelező mezők, amelyek közösek a hibás naplózási eszközök között, ezek a mezők -
- Hiba életciklus Leírás
- A hiba életciklusának összefoglalása
- A hibát naplózta
- Hiba hozzárendelve
- Hiba súlyossága
- Hiba prioritás
- További pillanatképek
- Kiadási szám / név
Hiba az életciklus
A hiba életciklusa egy új hiba naplózásáról indul. Ha a hibát naplózza, az új állapotba kerül.
Tesztelő - új hiba
Kinek rendeljen új hibát?
A tesztelő hibát rendelhet a fejlesztőhöz vagy a fejlesztési vezetőhöz. Ez a hibakiosztási döntés projektenként változik. Bizonyos munkahelyeknél életciklus-folyamat zajlik annak érdekében, hogy azt közvetlenül a megfelelő fejlesztőhöz rendeljék, és egyes helyeken a hibát először egy dev vezetőhöz rendelik, a dev vezető pedig ezt egy fejlesztőhöz rendeli.
Hiba-hozzárendelés (új) - hibás életciklus-fejlesztő
Hibaelhárítás (új) - Dev Leadà fejlesztő
Hibaelemzés
A fejlesztő elemzi a hibát annak ellenőrzése érdekében, hogy megismételhető-e. Ebben az esetben a tesztelő legfontosabb hozzájárulása az összes szükséges részlet beillesztése a hibába. A hibaösszefoglalás, a hiba részletes leírása azok a mezők, amelyek segítséget nyújtanak az érdekelt feleknek a hiba egyszerre történő megértésében. A hibaösszefoglalónak mindig csak a hiba magas szintű információival kell rendelkeznie. Ugyanakkor elegendő információval kell rendelkeznie, hogy leírja a hiba áttekintését egy sorban.
A hiba leírása az a hely, ahol a tesztelő várhatóan tartalmazza az összes szükséges információt, például a környezet, a forgatókönyv, a használt teszt adatok, a várt eredmény, a tényleges eredmény, a fájlokra / adatokra való hivatkozás és a pillanatfelvétel hivatkozása.
Itt található a hiba különféle elemeinek rövid áttekintése - Részletes leírás -
Környezet
Tesztkörnyezet, ahol a hibát találták. A projektek gyakran több tesztkörnyezettel rendelkeznek, ahol a tesztcsoport tesztelést végez. Például - AT (szerelési tesztelési környezet), PT (terméktesztelési környezet), UAT (felhasználói elfogadási tesztelési környezet) és így tovább. Különböző környezetek kialakításának célja, hogy rugalmasságot biztosítson a fejlesztő és a tesztelő csoporton belül annak érdekében, hogy a kódot a rendelkezésre álló környezetek bármelyikére telepítsék, hogy időben elindítsák a tesztelést.
Vannak olyan esetek, amikor a Termékteszt (más néven rendszerteszt) és az UAT tesztelés átfedésben vannak, ezért a többféle környezet megléte kötelező a párhuzamos tesztelés folytatására.
Vannak esetek, amikor a fejlesztői csapatnak további környezetre van szüksége a tesztelő csoport által bejelentett problémák hibakereséséhez. A fejlesztő csapat emellett dedikált környezettel rendelkezik az egység tesztelésére.
Ezért több környezet esetén a hibában meg kell említeni egy adott környezetet, ahol a probléma megtalálható.
Forgatókönyv
A forgatókönyv a tesztelő által a hibahoz vezető lépések sorozata. A tesztelő elvárja, hogy megemlítse az összes lépést, amelyet a fejlesztő végrehajthat a hiba kijavításához. Gyakran vannak olyan esetek, amikor a hibát a tesztelő jelentette be, de a fejlesztő nem képes ugyanazt megismételni, és ezért a hibát elutasítják. Ennek oka lehet a leírásban említett helytelen lépések / hiányzó lépések miatt. Az egyértelmű lépések segítenek mindenkinek megérteni a hibát, és megismételni azt anélkül, hogy attól függ, hogy a tesztelőhöz fordul-e bemenetekhez. A jól dokumentált forgatókönyv könnyen olvasható, könnyen érthető és pontos lépéseket kell követni a hiba megismétlésére.
Teszt adat
A tesztelőnek állítólag megemlítenie kell a tesztelés során felhasznált adatokat, amelyek problémát eredményeztek. Ez az információ lehetőséget ad a fejlesztőnek a hasonló adatok felhasználására a hiba reprodukciójához és annak alapvető okának megtalálásához.
Vannak olyan esetek, amikor a tesztelő hibát talál egy meghatározott adat felhasználásával, de ugyanaz a probléma nem reprodukálható hasonló típusú adatok felhasználásával. Ez az adatok sérülése miatt fordulhat elő, ezért az adatok bevitele lehetővé teszi a hibák kiváltó okainak kiderítését. Lehet, hogy egy fejlesztő nem mélyedik le a kódszintre, ha a helyzet adatvesztéssel jár. Ez a fajta hiba konvertálható adathibá.
Várható és tényleges eredmény
Ez a legfontosabb leírás mezője, ahol a tesztelő bizonyítja, hogy a felmerült hiba valóban hiba. A várt eredmény egyértelmû megemlítése minden érdekelt számára egyértelmûvé teszi a hibát hibának tekinteni. Képzelje el, hogy a hibát minden részlettel naplózza, de nem határozza meg a forgatókönyv várható eredményét!
Általában a tesztelő csak a várt eredményt adja be, ami lehet egy vagy két vonalban, azonban nagyon fontos megemlíteni a várható eredmény forrását. Forrás itt hivatkozás arra a dokumentumra, ahol a várható eredményt említik. Ez lehet egy követelménydokumentum vagy egy forgatókönyv hivatkozás.
Hivatkozás a fájlokra / adatokra
Időnként a hiba magában foglalja a fájl létrehozását vagy a fájlként történő bevitelt. Az ilyen forgatókönyvekben a tesztelőnek állítólag információt kell adnia a használt fájlról, amely az alkalmazás során oka a kérdésnek. Ezeket a fájlokat a hibakezelő eszköz segítségével csatolhatjuk, vagy megadhatjuk a referenciát is. Ezeknek a referencia-helyeknek minden érdekelt számára hozzáférhetőnek kell lennie.
Hivatkozás pillanatfelvételre
A pillanatképek nagyon fontos szerepet játszanak, ha meg akarja jeleníteni nekik a képernyőn megjelenő pontos oldalsértési hibaüzenetet, vagy amikor meg szeretné mutatni a képernyőn megjelenő navigációs részleteket. A pillanatkép gyors képet ad a felmerült hibáról, a képernyőről, amelyen a hibát találták, a képernyőn használt adatokról és így tovább. Minden hibakezelő eszköz rendelkezik a pillanatképek csatolására. Időnként a tesztelő csatolhatja az Excel táblázatokat vagy szódokumentumokat is.
Ezek voltak a hibanapló különféle alkotóelemei és mindegyiküknél a bevált gyakorlatok. Visszatérve a hiba életciklusához, mihelyt a hibát egy fejlesztőhöz rendelték, elemzi a hibás tételben megadott adatok felhasználásával. Ha az elemzés szerint a naplózott probléma valóban hiba, akkor a fejlesztő „megnyitja” a hibát, hogy javításra kerüljön.
Ajánlott tanfolyamok
- Webszolgáltatások a Java Training Bundle-ban
- Képzés a játékfejlesztésről a C ++ nyelven
- Teljes etikai csapkodási képzés
- Vegas Pro 13 képzési tanfolyamok
Új - nyitva
A Nyílt állapot hibája azt mutatja, hogy a fejlesztési lemezen van, és a fejlesztők dolgoznak a javításán. Ha az elemzés azt találja, hogy a naplózott kérdés nem jelent hibát, akkor ez akkor fordulhat elő, ha a rendszer várható viselkedésében nincs megértés. Ha az elemzés szerint a hiba érvénytelen, akkor a fejlesztő elutasítja a hibát. A terminológia „elutasítva” vagy „visszatérés a teszteléshez”.
Új - Vissza a teszteléshez.
Hogyan kell vizsgálni a tesztelőt, ha a hiba valóban érvénytelen hiba volt?
Ebben az esetben a pontos követelménydokumentum segít a csapat minden tagjának arra a következtetésre jutni, hogy a naplózott hiba érvénytelen vagy érvényes. A követelménydokumentumokra való hivatkozás segít a tesztelõknek és a fejlesztõknek ugyanarra a következtetésre jutni, és ez valóban megkönnyíti a vita folyamatát.
Vannak olyan forgatókönyvek, amikor a tervezési és a követelménydokumentumok helyességét megkérdőjelezik, miközben hivatkoznak ezekre a dokumentumokra a hibabeszélgetések idején, ilyenkor az üzleti elemzőhöz való visszatérést tekintik a legjobb lehetőségnek a kérdések tisztázására.
Bevált gyakorlatként a követelménydokumentumokat és a tervezési dokumentumokat mindig naprakésznek kell lenniük, hogy kétértelműségek nélkül utalhassák azokat.
„Nyitott” állapotban a fejlesztőcsapat a hiba kijavításán dolgozik, miután a hibát kijavították, az állapot „üzemkész állapotba” változik.
Nyitva - készen áll a telepítésre
A telepítés az a folyamat, amelynek során a módosításokat feltöltik a kiszolgálóra, hogy a tesztelő csoport a kód rögzített változatán dolgozzon. Általában minden projektnek külön telepítési csoportja van erre a feladatra.
Tehát magas szinten egy szoftvercsapat főként e három csoportból áll -
- Fejlesztés
- Hiba az életciklus a tesztelés során
- Telepítés (vagy néha Build teamnek hívják)
Miután az összeállítás telepítésre került, és a hiba újra rendelkezésre áll az újrateszteléshez, azt egy új tesztelési feladat megfelelő tesztelőjéhez rendelik.
Hiba rendelve - tesztvezetékhez.
Tesztvezető - egyéni tesztelő.
Hiba kiosztva - egyéni tesztelő.
Bizonyos munkahelyeken a hibát először a tesztvezetékhez rendelik, és ezt viszont az egyes tesztelőkhöz rendeli, egyes helyeken azonban a hibát közvetlenül annak a tesztelőnek kell kiosztani, aki azt tesztelné, vagy azt, aki a hibát felvetette.
Az állapot itt változik a Telepítésre kész - kész SIT tesztelés értékről.
Most a hiba a tesztelő lemezén van. A tesztelő csapat ellenőrzi a hibát, és két lehetőség van, vagy a javítás helyesen működik, vagy ugyanaz a probléma fordul elő újra. Az eredménytől függően a hiba a következő állapotokra mozoghat -
Készen áll a SIT tesztelésére - bezárt
Készen áll a SIT tesztelésére - Nyissa meg újra
Mindkét fenti esetben a tesztelőnek hozzá kell adnia az elvégzett tesztek megjegyzéseit. Ide tartozik a tesztelt forgatókönyvek és a felhasznált adatok említése. Ha a hibát újra megnyitják, a tesztelõnek megadnia kell a végrehajtott pontos lépéseket, amelyek ismét a hibához vezettek.
Az újbóli megnyitás állapota megegyezik az „új” hibaállapotmal.
Amint a hibát újra kinyitják, ismét ugyanazt a ciklust követi.
Hiba az életciklus kihívásai
- A hiba súlyosságának eldöntése - ez a tesztelő v / s fejlesztők körében a közös vita egyik témája (gyakran harcol).
- A hiba nem reprodukálható a fejlesztő rendszerén.
- A forgatókönyvben felmerült hiba, amelyet a követelmények és a tervezési dokumentumok nem említenek.
- Hiba található, de ugyanez nem emelhető fel, mivel a forgatókönyv előállítása a termelési környezetre nem megvalósítható.
Hogyan kell egy tesztelőnek legyőzni a kihívásokat?
- A súlyosság közvetlenül arányos azzal a hatással, amelyet a hiba az alkalmazásnak okoz, ha a tesztelő nem tudja folytatni a hibát, akkor azt feltétlenül a legnagyobb súlyossággal kell megjelölni.
- Ha létezik egy megoldás a tesztelés folytatásához, azt közepes súlyosságúként kell megjelölni. A további életciklus-tesztelés hatásainak figyelembevétele mellett a súlyosságot annak a helyzetnek a figyelembevételével is el lehet dönteni, amikor egy egész modul meghibásodik, ebben az esetben annak ellenére, hogy egy másik modul tesztelése is elvégezhető, de a jelenlegi modul súlyossága magas így a hibát a legnagyobb súlyossággal kell megjelölni.
- Ha a hiba nem reprodukálható a fejlesztői rendszeren, akkor valószínű, hogy a fejlesztési és a tesztkörnyezet nincs szinkronban. A tesztelő rendszeren megismételhető hibát mindig érvényes hibának tekintik.
- Vannak olyan helyzetek, amikor egy hibát naplóznak az általános üzleti forgatókönyv figyelembevételével, de a közvetlen forgatókönyvet nem említik a követelményekben vagy a tervezési dokumentumban. A bevált gyakorlatként mindig a tényleges üzleti forgatókönyveket veszik figyelembe, ahelyett, hogy a teszt lépéseit követnék. Az ilyen elemzések feltárásában fontos szerepet játszik az üzleti elemzőkkel és a termék más szereplőivel folytatott kommunikáció.
- Vannak forgatókönyvek, amikor egy tesztelő rést fedez fel az üzleti logikában a tesztelési szakaszban. Az ilyen hiányosságok megtalálását ismét nagy plusznak tekintik a tesztelők számára. A tervezési hiányosságokat általában a fejlesztésekkel kezelik.
- Bővítés - Ha egy viselkedést meg kell változtatni a szoftver életciklusának tesztelési szakaszában, akkor létrejön egy fejlesztés, amelyet a jelenlegi vagy a következő kiadásban lehet figyelembe venni, figyelembe véve a fejlesztő és a tesztelő csoportok ütemtervét és sávszélességét.
- Vannak olyan forgatókönyvek, amelyeket egy tesztelő kipróbálhat az ad-hoc tesztelés során, amelyek valójában lehetnek érvénytelen forgatókönyvek, figyelembe véve azok előfordulásának lehetőségét a produkcióban.
Ki a tesztelő legjobb barátja?
Hová kell mennie egy tesztelővel kétértelműség esetén? A válasz a lekérdezés típusától függ, ha a lekérdezés követelményekre vonatkozik, akkor tanácsos először megbeszélni a csapaton belül, hogy a rendszer helyes megértését az idősebb tagokkal folytatott konzultáció útján végezzük. A következő kapcsolattartó pont az üzleti elemzők.
Ha a lekérdezés a tesztelési folyamatra vonatkozik, akkor tanácsos felvenni a kapcsolatot tesztvezetővel vagy tesztmenedzserrel.
Ha a lekérdezés az alkalmazás technikai tulajdonságainak megértésére irányul, akkor a fejlesztői csapat tagja lehet a megfelelő ember, akihez menni.
Mivel a tesztelés olyan folyamat, amely megköveteli a rendszer átfogó megértését, ezért a kommunikáció segít a tesztelõknek gyors választ adni a kérdésekre, az attól függ, hogy megfelelõ kérdéseket tegyenek fel a megfelelõ egyéneknek. A megfelelő időben történő félretehetőség a hibától a termelési környezetbe történő kiszivárgáshoz vezethet.
Mennyire fontos a tesztelő szerepe a vállalati életben?
Vannak olyan projektek, amelyekben a tesztelő csapat ugyanolyan fontos, mint a fejlesztői csapat, és egyes forgatókönyvek esetén inkább a tesztcsoporttól, mint a fejlesztőcsoporttól függ. A későbbi forgatókönyv ritka, de létezik egyes munkahelyeken. Ez történt az idő múlásával, és lehet, hogy egy bizonyos időszakra, amikor a fejlesztői csapat nem sok tapasztalattal rendelkezik a tesztelő csoporthoz képest. Vannak emberek, akik jobban megértik az általános áramlást és a funkcionalitást, mint a többi csapattag. Egy ilyen személy részt vehet a tesztelési / fejlesztési csapatban. Ez az egyik tényező, amely meghatározza a csapattól / egyéntől való függőséget az adott projekthez.
Mi a tesztelő karrierje?
Az egyénnek eltarthat egy ideig ahhoz, hogy megértse az általános tesztelési folyamatot, a tartományt és az egyéb feladatokat, amelyekkel szemben elvárják, hogy a mindennapi életben dolgozzon. Ezen megértés alapján tanácsos dönteni további területek feltárásáról, amelyeket a tesztelő feltehet. A folyamatban mindig vannak lehetőségek a különféle folyamatok automatizálására. A kis közművek létrehozása nagyban segíthet a csapatnak is. Ha egy tesztelő jól programoz, akkor azt nagy plusznak tekintik. Ez lehetőséget teremt az automatizálási szerepkörökhöz. A teljesítmény tesztelése a tesztelők karrierpályájának egyike is. Az üzleti elemző egy másik lehetőség. A jó domain ismeretek és a jó kommunikációs készségek szükségesek a készségkészletekhez, hogy üzleti elemzők legyenek. A tesztelés számos lehetőséget nyit a tesztelők számára, hogy különféle területeken, eszközökön, folyamatokon és így tovább dolgozzanak. Csak attól függ, hogy az egyén felveszi-e és elindul-e a tesztelés egyik alapterületének mélyén. Számos tanúsítás létezik különféle eszközök számára, amelyek a tesztelés egyik területére specializálódnak. A szokásos gyártótól származó igazolás előnye a karrier fellendülésének, ám önmagában a bizonyítvány nem segít hosszú távon, ha nem kombinálják a helyes munkatapasztalattal.
Ajánlott cikkek
Íme néhány cikk, amely segít részletesebben megismerni a szoftver tesztelését, csak lépjen át a linkre.
- 6 legcsodálatosabb szoftver tesztelő interjúkérdés
- Karrier a szoftver tesztelésében
- Hogyan lehet jobb karriernövekedést elérni a szoftver tesztelő munkájában