Caracalla blogja

Internet, jog, játék

Kontakt és egyéb infók

CC ígéret

Creative Commons Licenc

Címkék

7; (1) acta (1) adatvedelem (9) adobe (1) agile (2) ai (2) ajanlo (4) allami szfera (10) álláskeresés (1) állás keresés (1) amazon (2) amd (1) apollo (1) apple (5) artisjus (4) at&t (1) atom (1) biztonsag (5) blackbox (1) blog (26) blogter (3) bsa (4) budapest (5) bug (2) bullshit (2) buntetojog (7) censorware (7) chrome (1) cikkek (1) cisco (2) cloud computing (1) complex (1) copyright (44) creative commons (1) cyberspace (2) cybersquatting (3) cybook (1) datacenter (1) dea (1) digg (2) digitalis jog (1) digitalis utonallas (27) digitalis vilag (33) dmca (3) drm (21) ebédidő (1) ebook (4) ecj (1) ego (29) elektronikus alairas (1) életem (1) életem nem mindennapjai (1) életképek (1) élmények (1) email (3) empire tw (2) én (1) énblog (2) ensz (3) epub (2) étkezés (1) eu (19) eu self (1) e archiving (1) e kereskedelem (3) facebook (5) fantasy (1) fcc (4) fec (1) feed (14) feedburner (4) felsooktatas (5) filecsere (32) franciaorszag (3) frekvenciagazdalkodas (1) fud (5) gaming (1) gmail (2) goldenblog (3) google (13) google reader (3) gpl (1) grammar nazi (1) gyermekpornografia (1) hackers not dead (1) hadopi (2) hardware (4) harvard (1) hoax (1) hoi3 (1) hr (1) humor (8) hvg (8) hvg.hu (1) i2010 (1) ibm (2) identity (4) identity system (3) index (22) innovacio (18) intel (2) intellectual property (20) internet (107) internethungary (1) iptv (1) iso (1) isp (2) iwiw (4) jatekszoftver (10) java (1) jog (109) jogdij (3) jogelmelet (1) jogiforum (3) jogtar (3) kalozkodas (14) kína (3) kina (1) kinai nepkoztarsasag (1) konferecia (1) konyv (1) kozigazgatas (6) kozjoszag (2) kozos jogkezeles (5) kreativitas (1) kritika (4) kultura (3) lcd (1) leírások; (1) lessig (3) link (1) linux (12) lol (11) magas tudomany (1) marketing (10) media (32) microsoft (23) microsoft; (1) miner (1) mobilvilag (4) mobipocket (2) mp3 (6) mpaa (1) msi wind (1) mszh (2) mti (1) muveszet (1) myspace (2) nagy britannia (1) nemzetkozi jog (1) nepszabadsag (1) netscape (1) netvibes (1) net filtering (3) net neutrality (12) nin (1) nyelvtan (1) odf (1) office software (1) olaszorszag (1) online ujsagiras (2) openness (2) openoffice.org (3) opensocial (2) open access (1) open source (21) origo (8) os (1) osi (1) outsourcing (1) oxml (1) p2p (6) pagerank (1) pc szereles (1) phd (1) piac (8) politika (29) privacy (11) ps4 (1) rant (70) reklam (3) ria (2) riaa (12) rpg (2) rpg.hu (1) rss (5) saas (2) sajto (1) serveros (1) silverlight (1) smo (2) software (1) sony (4) spam (8) spectrum auction (1) steam (3) sun (4) superego (1) szabadalom (4) szabvany (5) szerzoi jog (38) szjt (3) szoftverfejlesztes (3) szoftverszabadalom (6) szoftverteszteles (2) szolasszabadsag (5) techcrunch (1) telekommunikacio (10) terminartors (1) tippek; (1) toshiba (1) total war (1) trükkök; (1) tudaselmelet (3) twitter (4) ubuntu (2) ugyfelkapu (2) uncov (1) upc (1) usa (15) uspto (2) vedjegy (2) verizon (3) verseny (9) virtualis haboru (1) virtualizacio (1) vista (3) vodafone (2) voip (1) wardriving (1) warez (1) web2.0 (27) webos (2) welcome to hungary (30) wifi (6) wiki (1) wikileaks (1) wikipedia (4) wimax (1) windows (9) windows; (1) winer (5) xml (2) xp (3) yahoo (1) youtube (3) zene (5)

