FAQ

Az alábbiakban a Guru99 közösség leggyakrabban ismételt kérdései olvashatók


Nem látja a videókat?


Az ezen az oldalon található összes videó a webhelyen található YouTube és ide beágyazva…
Ön valószínűleg olyan helyről éri el a webhelyet, ahol YouTube be van tiltva (az Ön cége, főiskola vagy ország, ahol YouTube le van tiltva)

Próbálja meg korlátlan környezetből elérni a videókat.
Ugye NEM a videók megtekintéséhez regisztráció szükséges.


Nem kaptam e-mailt a projekthez


Felhívjuk figyelmét, hogy a projekt e-mailjei 24 órás időközönként kerülnek kiküldésre. Tehát ha csütörtökön 10:10-kor iratkozott fel, a következő e-mailt pénteken XNUMX:XNUMX-kor kapja meg.

Kérjük, ellenőrizze a levélszemétet vagy a levélszemétet Maildoboz. Ha gmailt használsz, nézd meg a Promociók Tab

Rendszerünkben nincs lehetőség az e-mailek újraküldésére. Ha továbbra sem követi az e-maileket, iratkozzon fel egy másik e-mail azonosítóval a tartalom eléréséhez.

Ha hibát kapok egy alkalmazásban, ki fogja eldönteni a hiba súlyosságát és prioritását?


A súlyossága Disszidál az határozza meg, aki a problémát azonosítja (tesztelő), míg a prioritást az határozza meg, aki részt vesz a probléma megoldásában (fejlesztők).

Tesztelőként előnyben részesítheti a hibákat, amelyeket általában a tesztvezető felülvizsgál. A fejlesztők az elemzés után döntik el, hogy magas vagy alacsony prioritású hibáról van-e szó. Legtöbbször a fejlesztő végzi el, de a tesztelő is bevonhatja a műveletet, hogy elmagyarázza a súlyosságát. A megbeszélés után a vezetők következtetésre jutnak.

A súlyosság alapvetően az alkalmazás vagy termék funkcionalitásával függ össze. Bár a prioritás az, hogy a fejlesztő hogyan tudja azonnal kijavítani a hibát vagy hibát. A prioritás dinamikus természetű, és a forgatókönyv szerint változik, míg a súlyosság statikus jellegű.


Mi a teendő, ha nincs funkcionális specifikáció/dokumentum a rendszerrel kapcsolatban?


  • Először próbálja meg megérteni a területet üzleti elemzőkkel vagy kkv-kkal. Végezzen feltáró tesztelést a rendszer megértéséhez.
  • Ha a projekt nem rendelkezik Business Analyst vagy kkv-k, beszéljen a hasonló rendszereken dolgozó emberekkel.
  • Az üzleti élet megértéséhez beszéljen a felhasználói közösséggel
  • Hasonló termékleírásokat találhat az interneten vagy a PMO-n
  • Keressen azonos típusú alkalmazásszoftvert, és ismerje meg a funkciókat
  • Keressen néhány fontos üzleti forgatókönyvet, alternatív dokumentumot, pályázati témájú cikkeket
  • Kérje magyarázatát az összes modulról a fejlesztőktől
  • Felhasználói előzményadatok, alkalmazások és szolgáltatások
  • Ne tesztelje az alkalmazást technikailag, először csak felhasználói szemszögből tesztelje az alkalmazást

Mit tehet a tesztelő, ha a megjelenés előtt néhány nappal a műsor leállási problémáját észleli?


  • Erősítse meg és erősítse meg újra a hibát, és dokumentálja a hibát vagy hibát, a hatást és a lehetséges megoldást, ha tudja.
  • Felhívja erre a menedzser figyelmét, és beszélje meg a csapattal, mivel egy ilyen bemutatót nem ismer a csapat egy héttel a megjelenése előtt, nem jó.
  • Amint a Hiba eljut a feletteséhez és a magasabb tesztelői hatóságokhoz, előfordulhat, hogy meg kell adnia nekik a véleményét, ezért legyen alapos az álláspontjával, mivel ez hatással lehet a kiadásra.
  • Ha a vita támogat téged, itt az ideje, hogy felemelkedj és ragyogj. Ha nem, elvitelre kap egy leckét a napra. Tanulj tovább.

Miért a szoftverminőség-biztosítás területét választja?


Ahhoz, hogy minőségi projekteket biztosítsunk a végfelhasználóknak vagy az ügyfeleknek, a tesztelés kötelező, függetlenül attól, hogy milyen kódolásról van szó. A szoftver minőségbiztosítása nem csak a hibákat naplózza, hanem megoldásokat is kínál ezekre a hibákra.

A minőségbiztosítási területen a tesztelőknek tisztában kell lenniük a tesztelni kívánt alkalmazás teljes funkcionalitásával, ez lehetővé teszi számára, hogy megismerje a különböző környezetekben kifejlesztett különböző típusú alkalmazásokat, még a programozás néhány alapfogalmát is. A tudás szélesebb lesz, amikor tesztelünk, de szűk lesz a programozás során. Előfordulhat, hogy a fejlesztő a teljes alkalmazásnak csak egy kis részét fejleszti, és nem biztos, hogy az alkalmazás egészét ismeri. Ebben az esetben a QA (tesztelő) szerepét éreztem érdekesebbnek.


Nem talált választ?


Kapcsolat