6 minőségbiztosítási hibák és azok elkerülésének módja

Elkling átadta bölcsességét

A szoftverfejlesztés minőségbiztosítási ágazatában szerzett hétéves tapasztalatom megtévesztő magabiztosságot ad nekem, hogy leülök a hintaszékbe, összegyűjtem a fiatalokat és elmesélek egy mesét arról, hogy miként ment vissza a régi jó időkben, milyen hibáim voltak és bosszantó csók a juniorokon, hogy tanuljak a hibáimból. Miközben tudatosan a ropogós tűzbe megyek (igen, most van tüzet, tartsd fenn a fantáziát) komoran szigorú pillantást velem és elkezdem prédikálni. Íme hat minőségbiztosítási hiba és hogyan lehet elkerülni őket!

1. Felejtsd el a nagyobb képet

Amikor egy junior tesztelőként indul, és egy jól pihenő arany retriever kiskutya izgalmát élvezte, elkerülhetetlen, hogy elfelejtse a nagyobb képet. Két alkalommal, mielőtt be kell nyújtanom a végleges kiadási jelöltet, egy junior a Jira táblát javításokkal, tévesen beállított képpontokkal, kissé közepén lévő ikonokkal és hiányzó pontosvesszővel tölti be. Ez a leggyorsabb módja annak, hogy hiába szellőzzem. Szükségem van ebben a szakaszban a megerősítésre, hogy a főbb funkciók működnek, semmi nincs törve, az összeomlások távoli memória, és az alkalmazás felhasználóbarát és könnyen elérhető - nem a nyelvtan ellenőrzése és az UI tökéletesítése.

Az új tesztelőknél a legjobb dolog a végtelen vágyakozás, hogy minél több hibát találjanak, és értékesnek bizonyítsák magukat. Azonban a legrosszabb dolog az új tesztelőknél a végtelen vágyakozás, hogy annyi hibát találjanak ... tudod, hogy ez miként ér véget. Időnként a lehető legrosszabb pillanatokban hajlamosak kisebb jelentőségű részletekre összpontosítani. A prioritások meghatározása megtanult, és az idő múlásával megtanulják, hogy megfelelő idő van a triviális kérelmek benyújtására, és a közeledő ijesztő határidő valószínűleg nem ez az idő.

2. Adjon hozzá kérdéseket az érzései alapján

Úgy gondolom, hogy ez az ikon jobban fog kinézni, ha kék helyett narancssárga volt. Úgy érzem, hogy ezt a logikát egy kicsit nehéz megérteni, ezért úgy érzem, hogy még legalább négy felugró ablakot fel kell vennünk. Nem! A junior tesztelők nem kapnak javaslatot. Ez túl durva? Oké, hadd próbáljam meg újra, a junior tesztelők megfelelő időben javaslatot tehetnek a megfelelő embereknek.

Amikor egy funkció vagy modul fejlesztését a projektek kezdetén kezdjük el, általában minden javaslatot üdvözölünk. Kreatívan gondolkodunk, mert minden részletes élményre és felhasználói forgatókönyvre gondolnunk kell, hogy részletes és teljes tesztelési esetet írjunk. Ebben az esetben az építészek vagy tervezők a leginkább hajlamosak meghallgatni a javaslatokat és figyelembe venni ötleteinket.

Ha valóban úgy gondolja, hogy az Ön hozzájárulása értékes, és elvégezte a kutatást, akkor menj tovább és vakíts minket. Ha azonban a munkafolyamatokat, a bemutatókat és a javaslatainkat már jóváhagyták, végrehajtottuk és teszteltük, általában már túl késő megváltoztatni a dolgokat, függetlenül attól, hogy milyen nagyszerűek lehetnek az ötleted. És soha ne küldjön hibákat csak a saját preferenciái alapján.

3. Felejtsd el a tervező létezését

A renderelésekről, a munkafolyamatokról és a velük kapcsolatos kérdésekről nem lehet gyorsabb módja annak, hogy megtámadja az Ön tervezőjét, ha a fejük fölé kerül, és javítja munkájukat, vagy ami még rosszabb - a hibákat a tervekkel kapcsolatban. Szeretem a tervezőimet, és nagyon bízom kompetenciájukban, hogy ha egy funkciót egy módon megterveztek, akkor nagyon jó oka van annak támogatására. Tudom, hogy mekkora erőfeszítést tesznek a különböző ötletek kutatására, és tudom, hogy általában nagyon szoros együttműködésben vannak az ügyféllel, és valószínűleg jobban tudják az ügyfél felhasználói felületének igényét, mint én.

Ha teljesen őszintenek kell lennem, néha mégis elkövetem ezt a hibát, és a pillanat hevében úgy döntök, hogy valamit hozzáadom egy funkcióhoz anélkül, hogy először a tervezőmmel konzultálnék. A legjobb szándékkal csinálok valamit javítani, de a legjobb szándékom keveset jelent, ha megszakítom a megállapodott folyamatot, és váratlan késleltetést adok hozzá.

4. Döntsd el a készülékeidet

