Hogyan légy sikeres tesztelő, ha a csapatod DevOps-ra áll át Szerencsésnek mondhatom magam, hogy a hosszú karrierem alatt mindig olyan cégeknél dolgoztam, ahol szabadon kommunikálhattam és…
Az éjszakai buildelés előnyei Milyen egy éjszakai build? Az éjszakai build kifejezést gyakran használják nagy projekteknél. Olyan projektekre gondolok, ahol az elkészült termék teljes rebuildelése…
Létezhet tesztautomatizálás agilis környezetben? Mára már az agilitás szó annyira divatossá vált, hogy az emberek nem tudnak nélküle élni. A z az érdekes, hogy szinte…
Puppeteer – A webes tesztautomatizálás bábjátékosa Bevezető Fontos még indulás előtt megjegyezni, hogy mivel Node alapú modulokról lesz szó, így egy alapvető javascript tudást megkövetel a mélyebb szintű megértés, de mint azt látni fogjuk, azoknak sem kell kétségbe esniük, akik teljesen kezdők a kódolás terén, hisz egy teszt lépésinek leírása igazán intuitív. Ebben a cikkben igyekszem a legjobb tudásom szerint egy kis ízelítőt adni ebből…
A „kevesebb” néha több, Szerver nélküli architektúra Emlékszel, amikor pár évvel ezelőtt, amikor a cloud technológia először napvilágot látott és volt egy gyakran elhangzó mondat:…
“Shifting Right” a tesztelésben A Cloud telepítés lehetővé tette és szükségessé is tette a folyamatos tesztelés és monitorozást az élesben futó rendszereknél. Míg a Cloud ugyan globális elérhetőséget…
Az élet minden területén találkozunk problémákkal, melyeknek gyakran a mélyére kell ásni, hogy megtaláljuk a valódi okokat. A miértek megismerése, rendszerezése, kapcsolataik és kockázataik felfedése kulcsfontosságú a hiba hatékony megszüntetésében. Összetettebb problémák kibogozása és alapos körüljárása sokszor nem egyszerű. Különösen igaz ez az informatikában, ahol egy-egy hibás eredmény mögött kódsorok ezrei állhatnak, kapcsolódó rendszereken, egymásra ható gépeken át jutunk el a „De miért nem működik?”, „Nem ezt kellene csinálnia!”, „Mégis mitől fagytál le már megint?” felkiáltásokig. Az eredményes kiváltó ok kereséshez nyújtanak segítséget felsorolt módszerek.
Nem is túl régen, amikor valaki azt mondta, hogy egy globális szoftverfejlesztő csapat tagja, az azt jelentette, hogy az IBM-nél, az SAP-nál vagy a 100 legszerencsésebb vállalat valamelyikénél dolgozik, amelynek világszerte vannak fejlesztő központjai.
Manapság még a tíznél kevesebb alkalmazottat foglalkoztató cégek is kettő, öt vagy annál is több helyszínen lévő csapatokkal dolgoznak. A csapattagok földrajzi elhelyezkedése véletlenszerű tulajdonsággá vált, amelyet gyakran figyelmen kívül hagytak vagy egyáltalán nem vettek figyelembe.
A tesztelés minőségét korlátozza a tesztelhetőség. Függetlenül attól, hogy ez a rendszer műszaki megértésére, a csapaton belüli kapcsolatokra vagy a rendszer megfigyelhetőségére vonatkozik.
Hiszem, hogy a tesztelés jövője attól függ, hogyan támogatjuk a tesztelhető rendszerek megvalósítását. Itt az idő, hogy mindenki vállalja a felelősséget a tesztelhetőségért.
Amikor azt mondom, hogy mindenki felelős valamiért, akkor azt is jelenti, hogy ennek mindig ugyanonnan kell kiindulnia. Tőled.
A „Build automatizálás” fogalma általánosságban sok mindent takarhat, ami segít nekünk abban, hogy szkripteket használjunk és automatizáljuk azokat az ismétlődő feladatokat, amelyek a szoftver termék „összeállításához” szükségesek – összegyűjtünk közben minden eszközt, amit figyelembe kell venni, automatizálunk minden feladatot, hogy lefordítsuk (compile), összeállítsuk (build), teszteljük, és csomagoljuk (package) a forrás kódot, és hogy automatizálhassuk az élesítését (deployment) a különböző környezetekben. Fejlesztőként ezzel megkönnyíthetjük az életünket, és lehetővé válik, hogy fontosabb fejlesztési és hibakeresési feladatokra tudjunk összpontosítani.