În general, atunci când ne gândim la un sistem digital, primul lucru care ne atrage atenția este viteza sau puterea sa de calcul. Abia după ce lămurim partea aceasta despre tipul de procesor, despre numărul de core-uri și frecvența de lucru, apar întrebările adiționale printre care cea dintâi ar fi despre memorie. Ce capacitate are memoria, de ce tip este și eventual alte aspecte legate de câte canale, modul de accesare, viteza de lucru ș.a.m.d. Însă este un lucru bine știut că nu ne punem neapărat, problema calității memoriei și a caracteristicilor date de producător în ceea ce privește retenția datelor, comportamentul în diverse condiții (ex. cu temperatura, variația tensiunii, …) și a fiabilității acesteia. Cu atât mai puțin încercăm să căutăm informații adiționale care să fie relevante în acest sens și care să ajute la o decizie în alegerea acesteia.

Waterfall, Agile, Test Driven Development (TDD), Behavior Driven Development (DBB), Rapid Application Development (RAD), Spiral Model, Feature Driven Development (FDD), Rational Unified Process (RUP), sunt doar câteva dintre cele mai cunoscute modele de dezvoltare a aplicațiilor software care au apărut ca răspuns la nevoia de a reduce timpul de livrare a software-ului către clienții finali, adică amortizarea investiției și obținerea unui profit mai rapid. Unul dintre efectele produse de evoluția modelelor de dezvoltare este declinul specificațiilor scrise în mod tradițional și definirea lor într-o formă simplificată. În acest context, se impune cu necesitate apariția unui nou concept de specificații care să satureze deplin această nevoie.

Publicat în Numărul 64 Citeşte mai mult

Suntem într-o continuă inovare și schimbare în domeniul auto. Dacă până acum zece ani un ciclu complet de testare pentru un produs software în industria auto dura în medie undeva la doi ani de zile, acum timpii sunt reduși considerabil datorită pieței într-o continuă extindere și concurenței tot mai acerbe. Suntem în situația în care aveam tot mai multe echipamente electronice în mașină, autonomia auto este din ce în ce mai mare și timpii de dezvoltare și testare sunt tot mai reduși. În aceste condiții, ne punem problema cum ne alegem oamenii, cum selectăm testerii? Cum ne asigurăm că ne vor livra produse de cea mai înalta calitate?

Publicat în Numărul 62 Citeşte mai mult

Când am început primul nostru proiect, am căutat un tool ușor de folosit care ne-ar fi putut ajuta să scriem teste lizibile și concise. Ne-am hotărât să folosim Spock, pentru că în combinație cu Groovy ne dă exact ce avem nevoie: teste lizibile de tip BDD pe care le putem scrie și schimba rapid. Spock poate fi folosit și în combinație cu Java, dar are sinergie foarte bună cu Groovy. Toate exemplele din articol sunt scrise în Groovy, dar e suficientă puțină experiență cu Java pentru a le înțelege. Deoarece exemplele de teste din proiectul nostru sunt prea complicate pentru o introducere în Spock, am ales exemple de cod dintr-un kata pe care l-am făcut pentru a exersa TDD.

Preocuparea tot mai frecventă a marilor companii de a face accesibile paginile lor web pentru cât mai mulți utilizatori, ne îndreaptă pașii către o categorie de utilizatori cu nevoi speciale. Oricare ar fi gradul de deficiență, permanentă sau temporară, proprietarii de website-uri își doresc ca informația livrată să fie accesibilă și acestora. Astfel, o direcție în cadrul testării se orientează spre acest tip de utilizatori cu diferite deficiențe. Există o inițiativă internațională prin care se încearcă a se stabili un set de bune practici și recomandări, numită W.A.I. (Web Accessibility Initiative), lansată de W3C (World Wide Web Consortium).

Publicat în Numărul 59 Citeşte mai mult

