FAQ
Az alábbiakban a Guru99 közösség leggyakrabban ismételt kérdései olvashatók
- Nem látja a videókat?
- Nem kaptam e-mailt a projekthez
- Ha hibát kapok egy alkalmazásban, ki fogja eldönteni a hiba súlyosságát és prioritását?
- Mi a teendő, ha nincs Funct.Spec/a rendszerhez kapcsolódó dokumentum?
- 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?
- Miért a szoftverminőség-biztosítás területét választja?
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.