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…
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.
Egy örök probléma: túl sok tesztet kell elvégezni, és nincs rá elég idő.
Korábban már írtam erről a témáról: „What to Test When There’s Not Enough Time to Test” , ebben arról volt szó, hogyan lehet a tesztelési feladatokat rangsorolni,
hogyan kell a csapattal együtt dolgozni úgy, hogy ne kerüljünk időhiányba a tesztelési feladatokkal kapcsolatban.
De most szeretném általánosságban áttekinteni az időgazdálkodást: hogyan lehet felépíteni a napjainkat, hogy ne érezzük magunkat folyamatos nyomás alatt a sok munka miatt?
A digitális termékekkel kapcsolatos felhasználói visszajelzések nagyon fájóak is lehetnek a cég – különösen a fejlesztő csapat – számára. Az okostelefonok és a mobil alkalmazások megjelenésével megnövekedtek a felhasználóknak a termékkel kapcsolatos általános és minőségi elvárásai.
Tesztelés élesben (testing in production) – avagy hogyan tegyük a tesztelési folyamatunkat sokkal hatékonyabbá anélkül, hogy felesleges kockázatot vállalnánk Ha azt halljuk, hogy valaki élesben…
Mi ölheti meg a tesztelést? Habár Rómát nem 1 nap alatt építették, 64-ben 6 nap alatt mégis leégett, majd egy kicsit tűzállóbban újraépült. Amikor a…
Hogyan fejlődik a szoftvertesztelés szerepe A szoftvertesztelés tűnhet dögunalmasnak, de akár szexinek is, ahol a tesztelő a felhasználói élmények úttörőjévé válhat. Képzeld el az alábbi…