Friss topikok

  • Szedlák Ádám: Plusz kérdés: képes lesz-e a Sony a kínált funkciókat az egész világon bemutatni és üzemben tartan... (2013.03.01. 14:25) PS4
  • lipot: Olvasgattam a korábbi posztokat, belinkelt törvényeket és lehet, hogy egyértelmű, azért mégis szer... (2011.01.20. 10:28) Bejelentésköteles a webbolt működtetése, hogy is van ez?
  • Boca: Lehet h így van, de ezek hatása egyelőre nem látszik, mert a user kezében lévő technológiákkal kön... (2010.12.29. 06:09) A WikiLeaks internetszabályozási ötletelést vált ki
  • Caracalla: Konrád, nem vitatva amit írsz, kiadói oldalról az nem mentség, ha azt hozzák fel, hogy nem értenek... (2010.10.09. 19:05) A könnyűlovasság károgása
  • emzperx: Már az iwivvel is ez volt az egyik fő probléma úgyhogy ez spanyolviasz. Megyek is a subbára balfék... (2010.05.17. 01:53) Életek a Facebook

2012.07.30. 17:42 Caracalla

Alkalmazott agile szoftvertesztelés

Címkék: agile szoftverfejlesztes szoftverteszteles

Kicsit több mint egy éve csaptam fel webes fejlesztőcégnél tesztelőnek, amely agilis módszerekkel dolgozik (előtte is volt közöm a szoftverekhez), és én vagyok a legszeniorabb, a ‘vezető’ tesztelő (a munkaidőm egyharmadában meg projektmenedzsmenttel, projektadminisztrációval foglalkozom). Így talán nem túl meglepő, hogy olyan módszertani kérdések is foglalkoztatnak, amelyek egy nagy, kialakult szervezetben dolgozó tesztelőt többnyire nem.

Az egyik, hogy mi a viszonya az agilis fejlesztésen belül a tesztelésnek az egyéb funkciókkal (BA/architect/dev/sa/customer support).  A waterfallban ugye elég egyértelmű, egy leginkább a gyártásból ismert utólagos minőségellenőrzés, amit a minőségmenedzsment irodalom többnyire a quality control néven szokott ismerni (a különbség az, hogy a gyártásban az elhibázott példány többnyire kuka, vagy akciósan megvehető, mint a hárommagos processzor). Jobb műhelyekben ez kiegészül olyan mérőszámok követésével, amik a kódról már megírásakor mondanak ezt-azt (ciklomatikus komplexitás, valamilyen notation követése régebben, code review, unit testelés pl.), amikor már valóban beszélhetünk minőségbiztosításról, quality assurance-ről.

Ehhez képest az agile iterációkban dolgozik, és ilyen értelemben az utólagos minőségellenőrzés rögtön megkérdőjeleződik, mert ami a funkciónak a vége, az az értelmes szoftvernek még nem, illetve nincs rá garancia, hogy nem . A mindennap release-elhető állapotú kód, az megint ellentmond ennek az utólagos tesztelésnek.

Két igazán komoly problémát látok egy agilis projekten való tesztelésen.

Az egyik a build stabilitás. A gyakori build, változások miatt sokszor lehetetlen azonos kódon végrehajtani a teszteket (ha nem az a greatest-latest, akkor pedig az lesz a válasz a bugokra, hogy a legújabbon is van, és tegyük hozzá, valóban nincs sok értelme egy már nem aktuális verziót tesztelni).

A másik az elvárt állapot dokumentációja, ami a sok iteráció alatt könnyedén elmarad az aktuálistól, esetleg nem is létezik, vagy csak valami megtévesztésre jó, részleges, helyenként elavult formában. Az sem segít, hogy a tipikusan kevés upfront tervezéssel dolgozó agile esetén rendszeresek a meglepetések.

