[Java lista] Szoftver-tesztelés

2010. Sze. 7., K, 14:29:51 CEST

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... :)
>>> -- 
>>> http://www.javaforum.hu -=- http://www.enaplo.hu
>>> Auth Gábor -=- http://www.javaforum.hu/web/10/authgabor
>>> _______________________________________________
>>> Javalist mailing list
>>> Javalist at javagrund.hu
>>> http://javagrund.hu/mailman/listinfo/javalist
>> 
>> _______________________________________________
>> Javalist mailing list
>> Javalist at javagrund.hu
>> http://javagrund.hu/mailman/listinfo/javalist
> 
> 
> -- 
> Üdvözlettel,
> Gábriel Ákos
> 
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist

--------- következő rész ---------
Egy nem text típusú csatolt állomány át lett konvertálva...
Név: smime.p7s
Típus: application/pkcs7-signature
Méret: 3792 bytes
Leírás: nem elérhető
Url : http://javagrund.hu/pipermail/javalist/attachments/20100907/97de23df/attachment.bin 