[Java lista] Szoftver-tesztelés

[Gábriel Ákos]

"Számomra a másik rendszer fejlesztőjének mocskolása nem elfogadható."
Sajna van, amikor kell. Persze nem érzelmi alapon, hanem szigorúan
tények mentén. Az előző levelemben elég rosszul fogalmaztam, sorry.

Tehát ha a külső rendszer sokszor nem a specifikációjának megfelelően
működik, és ezt bizonyítani tudjuk, akkor van olyan érv a kezünkben,
amivel az ügyfelet meg lehet győzni arról, hogy bár ezt a rendszert
korábban nem "takartuk el", azaz nem mockoltuk, de épp ideje lenne, mert
folyamatosan csak a gond és a többletkiadás van miatta.

A tisztességesen letesztelt rendszerekkel nem szokott probléma lenni,
vagy ha igen, az egyszerűen és gyorsan javítható.

A mockolásnak látom még egy problémáját: tfh van egy rendszerem, amely
több másiktól függ (integrál). A rendszerem a mockolt alrendszerekkel
jól működik. Majd kirakom élesbe, ahol már semmi nem mockolt, és jön a
hiba. Az ügyfél nálam látja a hibát, hol máshol. Tehát az a minimum,
hogy nekem meg kell keresnem melyik alrendszer a hibás, és rá is kell
mutatnom. Jó esetben az alrendszer gazdája elismeri felelősségét, rossz
esetben nem. Ennek igen jelentős költsége tud ám lenni, és ha ad
absurdum emiatt az éles rendszer (vagy egy része) borul, akkor az ügyfél
nagyon zabos bír lenni.

Ha nem mockolunk, fejlesztési időben kijönnek ezek a hibák, akkor fele
ennyire nem ideges az ügyfél. A költség persze a miénk...

Még egy: ahhoz, hogy mockoljunk, stabil API kell, a mockolt szolgáltatás
részéről, ugye? Mit csinálunk, ha a mockolt szolgáltatás szállítója ezt
nem tartja be? Bármilyen okból... (és itt legalább 3-at tudok mondani)


