Vitatkozhatunk a ténnyel, hogy Androidra fejleszteni szívás. Erre pro és kontra is érvek sora áll rendelkezésre, ám általában ezek amolyan etimológiai-szemantikai viták, hogy tudniillik mi a szívás: az, hogy bonyolult (tény, de erről mindjárt), vagy az, hogy ha nem készülsz rá előre (mondjuk mert úgy gondolod hogy “majd az emulátorban megtesztelem oszt’ jóság van”), akkor tényleg csúnya negatív élménybe fordulhat, amiről aztán később csak egy kesztyűsbáb segítségével fogsz tudni beszélni egy kanapén fekve.
Nos, Emich Szabolcs, az Arkon CTO-ja testközelben tapasztalta a problémát, ám ő nem állt meg ott, hogy rinyablogba illő bejegyzést írjon róla (nb.: nem is írt), hanem gondolkozott és kitalált egy lehetséges megoldást, ami a Testrrr munkacímet kapta.
Mi is tehát ez a Testrrr?
Mielőtt belecsapunk (pedig micsoda cliffhanger volt!), térjünk vissza kicsit az “az Android tesztelés bonyolult” megállapításra. Az Android tesztelés bonyolult, mert rengeteg és rengetegféle Android eszköz van. És bár van egy emulátor, ami a stock Androidot képes sok konfigurációban és felbontással emulálni, még ez sem minden: egy fejlesztőnek készülnie kell a különféle gyártók által kókányolt “custom ui” intézményére, ami alatt kiterjesztve azt értem, hogy simán belenyúlnak az Android alaprendszer működésébe is több-kevesebb sikerrel. (És erre persze minden joguk megvan: ettől jó az Android.) Nem is olyan rég részt az általam (is) szakértett projekt QR olvasókat tesztelt: érdekes volt, hogy a laboratóriumi tesztben szerepelt egy iPhone, egy Nokia telefon (csak hogy egy halott platformon is megnézzük a működést), és vagy 6 Androidos telefon – és ez csak a képernyőméret-felbontás-technológia kombók alapján! Nem nehéz elgondolni, hogy ha jól (úgy értem: jól) le akarszt tesztelni egy Android appot, ami nem csak egy WebView ablakból áll, bizony jó sok mindent kell kombinálgatnod: architekrúra/processzortípus, képernyőméret/technológia, van-e ilyen-olyan szenzor vagy nincs, lowend-highend, és így tovább. Egy kis fejlesztőcégnek (ami adott esetben egy darab lelkes fejlesztőt jelent) pedig 6-8-10 készüléket fenntartani nyilván nem opció. Marad a kevés eszközön minél jobban tesztelés, és a gyors hibajavítás, amit persze én erényként tartok számon.
És a közösség.
Az Android mögött-körül ugyanis sokkal reszponzívabb közösség van, mint más platformok körül, szívesen válaszolnak, szívesen segítenek. A régi GNU/Linux szcéna jut eszembe, ahol a fejlesztőt szívesen segítik trollkodás helyett a felhasználók. Nem szervezett formában most is rengeteg olyan tesztelés zajlik, ahol a fejlesztő informálisan outsource-olja a tesztelést a lelkes jelentkezőknek.
Szabolcs ötlete ezt vinné tovább, és adna neki keretet:
hozzunk létre egy olyan közösséget, valamint egy közösségi rendszert, ahol Android (később más platformok is) fejlesztők kérhetik mobil alkalmazásuk tesztelését. Ugyanitt lelkes mobil felhasználók jelentkezhetnek mobil app tesztelőnek. A fejlesztők különféle előnyöket, ajándékokat nyújthatnak a tesztelőknek, a tesztelők pedig a sokféle eszközükkel és rendszerükkel manuális és automatikus visszajelzéseket küldenének a tesztelt alkalmazásokról.
…vagyis a crowdsourcing. Mindehhez (ha már közösség) segítőket keres, akikkel első körben fel lehet építeni a keretrendszert ehhez (tehát még nem a tesztelőket várják): jelentkezz, ha szívesen részese lennél az elejétől ennek a sztorinak! Egyrészt Szabolcs a saját emailjén is (“sz kukac bolcs pont hu”) várja a vállalkozó szellemű droidokat, másrészt hogy legyen hol beszélgetni, létrehoztam egy Testrrr fórumtémát a kezdeményezésnek.
Kezdődjön hát a Testrrr közösségi szakasza, és remélem, hogy fél év múlva már a sikeres indulásról tudunk beszámolni!
