A teszterem útja kíváncsisággal kezdődött. A gyermekkortól kezdve számítógépek összeszerelésére és szoftverek telepítésére vállalkoztam, a munka során rendszeres kérdések merültek fel: “Miért nincs telepítve? Miért nem működik? “. Abban a pillanatban azt hittem, hogy tesztelővé akarok állni, hogy minőségi szoftvereket állítson elő, és megtalálja a választ mindezen kérdésekre.
Az alábbiakban a jövőbeli minőségbiztosítási szakembereknek szeretném megmondani, hogy mi vár rájuk a karrierjük kezdetén, és adjon tanácsot tapasztalataikból.
interjú
Junior-tesztelő nem túl nehéz átvinni az interjút. Nem számít mélységes ismeretekre a tesztelés elmélete és eszközei iránt. Az ilyen jelöltek megkérdezésénél figyelmet fordítunk a gondolkodás gyorsaságára és életlenségére, a friss problémák megoldására és a nem szokványos megközelítésre.
Például kérdezze meg szokatlan kérdéseket, hogy lássa, hogyan gondolkodik az ember:
- A repülőgép az A ponttól 17: 00-kor elhagyja a B pontot 19:00 órakor. Három órával repült. Miért lehet ez?
- Hogyan győződjön meg arról, hogy a frissített alkalmazás beérkezése után a versenytársak nem tudták megismerni új funkcióit?
Készüljön fel a leggyakoribb feladat – egy egyszerű tárgy tesztelésére: papírdarab, ceruza, tápszalag és hasonlók.
Az interjú is hasznos lesz:
- Vizsgáljuk meg, hogy milyen típusú vizsgálat: a funkcionális és feltáró vizsgálat, automatizált tesztelés (ideértve eszközök is), a terhelés és stressz teszt, füst-tesztelés.
- Ezenkívül olvassa el az átvételi tesztet és a kritériumokat.
- Ha webes alkalmazások teszteléséről van szó, akkor ez egy böngészőpult és munkája, a böngészők számát és verzióit, monitorfelbontásokat, képpont-tökéletesítő eszközöket.
- Ha mobil alkalmazásokról beszélünk, ezek platformok, emulátorok, majom tesztelés. Ne felejtsd el a tablettákat.
- A hibakeresők típusainak tanulmányozása. Legnépszerűbb: Jira, BugZilla, RedMine, Mantis. Nézze meg, hogyan működnek, mi a sajátossága.
- Persze, az eszközök Jmeter, Postman, Charles. Nem nagyon nehéz elsajátítani egy alapszintet.
Az első munkanap
Az első munkanap a standard: megadja a számítógépet, amelyet be kell állítani és munkaprogramokat kell telepítenie. A rendszergazda felkészíti a levelezést és a vállalati belső programokat.
Ne kérdezze meg, hol kell telepíteni a Skype-t, használd becenevét a gangsta_666 iskolai időből vagy vicces képet. Használja a becenevet az első és a vezetéknév kombinációját, például a ivansmirnont vagy a smirnovivant, a szokásos fényképét.
Fontos lépés a munkanap előkészítésében, hogy megismerkedjen a vállalat által használt hibajelzővel. Érdemes előre megkérdezni: tanulmányozni a cikkeket, nézni a képzési videókat. Megtakaríthatja a kollégák idejét, és biztonságosabbá válik.
Az első feladat
A merülés első tervezetét kapja. Azt tanácsolom, hogy ismerkedjen meg a hibakereső történetével, és nézze meg, hogy milyen hibák vannak már előfordultak vagy a leggyakrabban előfordultak. Tudod megfogalmazni statisztikákat magadnak, és meg fogja érteni, hogy milyen pillanatokban érdemes több figyelmet fordítani.
Vegye meg a kezdeményezést. Ha nem kapta meg az alkalmazás ellenőrző listáját, ne várjon, de kérje a mentorról. Ha a szervezet nem rendelkezik ellenőrző listával, saját maga készítheti el. Cégünknél az ellenőrző lista gyakrabban szerepel a “Google Táblázatokban”. Az alábbiakban példát adtunk egy ilyen ellenőrző listára – saját példájával sajátíthatja el a sajátját.
A kollégák meglepődnek, ha ellenőrző listát készítenek egy gondolati térkép formájában, például az Xmind.net-ben.
Ellenőrzőlista a Pokémon GO teszteléshez
Az egyik legfontosabb tesztelési típus a kezdő QA-szakember számára talán az ellenőrző listák átvétele, a régebbi szakemberek tesztelése. Ez a szakasz szükséges a projekt gyorsabb bemerítéséhez. A tesztbázis bővítéséhez a kezdő saját maga bővítheti ezt az ellenőrzési listát. A junior tesztelők egy lapot készítettek a Pokémon GO alkalmazás tesztelésére az edzés részeként az írásjegyzékben. Csak pozitív eseteket ismertetnek itt.
Az első hiba a trackerben
A hibák leírása különböző vállalatokban változhat, de általában a jó hangzás elvei vannak.
téma
Néhány szóval leírja a problémát. Jobb, ha negatívval kezdődik: “nem működik”, “nem történik meg”, “rossz”, és így tovább. Például: “Nincs szinkronizálás a szerverrel az iPhone 6-on”, “A videofelvétel a Nexus 5-ben nem működik”.
forgatókönyv
A hiba reprodukciójának lépésről-lépésre történő leírása. Ügyeljen arra, hogy a hiba előfeltétele és jelei jelennek meg (például a balra mutató piros gomb világít).
Ezenkívül csatolhatja a képernyőképeket azokkal a helyekkel, amelyekre figyelniük kell (a Joxi, a LightShot és más alkalmazások használata esetén), mert nehezebb hibákat reprodukálni – videofelvételt készíteni. Amikor tapasztalatot szerez, lõhet és alkalmazhat naplókat.
A szkript végén a tesztkörnyezet, amelyen a tesztelést végezték, jelzi: az alkalmazás verzióját, a készülék firmware-jét (Android 6.0.1, iOS 9.3.2). Ha ez webes alkalmazás, adja meg a böngésző verzióját.
A táska célja
Ezután hozzá kell rendelnie egy hibát valakinek. Kérdezze meg a projektmenedzsert vagy a mentort, hogy ki fogja felakasztani ezt a hibát, és ki azok közül a fejlesztők közül, akiknek a projekt területe felelős. Így megismerkedhet a csapattal, hogy később hibákat rendelhessen el.
Criticality mapping
A legtöbb követőben a hibák kritikusságának típusai a következő listán szerepelnek:
Azonnali (blokkoló)
Blokkolási hiba. Az alkalmazást nem működőképes állapotban hagyja, ennek következtében lehetetlenné válik a vizsgált rendszerrel vagy annak funkcióival való további kölcsönhatás.
Crit – Sürgős
Kritikus hiba, a legfontosabb üzleti logika megszakadt. A probléma a kiszolgáló vagy alkalmazás ideiglenes lecsökkenését eredményezi anélkül, hogy megoldaná azt. A probléma megszüntetése szükséges a teszteléshez.
nagy
Jelentős hiba, a fő üzleti logika része sérül. A hiba nem kritikus, lehetőség van arra, hogy más beviteli pontokkal együtt dolgozzon a tesztelt funkcióval.
normális
Kisebb hiba. Nem sérti az alkalmazás tesztelt részének üzleti logikáját, a felhasználói felület és a lokalizáció nyilvánvaló problémáját.
alacsony
Triviális hiba, nem vonatkozik az alkalmazás üzleti logikájára. A külső könyvtárak vagy szolgáltatások problémája gyengén reprodukálódik, alig látható a felhasználói felület miatt.
Önképző
Mindenki ismeri az önképzés fontosságát – az utasításom banális lesz. Tehát azonnal a lényegre.
Az alábbiakban néhány könyv, amelyet személyesen ajánlok a gyakornokoknak:
- “DOT COM tesztelése”, a Roman Savin egy nagyon hasznos kézi, majdnem asztali könyv egy kezdő tesztelőnek. Tartalmazza az oroszlánrészek ismereteit annak érdekében, hogy megkezdje a tesztelést és sikeresen válaszoljon az interjú során a technikai és elméleti részre vonatkozó kérdésekben.
- “Hogyan teszteljük a Google-t” – egy mélyebb könyv, amely leírja a folyamatok szervezését, a különböző stratégiákat és a tesztelés módszereit. A könyv segít megérteni, milyen a minőség, hogyan és milyen szakaszokban lehet befolyásolni.
- “A gyakorlati útmutató a szoftver tesztelésére”, Lee Copeland – a könyv leírja a tesztelés típusát “fehér” és “fekete” dobozként. Számos tesztelési technika kerül felsorolásra, valamint azok használatára és használatukra. A könyvben egy érdekes cikk található a kutatási tesztelésről, ami nagyon hasznos a kezdők tesztelésére.
Kollégák, írja meg a megjegyzésekben az érdekes könyvek nevét a tesztelőknek. Biztos vagyok benne, hogy mindenki hasznos lesz.
következtetés
Végezetül szeretném hozzátenni, hogy egy minőségi termék felszabadítása nehéz és lassú folyamat. Meg kell védenie a véleményét a tárgyalások során, meg kell győznie a fejlesztőket, hogy tegyék meg a helyes dolgokat, és ne a mankókat, hogy megértsék, hogyan lehetne a felhasználóbarát működést.
Ez csak egy része a szükséges információk egy kezdő tesztelő. Az összes többiet keresni kell az interneten harci körülmények között, majd kérje meg kollégáit. Ne habozzon felkérdezni a kérdéseket és a google órákat, gyakran az egyik kérdésre adott válasz sok időt takarít meg a jövőben.
