TESZTELÉS A GYAKORLATBAN – A SZAKÉRTŐ TESZTELŐK LAPJA számára, mert néha nem egyszerű átlátni a lehetséges dependenciákat. Ebben az esetben fontos bevonni a fejlesztőket, vagy a software architektet a korai termékfelfedezésbe, hogy technikai szemszögből is lássuk a helyzetet. • Amint a függőségek tisztázása megtörtént, a termék menedzsernek el kell kezdeni előkészíteni a backlogot a csapat számára, ahonnan majd képesek lesznek felvenni a feladatokat maguknak, valamint implementálni, és tesztelni az új funkciókat. Legjobb esetben, a backlog már elő van készítve a következő sprintre, vagy hétre. Ez idő alatt, a termék menedzser előre tud dolgozni, hogy előkészítse az új funkciókat, vagy az ügyfelekkel egyeztetni, visszajelzéseket kérni. Ezzel a munkamódszerrel a csapatnak mindig vanelőkészített backlogja, és képesa termékeket, funkciókat szállítani minden iteráció után. 3. Az automatizálás javítása Egy szoftverfejlesztő csoportban az automatizálás az a másik dolog, amit javítani lehet. Ez nyilvánvalóan nem a termékmenedzser feladata. A termék menedzsernek azonban ismernie kell, hogy milyen előnyei vannak az automatizálásnak, és támogatnia kell abban a csapatot, hogy időt tudjon fektetni a saját infrastrukturája fejlesztésébe, ami segíti a csapatot a termékszállításban. Az automatizálással nagyon sok idő megtakarítható, amit például arra tudnak használni, hogy jobban megismerjék a terméket, és annak architekturáját. Mielőtt a csapat időt és pénzt fektetne az automatizálásba, előtte tisztán kell értenie, hogy mi az ami automatizálható, mi az amit érdemes automatizálni, és mi az amit nem4. Például, ha a termék, vagya termékegy részeakövetkezőhetekben gyakran fog változni, akkor nem a legjobb ötlet az automatizálás a korai szakaszokban. Másrészt, ha vannak olyan kritikus részei az alkalmazásnak, amely mindig működnie kell, fontos, hogy ezek le legyenek fedve automata tesztekkel a kezdetektől fogva. A csapatnak kell meghatározni, hogy a program melyik része, mikor, és hogyan legyen automatizálva. 4. A kulcs a dokumentáció. Mindig. Minden terméket dokumentálni kell, ideértve a termék fejlesztésének módját is. Melyek a támogatott szolgáltatások, hol vannak a potenciális problémák, vagy mi várható a jövőben? Könnyű feladatnak tűnik, de a legtöbb csapat nem fordít elegendő időt saját termékének és szolgáltatásainak dokumentálására. Ez a befektetett idő azonban hosszú távon megtérül és segíti a fejlesztési folyamat felgyorsítását. Különösen akkor, ha egy termék fejlesztése már régebb óta tart és a termék mérete is növekszik, ez a fajta információ segíteni fogja a csapatot visszaemlékezni a döntésekre vagy a termék architektúrájára. Ezen kívül a megbízható termékdokumentáció5 segíti az új kollégák bekapcsolódását. A dokumentáció áttanulmányozásával sokkal gyorsabban megértik a függőségeket és a termék logikáját. Ez elősegíti az új kollégák gyorsabb beilleszkedését a csapatba. Végül, de nem utolsósorban a jól dokumentált termék az érdekelt felek számára is segít abban, hogy több ismeretet szerezzenek a termékről anélkül, hogy megkérdezzék és ezzel megszakítsák a csapat munkáját. A termék informatikai infrastruktúrájától függően a termékdokumentáció elkészíthető ticketing rendszerben, wikiben vagy akár a kódbanmagában is. Itt az idő gyorsítani: készen állsz? A vállalatoknak arra kell koncentrálniuk, hogy csökkentsék a termékeik piacra dobásának idejét. Elég gyorsnak kell lenniük ahhoz, hogy kiszolgálják, kielégítsék a felhasználói igényeket, és versenyelőnyben maradjanak a többi vállalattal szemben. Azonban ez a fejlesztési gyorsaság nem jön ingyen. A csapatnak időt kell belefektetnie abba, hogy elemezze a jelenlegi munkamódszerét, folyamatait. A fejlesztés javítása érdekében, a következő kérdésekre kell megtalálni a válaszokat: • Világos-e a termékfejlesztési stratégia mindenki számára? • Világos,ésegyértelmű-emindenacsapatnak, ami ahhoz kell, hogy koncentráltan és függetlenül dolgozhassanak a termékükön? • Megvan a termék fejlesztéséhez szükséges tudás és készségek a csapatban? • A csapat a megfelelő technologiát, és tech-infrastruktúrát használja-e, és az naprakész-e? • Engedélyezve van-e, és tud-e a csapat időt áldozni az automatizálásra, és a dokumentálásra6? Szerző: Daniel Knott Forrás: https://www.applause.com/blog/4-stepsto-ship-your-products-faster 1. https://www.applause.com/blog/realtors-keysto-achieving-speed-and-quality 2. https://www.applause.com/blog/its-all-or-nothingon-agile 3. https://www.applause.com/blog/which-agile-are-you 4. https://www.applause.com/blog/the-properrole-of-test-automation 5. https://www.applause.com/blog/steps-to-maturingtest-automation 6. ht tps: //www.applause.com/blog/adopt ingautomat ion- is-essent ial -for-growth Daniel Knott Daniel mobil tesztelési szakér tő, aki vezető szof t vertesztmérnökként dolgozik az XING mobil csapatában. Szoftvertesztelési pályafutása 2003ban kezdődött az IBM-nél, mint gyakornok. Az IBMnél töltött idő után szoftverfejlesztést és tesztelést tanult. 2009 óta olyan cégeknél dolgozott, mint az Accenture, az AOE és a XING. Számos mobil tesztelési automatizáló eszközzel kapcsolatos tapasztalattal rendelkezik, mint például a Robotium, a Calabash for iOS / Android, az Espresso és a Keep It Functional. Ezen eszközök segítségével kifejlesztett egy teljesen automatizált tesztelési környezetet Android és iOS számára. Szeret i megosztani tudását , ezér t elkezdte leírni tapasztalatait a www.adventuresinqa.com blogjában, valamint számos tesztelési magazinban. Európa különféle konferenciáinak előadója, és 2014 óta a Hands-OnMobile App Testing könyv szerzője. 11 . oldal TESZT MANAGEMENT
RkJQdWJsaXNoZXIy MTEyMzcyNw==