A szakirodalom válasza ezekre többnyire az automatizálás. Buildet, unit, komponens, gui, teszteket automatizálni, 100% coverage-re lőni, stb. Ezek a könyvek többnyire tele is vannak olyan példákkal, miszerint “A 13 fős, 3 BA, 4 fejlesztő, 4 tesztelő és kettő valami menedzserből álló team azzal a problémával szembesült, hogy” - ami gondolom mindenkinek látható, hogy nem reális az itthoni viszonyokra. Arról nem is beszélve, hogy a tesztelők mind kiválóan értenek a fejlesztéshez, sőt, akár az architect munkájának szakmai felügyeletére is felkészültek, és természetesen a fejlesztés TDD alapokon folyik.

Azok alapján, amit én láttam, ez itthon és külföldön is eladhatatlan. Az, hogy átlagosan egy fejlesztőn még másfél embernyi (+menedzsment) overhead legyen, a megrendelőknél, részvényeseknél kiveri a balhét. Outsourcingban más nyeri a megbízást, a belső IT-t meg kiszervezik (paradox módon olyat viszont már láttam, hogy profi tesztelők nélkül üzemeljen egy 5+ fejlesztőgárda, igaz jobbára nem is fejlesztettek semmit, amikor meg igen, akkor az rossz minőségben sikerült). A dolog kevésbé problémás, minél nagyobb a projekt, mert ha relative nem is több, de mégis van egy rendes tesztelői team, ami kisebb projekteken nem jellemző.

Ehhez az is hozzátartozik, hogy a piaci viszonyok között aki elég jó, az ritkán marad tesztelő. Többnyire átáll fejlesztőnek, és főképp architektnek, a fejlesztők vagy bukott mérnökök, vagy kívülről érkezett szerencselovagok (én is ebbe a kategóriába tartozom) ésvagy nem tervezik, hogy sokáig tesztelők maradjanak. Ebből következően elég sok cég szenved a teszteléssel.

Magunk között szólva a megrendelőnek és a részvényesnek azért van igazsága. Nem minden esetben kellene 15 éven át fenntartható, atomstabil rendszer, különösen a webes fejlesztések nagy részében vállalható alacsonyabb minőség is. Más kérdés, hogy nem azonosan skálázódik a minőség meg az automatizálás, és hogy ha a megrendelő számára egy (pár) iteráció tervezett a szoftver életciklusára, akkor nem is éri meg. Különösen jól látható ez az egyébként is érdekes üzleti területet képviselő mobilalkalmazásoknál.

Hogyan lehet mégis biztositani egy viszonylag jó minőséget?

Automatizálni kell, de értelmes helyen. Elsősorban a különböző build/property szerkesztéseknél tud ez nagyon jól jönni. Eközben a cross-browser GUI automatizáció valószinüleg nem térül meg, marad az, hogy valaki manuálisan végignézi több környezetben is szisztematikusan a szoftvert. Azaz ha az ügyfél nem fizeti meg, bizony csak ott érdemes automatizálni, ahol valóban megtérülést hoz.

A másik, ami viszonylag működik tapasztalatom szerint, az a hagyományos quality police szemlélet visszacsempészése. A tesztelő amennyiben elér egy elég komoly domain ismeretet (például a félkész dolgokkal való foglalkozás helyett erre is gyúrhat), és egyben tölthet el viszonylag értelmes mennyiségű időt az elvileg már kész szoftverrel (ami központi agile elvekkel ellentétes), funkcionálisan, vizuálisan, használhatóság szempontjából biztositható egy jó minőség. Ha a fejlesztőkkel közösen sikerül még skálázhatósági és teljesitmenyellenörzéseket is végezni, akkor még tovább emelhető a minőség.

Tökéletes? Nyilván nem. Agilis? Egyes elemeiben.

Ellenben a gyakorlatban alkalmazható, nem pazarló és eredményt lehet vele szállitani.

Szólj hozzá!

A bejegyzés trackback címe:

http://caracallablog.blog.hu/api/trackback/id/tr524687104

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

Nincsenek hozzászólások.