În acest articol se va face o trecere în revistă a elementelor cheie specifice MAF – API dezvoltat intern în Telenav pentru testare automată folosind Appium. Acesta din urmă oferă posibilitatea rulării aceluiași set de teste simultan pe mai multe dispozitive iOS, respectiv Android. Se vor analiza câteva aspecte generice legate de serviciul de automatizare Appium și se va realiza un tutorial despre instalarea și configurarea API-ului.

Toolurile de testare automată din ziua de azi oferă o alternativă la metodele de testare manuală, deoarece testele sunt executate rapid și în mod repetat. Mai mult, rezultatele testelor pot fi comparate automat cu rezultatele comportamentului așteptat, iar diferenţele pot fi astfel evidenţiate. Testarea automată presupune un efort iniţial. Beneficiile viitoare sunt semnificative deoarece se traduc în stabilitate mărită. CasperJS este un tool util pentru testarea automată a aplicaţiilor web, fiind foarte ușor și rapid de instalat. În contextul actual, livrarea rapidă pe piaţă este crucială, iar erorile și bugurile nu sunt foarte tolerate. Prin urmare, este important să se livreze produse de calitate. Deoarece asigurarea calităţii nu este un obiectiv principal din cauza unor constrângeri precum timpul, costul, resursele, acest aspect este doar parţial acoperit în munca efectivă. Consecinţa imediată este o experienţă negativă a utilizatorului.

Publicat în Numărul 57 Citeşte mai mult

Ne poate interesa la un moment dat cât de bine sunt proiectate testele automate ce validează funcţionalitatea Serviciilor Web. Poate vrem să vedem cât de mult este exersat codul prin testele automate. O variantă de testare funcţională a Serviciilor Web este aplicația SOAP UI. Acest articol prezintă cum se poate integra aplicaţia Squish Coco pentru a determina cât de mult exersează codul C# testele automate dezvoltate utilizând SOAP UI.

Într-un context DevOps, testarea a evoluat și va continua să evolueze trecând de la un rol făcut de o singură persoană la taskuri de testare făcute de toată lumea din echipă. Motivul pentru o astfel de schimbare este dat chiar de scopul principal al unei echipe DevOps , care este acela de a găsi cea mai rapidă cale de la o idee către lansarea acesteia în producție. În acest context, pentru a avea un produs de calitate și cu cât mai puține defecte, gata de lansare în orice moment, trebuie ca toată lumea să includă testarea (în diverse forme) în responsabilitățile de zi cu zi. Pe scurt, toată lumea trebuie să facă testare într-un astfel de mediu. Aceasta este prima transformare a testării. Într-un astfel de mediu de tip “Continuous Everything” singurul mod de a obține un astfel de proces este prin dezvoltarea testării automate pe toate nivelele produsului (de la unit testing la acceptanță). Testarea automată presupune cunoștințe tehnice cel puțin medii (programare, arhitectură, baze de date, etc.) și, prin acoperirea tot mai mare și preluarea unor taskuri de la tester, deschide calea acestuia de a se orienta spre o înțelegere mai bună a utilizatorului sau grupului țintă căruia îi este adresat produsul dezvoltat.

Știm deja că milioane de oameni din întreaga lumea folosesc telefoane mobile și tablete, iar numărul utilizatorilor este într-o creștere continuă, ceea ce determină și o creștere exponențială în piata aplicatiilor mobile. Companiile dezvoltatoare de aplicatii mobile trebuie să se asigure că produsele livrate sunt de bună calitate și se diferențiază, pentru a avea un feedback cat mai bun din partea utilizatorilor. Acest lucru devine o provocare, având în vedere diversitatea tipurilor de device-uri mobile și a sistemelor de operare. Pentru a asigura o acoperire cât mai largă și eficientă, testarea acestor aplicații trebuie automatizată. De aceea este nevoie de o soluție cât mai generică și care să acopere cât de mult posibil testarea aplicației.

Publicat în Numărul 57 Citeşte mai mult