On Tue, 2010-09-07 at 14:29 +0200, Istvan Verhas wrote:
> Valójában nem is a fejlesztő/szállító cég feladata a User Acceptance Test elvégzése, hanem a User vagyis a vevő feladata és költsége. Ideális esetben ez a tevékenység a minőségbiztosítás része és egy harmadik független (a szállítótól független) fél végzi el.
> Azt én is tudom, hogy az elmélet és a gyakorlat csak elméletben azonos.
> Azért néha mégsem árt átgondolni, hogy mi az amitől eltérünk és mennyire. Számomra a másik rendszer fejlesztőjének mocskolása nem elfogadható. Már csak azért is érdemes ezzel óvatosnak lenni, mert lehet, hogy ő letesztelte tisztességesen és dokumentálni is tudja. Hosszútávon mindenképp kifizetődő az "egyetemi szintű" tesztelés.
> Én mockolok nem mocskolok.
> 
> üdv
> vi
> 
> Verhás István
> JIRA szakértő
> Verhás & Verhás Szoftver Manufaktúra Kft.
> istvan at verhas.com
> t: +36(30)3997117
> skype: verhasi
> 
> On Sep 7, 2010, at 7:55 AM, Gábriel Ákos wrote:
> 
> > Kedves István,
> > 
> > Egyetemi szinten tökéletes amit írtál. De az élet nagyon sokszor mást
> > mutat. Ha valaki mint fejlesztő cég elkövette azt a hibát, hogy a külső
> > rendszerek "mockolását" nem vette bele a projekt scope-jába - márpedig
> > elköveti, mert másképp nem nyerhet, mert túl drága lesz - akkor ez így
> > marad. Ilyenkor politikailag egy módszer marad: addig kell mocskolni a
> > másik rendszer fejlesztőjét (joggal vagy anélkül) amíg a felhasználó
> > bele nem egyezik, hogy az ő költségére pluszban ki lehesen fejleszteni a
> > mockolást. Akinek van jobb ötlete, írja meg! :)
> > 
> > Üdv,
> > Ákos
> > 
> > 
> > 
> > 
> > On Tue, 2010-09-07 at 00:28 +0200, Istvan Verhas wrote:
> >> Szia Gábor!
> >> 
> >> Hosszú leveldből számomra az világli ki, hogy számodra a tesztelés egy összetett és bonyolultan egymáshoz kapcsolódó rendszerek esetén túl nagy falat. Van egy jó hírem, ez a nagy falat is megehető apránként. Persze több idő is kell hozzá mint egy szendvicshez. Konkrétan például a leírásodban folyamatosan keveredik a modul/rendszer szintű funkcionális teszt és az integrációs teszt. Modul/rendszer alatt értem azt amire azt írod, hogy belső vagyis amihez képest külső rendszerek is kapcsolódnak. A modul szintű funkcionális tesztelés során egyetlen külső rendszert sem szabad/célszerű bekapcsolni a tesztbe, hanem azok helyett mockolt külső szolgáltatásokkal kell tesztelni. Ideális esetben a partner(ek) is megteszik ezt és utána az integrációs teszt már csak egy pipa. A valóságban, amikor a partnerek ezt nem teszik meg, akkor is nagyon hasznos ez a szétválasztás mert amikor előjön a hiba az integrációs teszt során, akkor igen jó eséllyel tudsz rámutatni az éppen bekapcsolt külső szolgáltatásra mint hibaforrásra. Igen a külső rendszereket sem egyszerre célszerű bekapcsolni, hanem egyesével. Ha a funkcionális tesztelés automatizáltan futtatható, akkor ez nem okoz plusz költséget vagy elhanyagolható.
> >> Az integrációs teszt elvégzéséhez természetesen szükség van az integrációs teszt környezetre. Ha ez nem áll rendelkezésre akkor az előbbi ügymenet adott fázisában könnyebben menedzselhető a felelősség kérdése és nincs vagy legalábbis kevesebb az egymásra mutogatás.
> >> A classpath probléma maven-el is előfordulhat, de azért ahhoz nagyon ügyesnek kell lenni.
> >> üdv
> >> vi
> >> 
> >> Verhás István
> >> JIRA szakértő
> >> Verhás & Verhás Szoftver Manufaktúra Kft.
> >> istvan at verhas.com
> >> t: +36(30)3997117
> >> skype: verhasi
> >> 
> >> On Sep 5, 2010, at 10:18 PM, Auth Gábor wrote:
> >> 
> >>> Halihó!
> >>> 
> >>> 2010. szeptember 5. 21.11.07 dátummal András Csányi az alábbiakat írta:
> >>>>> Tegye fel a kezét, akinél egy közepesen összetett program a teszt- és az
> >>>>> éles környezetben azonosan viselkedett... :) 
> >>>>> Egy kezet se látok...  akkor meg minek annyit tesztelni? :D
> >>>> Gábor, közepesen összetett programteszt...?
> >>> 
> >>> Mondom közepesen összetett program... :)
> >>> 
> >>>> Ha nem tudod megcsinálni azt, hogy a tesztkörnyezetben futó szoftver
> >>>> és az éles környezetben futó szoftver ugyanúgy viselkedjen, akkor
> >>>> valamit benéztél. :)
> >>> 
> >>> Vagy nem láttál még közepesen összetett rendszert, ez kb. 5-10 millió 
> >>> programsortól kezdődik és legalább egy tucat külső rendszerhez kapcsolódik. 
> >>> Ekkora "saját" rendszert nem kihívás tesztelni, ha viszont SOA elvek mentén 
> >>> állandóan önmagát hívja keresztül-kasul, akkor az egész működését viszont 
> >>> igazi művészet - főképp, ha a kódbázis kétharmada a külső rendszerekkel való 
> >>> kommunikációért felelős... :)
> >>> 
> >>> Ha ehhez hozzávesszük, hogy a külső rendszerek közül van, amelyiknek csak és 
> >>> kizárólag éles verziója van éles adatokkal, akkor ez eléggé aknamezővé teheti 
> >>> a teszteket, ilyenkor szokták a félősebb időszakokban azt mondani, hogy majd 
> >>> kieső órákban éles üzemben teszteljük, legfeljebb visszaállunk. :)
> >>> 
> >>> Van eset, amikor a külső rendszernek van ugyan teszt környezete, de csak 
> >>> időnként érhető el, és akkor is jelentősen limitált teljesítménnyel. Ennél 
> >>> csak az rosszabb, amikor közös interfésze van az éles és teszt rendszernek, és 
> >>> a kérés egy paramétere - jó esetben ez egy flag, rossz esetben 0-y közötti 
> >>> azonosítóval teszt adatok, x-végtelen között éles azonosítók vannak, s ez 
> >>> rendelkezik arról, hogy most tesztelünk vagy éles üzemből érkező módosítást  
> >>> kérünk.
> >>> 
> >>> Van olyan, amikor egy a külső rendszer teszt környezete egyben fejlesztői 
> >>> környezet (jobb esetben integrációs környezet), ekkor egy hibás válasz esetén 
> >>> tesztelő legyen a talpán, aki eldönti, hogy mi és hol okozta a hibát. 
> >>> 
> >>> Van olyan, amikor nem a külső rendszer teszt környezete a hibás, hanem a két 
> >>> helyet összekötő (teszt- vagy backup-)hálózaton tesztelnek vagy javítanak a 
> >>> hálózatért felelős emberek, az öt évvel ezelőtt megszűnt cég meghalt 
> >>> fejlesztője által fejlesztett modul pedig misztikus hibaüzenetekkel 
> >>> szórakoztatja az üzemeltetést, aztán az üzemeltetés a fejlesztést, azok pedig 
> >>> hosszas tanácstalanság után halkan rákérdeznek, hogy a hálózattal van-e valami 
> >>> gond, mire kiderül, hogy van azzal gond, de a hálózatosok úgy gondolták, hogy 
> >>> 50 százalékos csomagvesztés egy teszt környezetben nem ok arra, hogy szóljanak 
> >>> róla.
> >>> 
> >>> Van olyan, amikor egy-egy szerver költözik karbantartás vagy gépterem 
> >>> reorganizáció kapcsán, vagy az élesben éppen meghibásodott, ezért a teszt 
> >>> környezetből pótolták, és amíg megjön a megrendelt dolog, addig fél lábon vagy 
> >>> ülve kibírja a teszt rendszer az a három hónapocskát. Persze három hónapig 
> >>> csak álom a teszt és az éles azonos működése.
> >>> 
> >>> Arról nem is beszélnék, amikor ránézésre szinte bitre ugyanaz az alkalmazás 
> >>> szerver teszt rendszeren gond nélkül működik, éles környezetben pedig az egyik 
> >>> láb baromságokat csinál - megtörtént eset. Nem kellett végül fekete kakast 
> >>> áldozni éjfélkor a gépteremben, az ok triviális volt. Volt két azonos - de 
> >>> eltérő verziójú - jar fájl a classpath-on, és valami fájlrendszerbeli ok miatt 
> >>> az összes szerver a jót találta meg elsőre, ezért nem próbálkozott meg a rossz 
> >>> betöltésével, a különc szerveren viszont a rosszat találta meg elsőre, ezért 
> >>> volt hibás - persze miért ne az éles környezetben történjen ilyen... :)
> >>> 
> >>> További problémák lehetnek a működési paraméterek különbözősége, hiszen a 
> >>> teszt rendszernek teszt adatbázist kell elérnie, teszt felhasználókkal, és jól 
> >>> látható módon jeleznie kell minden felhasználóval való kapcsolata esetén, hogy 
> >>> teszt rendszerről van szó. Ezért az éles üzemhez más paraméterezéssel kell 
> >>> futnia, mint teszt környezetben, és itt szoktak eltérések mutatkozni, jó 
> >>> esetben feltűnő módon, esetleg működésképtelenséget okozva (hálózatilag 
> >>> elszeparált éles és teszt környezet), rossz esetben sunyi módon az éles üzembe 
> >>> tett modul a teszt környezethez csatlakozik, vagy fordítva.
> >>> 
> >>> Ezen túl gyakori, hogy a teszt környezetben nincs annyi és olyan gép, hogy 
> >>> terheléses, illetve stressz teszteket lehessen futtatni. Gyakran éles üzemből 
> >>> levedlett gépek kerülnek a teszt környezetbe, gyakran még ilyen gépek se. 
> >>> Mostanában divat a virtualizáció, így sok esetben az éles környezet fizikai 
> >>> hardveren fut, a teszt környezet pedig virtualizálva, ez is jelenthet apró 
> >>> működésbeli különbségeket.
> >>> 
> >>> Olyan céget igen keveset láttam, ahol sikerült volna elérni a "klasszikus" 
> >>> éles-, teszt-éles-, stressz-teszt- és/vagy QA-teszt-, felhasználói-teszt- 
> >>> és/vagy funkcionális-teszt-, illetve integrációs környezeteket. Olyat még 
> >>> egyet se, ahol ezek mind egyformán működtek volna... :)
> >>> 
> >>> Szóval összefoglalva: egy közepesen összetett program és/vagy rendszer 
> >>> esetén én még nem láttam azonosan működő teszt és éles környezetet... :)

-- 
Üdvözlettel,
Gábriel Ákos