Hatékony minőségbiztosítási bevált gyakorlatok

A Effective munkatársaként több mint 30 különböző projektben vettem részt. Mindegyik teljesen különböző volt: internetes és mobil, nagy és kicsi, bonyolult és egyszerű. A nulltól kezdve építettünk projekteket, új funkciókat adtunk hozzá és fenntartottuk a meglévő projekteket.

Sok trükkös eset volt a minőségbiztosítási folyamatban, a tesztelésben, a menedzsmentben és a fejlesztésben, és most úgy érzi, hogy csapatunk átjutott a Per Aspera ad Astra-n.

Jelenleg úgy érzi, hogy semmi különlegeset nem tettek, de amikor összehasonlítjuk a Effective-t, akkor azt mondhatom, hogy óriási lépést tettünk előre. A hibák elemzése, a csapat kívánságai és javaslatainak elemzése során elkészítettem a következő legjobb gyakorlatok listáját a minőségbiztosításhoz. E lista célja, hogy segítse a fiatal csapatokat megérteni, mi hasznos lehet számukra anélkül, hogy sok időt fordítanának a kutatásra. Néhány tapasztalt számára ez a kerékpár újraalkotásának tűnhet :) Itt vagyunk!

Értse meg az üzleti célokat, és tegye egyértelművé az elfogadási kritériumokat

Ez a projekt sarokköve, amelyet tisztázni kell a fejlesztés megkezdése előtt. A projektcsapatnak meg kell értenie, mit kell tenni, ki a célközönség / a szolgáltatás fogyasztója, és hogyan kell megérteni, hogy nincs mit tennie.

Az üzleti célok megértése segít olyan kérdések megválaszolásában, mint „Mit kell tennünk, és ki fogja használni?”. Az elfogadási kritériumok segítenek megérteni, hogy egy szolgáltatás megfelel-e az üzleti céloknak. Tapasztalataim szerint elmondhatom, hogy az üzleti célokat és az elfogadási kritériumokat az ügyfélnek vagy az ügyfél képviselőjének meg kell erősítenie. Ezen felül, egyértelmű és átlátható üzleti célok és elfogadási kritériumok alapján a képzett szoftverfejlesztő cégek továbbfejleszthetik üzleti ötletüket vagy javaslatot tehetnek egy jobb megoldásra.

CI / CD - folyamatos integráció / folyamatos telepítés

Ismerősnek hangzik ... nem igaz? A jelenlegi szoftverfejlesztés egyik trendje, amelynek fő előnye a minőségbiztosítási csapat szempontjából az, hogy könnyen megszerezhetjük a legújabb funkciókat vagy javításokat.

A fejlesztési ciklus alatt fejlesztői csapatunknak sok különböző funkciója lehet, amelyek a gépeket tartalmazzák, de csak az egyik ága tartalmazza a legfrissebb kódot. A CI eszköz ellenőrzi ezt az ágot, és amikor a kód megváltozik, új összeállítást hoz létre, és megosztja azt egy meghatározott terjesztési szolgáltatással.

Kipróbáltuk a TeamCity-t és a Jenkins-t. Mindkettő nagyszerű eszköz. A TeamCity szebb felhasználói felülettel rendelkezik, de a Jenkins teljesen ingyenes, tehát a Jenkint választottuk.

Alkalmazás-terjesztési szolgáltatások

Általában nem tűnik különösebbnek, de a motorháztető alatt a hangolt alkalmazástelepítési szolgáltatásokkal történő folyamatos integráció lehetővé teszi a legkönnyebb és leggyorsabb módszert a kívánt tesztelőeszközre vagy környezetre történő legújabb felépítéshez. Rendben, ha az összeállítást USB-n keresztül töltjük fel egy eszközre. De mi van, ha 10 különféle eszközzel kell ellenőriznie az összeállítást? Ez a lényeg.

Mobil projektekhez néhány különféle szolgáltatást kipróbáltunk, mint például a HockeyApp, a Beta by fabric (ex-Crashlytics), az Apple Test Flight, a Google Play Console. Természetesen több szolgáltatás is létezik, de ezeket választották a legnépszerűbbeknek. Most a Test Flight and Play Console mellett szavazom, mivel ezek a szolgáltatások rugalmasak, támogatják a belső és külső tesztelő funkciókat, valamint az Apple és a Google hivatalos szolgáltatásait, és csak a tesztelők e-mailjére van szükség. Az egyetlen korlátozás az, hogy szükség van Apple és Google fejlesztői fiókra, amelynek költsége 25 USD a Google számára (egyszeri fizetés) és 99 $ az Apple számára (évente).

Más szolgáltatások, például a HockeyApp vagy a Beta, némi nehézséggel járnak az új tesztelők felvételével a projektbe, különösen iOS esetén. Az Apple biztonsági gondozása miatt a tesztelőktől az eszközök UDID-jét meg kell adni a fejlesztőnek, és a fejlesztőnek ezeket a UDID-ket hozzá kell adnia a projekthez. Mivel a dev építkezéseket megosztjuk ügyfeleinkkel (akiknek általában nagyon sok különböző eszköze van, és rendszeresen cserélik őket), mindannyian belefáradtunk az UDID gyűjtési tevékenységeibe. Ezért választottuk a Test Flight and Play Console lehetőséget.

Webes projekteknél minden kissé egyszerűbb, mert egy speciális tesztelési környezetet használunk, amelyet a CI eszköz frissít, amikor a fejlesztési ág megváltozik.

Tesztelési dokumentáció

