Milyen megszorításai vannak a valós szoftver projektnek, amik a termék minőségére is hatással lehetnek? Mások milyen nehézségekkel néznek szembe a szoftvertesztelési folyamataik kialakításánál? Érdemes-e mérnökként mindig a tökéletes megoldásra törekedni? A válaszokat László Gábortól, az EPAM Quality Architectjétől tudhatod meg július 6-ai webinarunkon.
Sokan rendelkezünk különféle tanúsítványokkal, amik az elméleti ismereteinket bizonyítják szoftvertesztelés terén. Könnyedén rajzolunk tesztelési piramist, értjük a V modellt, tudunk ekvivalencia partíciók alapján teszt eseteket tervezni. Mégis, amikor egy valós projektben veszünk részt, a legritkább esetben találkozunk a tankönyvi világgal. Rendszeres csatákat vívunk a megfelelő tesztlefedettség, vagy a követelmények nyomonkövethetősége érdekében. A tesztelői szerepünkből kicsit kilépve viszont beláthatjuk, hogy az üzlet, vagy akár csapatdinamika szempontjából nem szerencsés, sőt különböző korlátok miatt általában nem is lehetséges az elméletben ideális állapot elérése. Vajon létezik olyan köztes megoldás, amivel szakmai igényességünk nem szenved csorbát, de a kollégáink körében sem leszünk népszerűtlenek?
Az előadásban a következő technológiákról lesz szó:
Neked szól az előadás, ha:
Milyen megszorításai vannak a valós szoftver projektnek, amik a termék minőségére is hatással lehetnek?
Gábor az elmúlt 11 évben a legkülönfélébb szoftverfejlesztési projektben vett részt: a szokásos webes, desktop és mobil alkalmazások mellett okos fűtésvezérléssel, mobilhálózati kapcsolóközponttal, orvosi eszközzel, illetve navigációs térkép előállító infrastruktúrával is volt szerencséje foglalkozni. Elsősorban teszt automatizálás és a tesztelési módszertan megtervezése volt a feladata. Dolgozott a legkülönbözőbb méretű és hozzáállású cégeknél: induló startuptól soktízezer fős nagyvállalatokig, erősen dokumentált folyamatoktól az agilis útkeresésig. Szívesen osztja meg a tapasztalatait másokkal, és igyekszik ő is tanulni mások tapasztalatából.
Milyen megszorításai vannak a valós szoftver projektnek, amik a termék minőségére is hatással lehetnek?
A MndwrkOut órákon való részvételhez egyszeri regisztráció szükséges. Ha már közösségünk tagja vagy, nincs más dolgod, mint csütörtök 18:00-kor csatlakozni az e-mailben megkapott linken.
Gábor az elmúlt 11 évben a legkülönfélébb szoftverfejlesztési projektben vett részt: a szokásos webes, desktop és mobil alkalmazások mellett okos fűtésvezérléssel, mobilhálózati kapcsolóközponttal, orvosi eszközzel, illetve navigációs térkép előállító infrastruktúrával is volt szerencséje foglalkozni. Elsősorban teszt automatizálás és a tesztelési módszertan megtervezése volt a feladata. Dolgozott a legkülönbözőbb méretű és hozzáállású cégeknél: induló startuptól soktízezer fős nagyvállalatokig, erősen dokumentált folyamatoktól az agilis útkeresésig. Szívesen osztja meg a tapasztalatait másokkal, és igyekszik ő is tanulni mások tapasztalatából.
Milyen megszorításai vannak a valós szoftver projektnek, amik a termék minőségére is hatással lehetnek? Mások milyen nehézségekkel néznek szembe a szoftvertesztelési folyamataik kialakításánál? Érdemes-e mérnökként mindig a tökéletes megoldásra törekedni? A válaszokat László Gábortól, az EPAM Quality Architectjétől tudhatod meg július 6-ai webinarunkon.
Sokan rendelkezünk különféle tanúsítványokkal, amik az elméleti ismereteinket bizonyítják szoftvertesztelés terén. Könnyedén rajzolunk tesztelési piramist, értjük a V modellt, tudunk ekvivalencia partíciók alapján teszt eseteket tervezni. Mégis, amikor egy valós projektben veszünk részt, a legritkább esetben találkozunk a tankönyvi világgal. Rendszeres csatákat vívunk a megfelelő tesztlefedettség, vagy a követelmények nyomonkövethetősége érdekében. A tesztelői szerepünkből kicsit kilépve viszont beláthatjuk, hogy az üzlet, vagy akár csapatdinamika szempontjából nem szerencsés, sőt különböző korlátok miatt általában nem is lehetséges az elméletben ideális állapot elérése. Vajon létezik olyan köztes megoldás, amivel szakmai igényességünk nem szenved csorbát, de a kollégáink körében sem leszünk népszerűtlenek?
Az előadásban a következő technológiákról lesz szó:
Neked szól az előadás, ha:
You can watch the video after registration
Az előadást regisztráció után tudod visszanézni
Milyen megszorításai vannak a valós szoftver projektnek, amik a termék minőségére is hatással lehetnek? Mások milyen nehézségekkel néznek szembe a szoftvertesztelési folyamataik kialakításánál? Érdemes-e mérnökként mindig a tökéletes megoldásra törekedni? A válaszokat László Gábortól, az EPAM Quality Architectjétől tudhatod meg július 6-ai webinarunkon.
Sokan rendelkezünk különféle tanúsítványokkal, amik az elméleti ismereteinket bizonyítják szoftvertesztelés terén. Könnyedén rajzolunk tesztelési piramist, értjük a V modellt, tudunk ekvivalencia partíciók alapján teszt eseteket tervezni. Mégis, amikor egy valós projektben veszünk részt, a legritkább esetben találkozunk a tankönyvi világgal. Rendszeres csatákat vívunk a megfelelő tesztlefedettség, vagy a követelmények nyomonkövethetősége érdekében. A tesztelői szerepünkből kicsit kilépve viszont beláthatjuk, hogy az üzlet, vagy akár csapatdinamika szempontjából nem szerencsés, sőt különböző korlátok miatt általában nem is lehetséges az elméletben ideális állapot elérése. Vajon létezik olyan köztes megoldás, amivel szakmai igényességünk nem szenved csorbát, de a kollégáink körében sem leszünk népszerűtlenek?
Az előadásban a következő technológiákról lesz szó:
Neked szól az előadás, ha:
Gábor az elmúlt 11 évben a legkülönfélébb szoftverfejlesztési projektben vett részt: a szokásos webes, desktop és mobil alkalmazások mellett okos fűtésvezérléssel, mobilhálózati kapcsolóközponttal, orvosi eszközzel, illetve navigációs térkép előállító infrastruktúrával is volt szerencséje foglalkozni. Elsősorban teszt automatizálás és a tesztelési módszertan megtervezése volt a feladata. Dolgozott a legkülönbözőbb méretű és hozzáállású cégeknél: induló startuptól soktízezer fős nagyvállalatokig, erősen dokumentált folyamatoktól az agilis útkeresésig. Szívesen osztja meg a tapasztalatait másokkal, és igyekszik ő is tanulni mások tapasztalatából.