Era vineri, la câteva ore după release-ul în producție și cu câteva ore înainte de a se crea noul branch de release.. Toată echipa era deja obosită, am avut câteva luni pline din punct de vedere al funcționalităților lansate, release în producție săptămânal și o echipă de product care avea deja pe rol alte câteva feature-uri noi. Îmi scot căștile din urechi deoarece văd agitație în jurul meu. Cei doi colegi de ai mei își bat capul cu un defect pe care l-au găsit și vin către mine pentru sfaturi. A treia mea întrebare: se întâmplă și pe producție? Se uită unul la celălalt, își întorc scaunele rotative fiecare spre biroul lui, iar după un minut, am răspunsul: da. Colega mea se panichează în timp ce realizează că ea a dat QA sign off la release. Eu sunt calmă, nu e prima dată când văd aceasta întâmplându-se, și da, mi s-a întâmplat și mie.

În lumea managementului defectelor, cel mai bine documentat defect este defectul care nu există. Prevenția este mai bună decât orice tratament. Numai că înainte de a ajunge la produse, echipe și procese de lucru perfecte, trebuie să ne gândim cum să tratăm defectele.

Un atac cibernetic de tip phishing (cuvânt omofon cu englezescul “fishing” datorită faptului că presupune folosirea unei “momele” pentru a prinde în plasă victimele) presupune furtul de informații confidențiale precum datele cardului bancar, username-ul sau parola unui utilizator. Acest furt se realizează prin deghizarea atacatorului într-o entitate în care utilizatorul are încredere – o bancă, o persoană cunoscută sau departamentul de IT al companiei la care utilizatorul lucrează – și căreia utilizatorul este inclinat să îi comunice de bunăvoie, acest tip de informații.

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

General vorbind, QA (asigurarea calităţii) apare în peisaj după ce dezvoltarea este finalizată. Apoi, echipa QA testează funcţionalităţile implementate și găsește defecte la nivelul aplicaţiei. Astfel crește calitatea aplicaţiei dezvoltate. Este oare aceasta cea mai bună abordare? Reduce aceasta costurile? Răspunsul este „Nu”. Atunci care ar fi metodele și procesele de urmat prin care un QA aduce cea mai bună calitate?

Să validezi un sistem software nu e o muncă ușoară, deși privind din afară, mulți ar zice că e o joacă. Haideți să ne gândim că suntem testeri pentru o zi. Ce avem de făcut? Primul pas: definim test case-urile, apoi scriem testele, automate sau nu, pregătim infrastructura, iar în final începe ”joaca”. Pentru a salva din timpul alocat testării automate, ne-am gândit să folosim containere Docker ca targeturi. Astfel, testerii nu vor mai fi nevoiți să își bată capul și cu environmentul.

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

Industria automotive evoluează într-un ritm accelerat. De aceea, pentru a depăși așteptările, trebuie să fiți cu un pas în față. Bosch are o vastă experiență în combinarea tehnologiei vehiculelor cu tehnologia hardware, software, precum și cu o diversitate de servicii pentru a oferi soluții complete pentru mobilitate. Nu avem încă mașini care să zboare, dar avem o sondă care face acest lucru.

Dacă sunteți interesați de testarea automată sau începători în acest domeniu, atunci acest articol vă va ajuta foarte mult, informându-vă despre instrumentul numit Cucumber, care este ușor de învățat și de înțeles. Odată lămurite caracteristicile acestuia, le vom integra într-un framework de testare automată folosind TestNG, Selenium și Maven. Codul sursă al acestui proiect poate fi descărcat de pe Git. Frameworkul este construit pentru a rula cu succes atât pe sistemul de operare MAC OSX, cât și pe Windows.

Poate că unii dintre voi vă întrebați de ce am ales acest titlu. Răspunsul scurt este că nu sunt prea mulți testeri care să-și dorească să învețe programare, deși aceștia ar prefera testarea automată în locul celei manuale. Dar am o veste bună! Cu toate că pare dificil la început, testarea automată fără programare este posibilă, iar acest lucru se poate realiza utilizând testarea bazată pe modele, în care testerul creează modele pentru controalele pe care dorește să le utilizeze. De exemplu, într-o aplicație web, un model pentru teste și un model pentru date. Prin urmare, ca expert în testarea bazată pe modele, la NTT Data Romania, doresc să vă împărtășesc din experiența mea.

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

Sunt tester din 2004. Am avut multe roluri în 13 ani, dar m-am considerat mereu un tester. M-am bucurat când am găsit buguri care frizau niște situaţii/context aproape imposbil de conceput. M-am simtit prost când mi-a scăpat ceva ce a făcut produsul dificil sau imposibil de utilizat în producţie. M-am ascuns în proiectele mele și în firma mea, considerând că sunt un tester bun. M-am aflat pe scenă în faţa a sute de oameni, așteptând acea întrebare care să mă facă să realizez ce stupide au fost presupunerile mele.
Am întâlnit multe concepţii greșite despre testarea software. Cu unele veţi fi de accord, cu altele nu, dar consider că arta de a testa ține de împărtășirea ideilor și a experienţelor, acesta fiind chiar lucrul pe care intenţionez să îl fac. Iată-le:

De multe ori aud în producţie următoarele întrebări:
- de ce trebuie să îngreunăm procesarea echipamentelor utilizate în zonele de producţie?
- de ce operatorul care face o anumită operaţie trebuie să ştie să utilizeze calculatorul?
- de ce munca lui nu se rezumă doar la aşezarea piesei de procesat într-o locaţie specializată, la preluarea ei şi trimiterea mai departe la următorul post de lucru?