Nagyon örülök, hogy ezt így gondolod.

Azt azért látni kell, hogy ez a konferencia a résztvevők nagy részének azért lehetett ingyenes, mert volt, aki fizesse helyettünk a számlát. Ezért cserébe viszont elvárhatják a jelen levő szponzorok, hogy az ő terméküket reklámozhassák. Ezzel nincs is baj, ezzel szerintem a jelen levők nagy része (velünk együtt) tisztában volt/van.
Manuális tesztelést támogató eszközökből pedig viszonylag kevés van a piacon. Vagy én ismerek keveset.

Viszont ha csavarunk egyet a gondolatmeneten: (majdnem) minden szoftvertesztelés automatizált, ha számítógépet használunk hozzá. Innentől nem manuális, és automatizált tesztelésről kellene beszélni, hanem az automatizáltság fokozatairól. (Nem saját gondolatom, de most nem találom a forrást. Ha meglesz, ideírom.)

@szlj: Nem a reklámmal volt a bajom, azt én is elfogadom. Olyan emberek is mondták ezt, akik nem reklámoztak terméket. Egyébként a menedzsment szoftverek szerintem ilyenek, azok támogatják a manuális tesztelést is.

A gondolatmenethez:
Tőlem kicsit távol áll ez a fajta megközelítés. Szerintem az elektronikus és automatikus fogalmak összemosódnak benne. Mert attól, hogy számítógépet használunk, az még nem biztos, hogy automatikus tesztelés lesz. (semmilyen fokon)
Az automatikus tesztelés egy önműködően futó tesztelést jelent. Amelyet ha elindítunk, az önműködően a bele programozott logikát felhasználva teszteli a rendszert. Míg a manuális tesztelésnél nincs önműködő rész. Nincs programozott logika. Ott a tesztelés logikáját, a tesztelés folyamatát a tesztelő határozza meg.

"Ott a tesztelés logikáját, a tesztelés folyamatát a tesztelő határozza meg. " vagy a teszteset? Ha van, akkor inkább az és a hozzá kapcsolódó dokumentációk (forgatókönyv, teszt modell, stb. igény szerint).

az automatizálást pedig (történelmileg) szerintem azért vették megint elő, mert már egy jó ideje megindult a szoftver fejlesztés abba az irányba, hogy az üzleti logikát egyszerűsítsék, ne legyen bonyolult, inkább sok kis apró - mint egy polipnál - elágazással oldjanak meg mindent. Ha pedig már ilyen jól sikerült ez az egyszerűsítés, akkor az automatizálása sem okozhat problémát.

Persze a gyakorlatban ennek az lett az eredménye, hogy ha már ilyen egyszerűen, bárhová (bármelyik rétegbe) betehetjük az üzleti logikát, mindenki "heggeszt" össze vissza (azaz gyakrabban változik), koordinálni meg senki sem tudja, mivel senkinél nem összpontosul a megfelelő tudás.

Ezekhez az egyszerű alkalmazásokhoz, interfészekhez tényleg sokkal egyszerűbb automatizált szkripteket készíteni, meg azért jók, mert flexibilisek is. A nagy hátrányuk viszont a korábban említett gondolat alapján az, hogy:
- gyakran változik (nem jó az automatizálásnak), ugye ez előny is, mert flexibilis, ez volt a cél :D
- koordinálni nem tudják, azaz a mélyebb összefüggések nem születnek meg, így a tesztelés minősége sérül

Egy kicsit olyan érzés ez, mintha visszautaznánk az időben, de mégis ezek az új trendek, "buta alkalmazások", amik igaz hogy gyorsan készek, de az értékvesztésük iszonyú.

A tesztelés / szoftver minőségbiztosítás pedig nem tud még egyelőre gyógyszert, megoldást ezekre a trendekre. Majdnem az összes módszertan, szabvány, stb. a korábbi szemlélet alapján készült szoftver termékekre adnak útmutatást. Van ezekből is még elég, nem kell megijedni, de azon érdemes lenne elgondolkodni, hogy kell-e nyomni ezt az automatizálást, a költségcsökkentés miatt? :D Az egész olyan, mintha egy elrontott technológia iszonyú magas költségeit a tesztelésen akarnák megint megspórólni. Egyre több helyről hallom megint hogy az agilis módszertanról is lefújták a port, ezek mind mind az új trendeket szolgálják.

Pedig a mindenféle módszertan bevezetés, túlzott automatizálás (bizonyos esetekben/helyen nagyon hasznos!) helyett szembe kellene nézni és felszámolni a káoszt. Ezt a cégek persze nem fogják bevállalni, ezért szórják 2 marékkal a pénzt, 5-ször akkora IT delegációra, meg drágább gépekre, technológiákra, mint amekkorára szükségük lenne. Ha a cégméretet nézem szerintem mindenhol ez a probléma most. Beütött már az új trend.

Mi lehet egy ilyen esetben a minőségbiztosítás feladata? Felkészül az új trendre? vagy Rámutat a hibákra, hiányosságokra? Javasol többféle megoldást? Felkészül a következő hullámra, ahová minden erejéből megpróbálja visszatéríteni az embereket? A mostoha piaci körülmények legalább indokot adhatnának a spórolásra, a nagy pénzt nem a tesztelés - soha nem az - viszi el, hanem az észnélküliség. Ezt kellene beleverni a menedzserek fejébe.

@skywalker lajos: A tesztmódszertan, teszteset, stb... igaz, hogy meghatározza a tesztelést és annak folyamatát, viszont a tesztelő ezt folyamatosan, akár minden percben felülbírálhatja. Hiába van leírva a tesztelés menete, a gyakorlatban ez a legritkább esetben futtatható elejétől a végéig mindenféle kitérő nélkül. Ezért gondolom, hogy a tesztelő határozza meg a tesztelés folyamatát. :)

Az összes többivel, amit írtál teljes mértékben egyetértek.

@p_jano: ez attól függ, hogy mi a felállás. Ha veszek egy szabványt (bármyelyik ide kapcsolódót) meg egy eszerint készített szoftvert, akkor abban a projektben a tesztelőnek nincs is joga felülbírálni ezt. Be lehet építeni Ad-hoc tesztelést, de a végeredmény szempontjából nem szabad, hogy az ad-hoc teszt legyen a releváns.

Persze a gyakorlat más. A gyakorlatban nem nagyon szoktak megvalósulni a standard előírások egy szoftver életciklusra. Ha nem valósul meg, akkor igaz az amit írsz, meg a kissebb projekteknél. Ahol nincs különválasztva a tesztelés és teszt tervezés.

Másképpen: ahol van külön egy senior tesztelő, aki tervez is, meg egy junior, aki futtat ott ez nem igaz nagyon. Ha van egy - bármilyen - tesztelő, akinek a feladata egyszemélyben a tesztelés ott igaz.

Én erre próbáltam korábban reflektálni, de így biztos érthetőbb.