Ah, ó, a DEV-k megfélemlíthetik, a DEV-k irritálhatnak, a DEV-k arrogánsak és morcosak lehetnek. De a dev mindig a legjobb barátja, mindig! Tehát mindent megteszel, és bizalmi kapcsolatot létesítesz. Ön megy, és őröl, amíg nem tolerálnak téged, merem mondani, akárcsak te. Mert boldog DEV = boldog QA. Még ha 1000-szer is hallania kell, hogy „ez nem egy hiba, hanem egy funkció”, akkor megharapja a nyelvét és kitart. Ha nem hisz abban, amit a fejlesztõ elmond, akkor keressen egy idõsebb személyt és kérjen második véleményt. De ideális esetben a legjobb, ha bizalmi partnerséget tart fenn. Bíznod kell tapasztalataikban, és akkor bíznak a kompetenciádban. Ez egy gyönyörű szimbiózis, de törékeny.

A dev-knek bízniuk kell abban, hogy megvan a hátad, bár bár meg akarja tönkreteni a kódot, akkor a lehető legjobb szándékkal és a jobb érdekében csinálod. És bíznia kell abban, hogy néha, nagyon ritkán, a hiba valóban jellemző. :)

A dev btw felgyorsításának leggyorsabb módja az, ha kipróbál egy félig kész modult, és egy csomó hibát ad hozzá a dolgokhoz, amelyeket még még nem is valósítottak meg. Adj időt nekik, ne rohanj rájuk, és próbáld megtartani a lelkesedésed mindaddig, amíg a részükkel meg nem fejezték őket, és a te részed elindulhat.

5. Tegyük fel, hogy túl jó vagy a dokumentációhoz

Ahhh, itt vagyok dióhéjban. Számomra a leg unalmasabb feladat a teszt esetek írása vagy a meglévők módosítása új szélforgatókönyvekkel és információkkal, amelyeket a tesztelésem során feltártam. Amikor összegyűjti a lendületet és megvizsgálja a bizalmat, elkezdi kihagyni az alapokat. Úgy találja, hogy az idő túl nagy nyomást gyakorol arra, hogy zavarjon egy ellenőrzőlista-sablon követésével, így a memória segítségével végezheti el, az eredmények nyomon követése nélkül. Annyira biztos abban, hogy képes, elfelejti, hogy minden tesztelésnek látható lábnyommal kell rendelkeznie. Különösen akkor, ha önmagában kezeli a projektet, és minden apró részletet megismer, elfelejti a dokumentálás szükségességét, amely könnyen visszatérhet és megharaphat téged.

Én bűnös vagyok ebben, és a leghosszabb ideig kihagytam néhány lépést, hogy több idő maradjon más feladatokra. De bizonyos esetekben az őszinte szavunk nem számít, hacsak nincs dokumentumod, amelyről biztonsági másolatot készít. Ha például azt mondja, hogy valami visszaesés, mert korábban hibátlanul működött, és akkor valaki megkérdezi, hogy mutassa meg neki ezt, és nem teheti meg, akkor ez szakszerűtlennek tűnik. Soha nem tudhatod, mikor kerül átváltásra egy másik projektre, vagy valaki másnak át kell vennie a munkáját, és ez a valaki teljesen elveszik, hacsak nem tette meg a papír részét.

6. Nem végezte el az alapjait

Tegyük fel, hogy a projekt egy mobilalkalmazás, amelyet Android és iOS támogat. A junior tesztelő ellenőrzi az Android telefont, és lát egy összeomlást. A Junior eksztatikus, az összeomlás nagy ügy, ezért siess, hogy a lehető leghamarabb hozzáadják Jira-hoz, és felhívják a figyelmeztetést. Elfelejtik az összes többi lépést, amelyet meg kell tennie egy hiba hozzáadása előtt, különösen fontos. A probléma felvétele előtt van egy kis előkészítés. Az első dolog az, hogy ellenőrizze a dosszié-rendszer másolatát - bármilyen is legyen. Senki sem szereti a másolatokat, és hanyagul néz ki! A második az, hogy még néhány helyen ellenőrizzük, hogy ez a kérdés eszköz-specifikus, platform-specifikus vagy általános. Tehát jobb, ha egy Android táblagépet, majd egy iOS eszközt ellenőriznek. Hasznos lenne néhány naplót összegyűjteni, hogy a dev megtakarítson egy kis időt, hogy helyette megpróbálja reprodukálni és gyorsan ellenőrizze a naplókat. Hasznos azt is megnézni, hogy milyen gyakran reprodukálhatja a kérdést, minden alkalommal, vagy egy kicsit véletlenszerűbben. Válassza ki a probléma pontos lépéseit, és ellenőrizze a korábbi verziók és verziók ellenőrzését is, hogy újonnan bevezetett regresszióról van-e szó, vagy ott volt-e, és kihagyták-e az egészet.

Ezek a hibák a minőségbiztosítási út általános részét képezik, és természetes lépést jelentenek a tanulási folyamat felé. Most, hogy átadtam az örökség ezen értékes rakományát, kérjük, ossza meg velem az alábbi megjegyzésekben, ha ezen hibák valamelyikében hibázik, vagy esetleg vannak még megbocsáthatatlanok a minőségbiztosítási bűn miatt, amelyeket kihagytam.