Az évek során a minőségbiztosítási csapat négy legértékesebb dokumentumot találott ki, amelyeket meg lehet osztani az ügyfelekkel vagy az érdekelt felekkel:

  • Támogatott platformok
  • Teszt terv
  • Teszt esetek / ellenőrző listák
  • Kiadási megjegyzések

A támogatott platformokról szóló dokumentumot a lehető leghamarabb el kell készíteni, amikor a projekt megkezdődik, és az ügyféllel alá kell írni. Információt kell tartalmaznia a támogatott hardver- és szoftverkonfigurációkról, az ismert korlátozásokról és korlátozásokról. Ez a célközönség eszközein is alapul, mivel az eszközök piacai az egyes országokban eltérőek.

Ha ügyfeleinkkel aláírjuk, garantáljuk, hogy egy termék első verziója tökéletesen működik a felsorolt ​​konfigurációkban, emellett tudatjuk ügyfeleinknek, hogy a termék más konfigurációkban is működhet, de bizonyos problémák felmerülhetnek. És ha a termék és a célközönség növekszik, képesek leszünk elemezni és megvalósítani a kiegészítő platformok támogatását. A jövőben ez a dokumentum lehetővé teszi számunkra, hogy a meghatározott fejlesztési platformokra és a hibajavításra összpontosítsunk.

A vizsgálati tervet szintén elején el kell készíteni, és meg kell osztani az ügyféllel. Ennek a dokumentumnak tartalmaznia kell az összes olyan tesztelést, amelyet a termékfejlesztés során alkalmaznak, az egyes típusokra leírt céllal. A teszttervben a minőségbiztosítási csapatnak kell eldöntenie, mit használ a teszteléshez, a teszt esetekhez vagy az ellenőrző listákhoz. Általában ez a projekt időtartamától és funkcionális összetettségétől függ. A támogatott platformokat össze kell kapcsolni a teszttervvel is. És végül, a teszttervnek információkat kell tartalmaznia a tervezett tesztelési tevékenységekről a projekt kidolgozását követő dátumokra és a kiadási ütemtervre.

A tesztelési esetek / ellenőrző listák minden projektnél szükségesek. Természetesen időbe telik ezeknek a dokumentumoknak a elkészítése, és további időbe telhet a dokumentáció támogatása, de ad egyfajta fa törzst, és ezt a törzset használva könnyen elképzelhető, és új tesztelési forgatókönyveket készíthet, ha ágakat ad hozzá a a csomagtartó. Később megoszthatja az elkészített teszteseteket az ügyfél oldalán lévő UAT-csoporttal vagy a béta tesztelőkkel, vagy akár bemutathat próbatesteket a projekt fejlesztői csoportjának. A fejlesztői csapat a teszt eseteit felhasználhatja a követelmények részeként, és ez valóban segíthet nekik bizonyos kérdések elkerülésében.

A Effective-nál sok TMS-t (tesztmenedzsment rendszer) kipróbáltunk, és a TestRail-t választottuk az egyik legnépszerűbb, testreszabható, gyors és kényelmes eszköznek a teszt esetek kezelésére és a teszt menedzsmentjére. A TestRail használata lehetővé teszi, hogy a teszt eseteit és az ellenőrző listákat könnyen naprakészen tartsuk. Számunkra ez az eszköz nagyszerű, de még mindig van sok alternatíva. A fő tipp itt a megfelelő TMS használata, és ne használja a Google Dokumentumokat és Táblázatokat teszt esetekhez és tesztnaplókhoz :)

A kiadási megjegyzések a minőségbiztosítási csapatunk által az ügyfelek számára készített dokumentum, amely a projekttel kapcsolatos aktuális információkat tartalmazza. Milyen funkciókat készítettek az adott sprintben, mi még mindig folyamatban van, ismert problémák, hol és hogyan lehet letölteni a demo összeállítást. A kiadási jegyzeteket mindig sprint és kiadás alapján készítjük. További átláthatóságot biztosít ügyfeleink számára a fejlesztés előrehaladásáról.

Felfedező tesztelés

Az utolsó dolog, amelyet soha nem szabad elfelejteni, a feltáró tesztelés. Ennek a tesztelésnek az a fő célja, hogy jobban megértse termékét, és a felhasználó szempontjából nézzen rá. A felfedező és a szkripttestek kombinálása (szkripttestelés alatt teszt esetekre vagy ellenőrző listák használatára gondolok), a tesztelő és a felhasználó által a termékről alkotott felfogás kombinálása, valamint az üzleti célok szem előtt tartása révén a dolgozó terméket a lehető legtökéletesebbé teheti.

A felderítő tesztelés részeként raj-tesztelési megközelítést is alkalmazunk. A Test Flight és a Play Console használatával külső tesztelőket hívunk meg, akik általában hatékony alkalmazottak, akik nem vesznek részt a projektben, és béta tesztelőkké válhatnak. Ez lehetővé teszi számunkra, hogy a termék szempontjából áttekintést kapjunk a felhasználó szemszögéből, és ügyeljünk a használhatóságra.

A hatékony minőségbiztosítási bevált gyakorlatok összefoglalása:

  • Megérteni az üzleti célokat
  • Tegye egyértelművé az elfogadási kritériumokat
  • Ismerje meg a támogatott platformokat
  • Készítse el a vizsgálati tervet
  • Használjon teszt eseteket / ellenőrző listákat
  • Használja a folyamatos integrációt és a folyamatos telepítést
  • Tartsa naprakészen a teszt eseteket / ellenőrző listákat
  • Oszd meg a kiadási megjegyzéseket az ügyfelekkel
  • Soha ne felejtsük el a feltáró tesztelést

Köszönöm, hogy elolvasta! Nyugodtan kommentálhatja, ha többet szeretne megtudni, nem ért egyet vagy kérdése van :)