Szoftvertesztelés konferencia – második nap

A második nap is hallattam jó néhány érdekes dolgot:

Teszt estek dokumentálása

Előadó: Veress zoltán (AEGON, operatív informatikai vezető)

Jó előadás volt, jó meglátásai, személyes tapasztalatai voltak az előadónak.

  • az üzlet, az igények oldaláról közelíti meg a tesztelés témáját
  • AEGON főleg külső fejlesztőket foglalkozatat. Nincs dedikált belső tesztelő se, csak olyan, akinek a tesztelés is munkája
  • Kockázat + hiba bekövetkezése alapján határozzák meg, hogy mire mennyi teszteset kell, üzleti hatást és bekövetkezés valószínűségét kell figyelembe venni.
  • tapasztalat: projekt indulásakor nincs minden letesztelve -> tesztesetek kitalálásakor súlyozni kell őket
  • Az üzlet számára a tesztelés szükséges rossz, ami csak lassítja a piacra jutást -> már a projekt elején győzködni kell őket, hogy miért fontos a tesztelés.
  • A fontos háttér fejlesztéseket valami divatos dologgal együtt könnyebb elfogadtatni:), pl. ok, vezessünk be mi is CRM-et, de ehhez előbb a háttérrendszereket rendbe kell rakni
  • legalább 3 környezet van: fejlesztői, teszt, éles. A teszt ugyanolyan rendszer, ugyanolyan platform, az eredeti adatbázist rakják át a személyes adatok kiszedése után.

Két nagyon fontos meglátása volt, amit mejegyeztem magamnak:

  • Akkor érdemes bevezetni valami támogató eszközt, ha anélkül is megy a folyamat rendesen. Ha nincs meg a tesztelési kúltúra, üzleti folyamatnak nem bevett része, akkor az eszköz nem segít semmit. Ha nincs cél eszköz bevezetve, akkor is legyen világos folyamat, legyenek sablonok, legyen központi tárhely, legyen kitől kérdezni.
  • A tesztelés a projekt költségének kb. 30%-a, ezt nem lehet megspórolni, csak hatékonyan elkölteni (alaposabb tesztelés, jobb minőség).
  • A hatékony szervezeti felépítés alapvetései

    Előadó: Privitzky Gábor, Qualysoft

    • A tesztelés és a szoftverminőség nem ugyanaz, minőség bővebb fogalom
    • Fontos: legyen a tesztelők előtt pozitív cél is, ne csak az, hogy 50 hibát találjanak
    • Az ügyfél, bár hadakozik, de inkább elviseli egy funkció hiányát, mint egy teljes funkciójú, de rossz minőségű rendszert
    • Tesztelők típusa: gyakorlatias, úttörő, elemző, vezető -> mindegyikből kell
    • Az a tapasztalat, hogy nehezebb jó tesztelőt találni, mint jó fejlesztőt
    • A tesztelő az a csapatből, aki tudja, hogy milyen készültségi fokon van az alkalmazás, a fejlesztő mindig azt mondja, hogy 80%-on van kész
    • Felmérés: 1996-ban a fejlesztési projektek 6-7%-ban használtak tesztelési eszközöket. 2006-ban ez az arány szintén 6-7% frown

    Az előzőhöz kapcsolódóan itt is elhangzott egy fontos dolog: az időnyomásból nem eszközökkel, hanem módszertannal lehet kitörni.

    IT és üzlet kapcsolata

    Előadó: Simon György, Magyar Telekom

    • Teszt környezetek: szállítói, User Acceptance Test, integrációs (meglévő rendszerekkel hogyan működik együtt)
    • Üzlet bevonása minél hamarabb a tesztelésbe: érezzék, hogy fontos a véleményük, már megnézik a félkész rendszert, beleszólnak, hogy milyen legyen, és így később a sajátjuknak is érzik, kevésbé kritukusak vele szemben. Viszont nem szabad a ló túlsó oldalára átesni, a teljes tesztelést ráhagyni az üzleti oldalra, mert előbb-utóbb beleunnak.
    • ütemezett shipment: évente előre betervezett időpontok, és így az üzlet is tudja ütemezni a saját dolgait.
    • ha az éles rendszerben sok a hiba: utólagos költség elemzés: hiba kijavításának költsége + okozott kiesés -> legközelebb ezt fel lehet használni, ha a tesztelést akarják rövidíteni.

    A többi előadásban is volt még érdekes dolog, de ott inkább egy-egy diakocka vagy ábra volt ami hasznos. Egyébként a konferencia maga elég vegyes volt, volt aki nagyon alap dolgokat mondott el, sokan általánosságokat ismételtek, de mondjuk tényleg nehéz belőni a szintet, hisz ez az első ilyen rendezvény volt. Szerintem azok voltak hasznosak, amikor saját tapasztalatot meséltek el, mi az ami működik és mi az ami nem, vagy konkrét számokat, pl. hogy mennyi teszt készül a rendszerhez, mennyi idő lefuttatni, mennyi hibát szoktak találni, stb. (mondjuk az ilyen konkrét számokból azért kevés volt:) Az ilyesmi az, amit tényleg nem lehet könyvből megtanulni, csak úgy, ha évekig tesztel az ember.

    Advertisements
    Kategória: Research | Közvetlen link a könyvjelzőhöz.

    Vélemény, hozzászólás?

    Adatok megadása vagy bejelentkezés valamelyik ikonnal:

    WordPress.com Logo

    Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

    Twitter kép

    Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

    Facebook kép

    Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

    Google+ kép

    Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

    Kapcsolódás: %s