Concluzia articolului anterior "Testare continuă = Testare automată++" este că în prezent, nu există un instrument sau o tehnologie care să ofere instantaneu testarea continuă. Dar există, din fericire, tooluri care oferă sprijin puternic pentru testarea continuă. Pentru prezentarea acestor instrumente actuale de testare continuă, am folosit raportul Gartner “Critical Capabilities for Software Test Automation”. Acesta se concentrează pe instrumente de automatizare a testelor software care pot rula teste funcționale automate, interacționând cu aplicația printr-o interfață de programare a aplicației (API) sau controlând interfața de utilizator a aplicației (UI).

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

Testarea continuă este o sintagmă din ce în ce mai utilizată. Dar oare câți dintre noi știm la ce se referă? Multă lume tinde să o confunde cu testarea automată sau să o considere doar un termen mai evoluat pentru același lucru. Testarea continuă și testarea automată sunt diferite; dacă veți înțelege diferențele veți fi pregătiți pentru a asigura calitatea aplicațiilor într-o epocă în care testarea tradițională pare să devină irelevantă. Veți fi, de asemenea, pregătiți să faceți trecerea de la rolul reactiv al testării pentru validarea cerințelor la un rol mai proactiv de „inginerie a calității”, axat pe protejarea și optimizarea afacerii.

Un ecosistem de unelte de testare pentru succesul unui proiect. Vom discuta despre unelte de testare care pot folosite în piramida de testare. Unele dintre acestea oferă posibilitatea de a fi folosite pentru mai multe activităţi de testare, altele sunt specifice doar uneia.

Fie că am avut oportunitatea să facem sau doar am participat la implementarea unui test plan, cu toții contribuim la execuția acestuia. Un test plan descrie scopul și împarte în faze efortul care urmează să fie depus în vederea testării unui produs. De asemenea, cuprinde informații legate de mediul de testare, priorități, planificări legate de durată și perioada de testare. Totodată, include strategia de testare, test case-uri dar și posibile riscuri, persoane implicate etc.

La UiPath dezvoltăm platforma numărul 1 de Robotic Process Automation (RPA), platformă utilizată în prezent de mii de companii din toată lumea pentru a-și automatiza procesele. În mod natural, suntem primii utilizatori ai acesteia. “Roboții” noștri software rulează procese de HR, de achiziții sau care țin de departamentul juridic, ajutându-i pe colegii noștri să se poată concentra pe activitățile cu valoare adăugată mai mare. Totuși, nu numai colegii din aceste departamente beneficiază de serviciile roboților noștri software, ci chiar și echipele de dezvoltare utilizează platforma pentru procesul de software development – orientat către partea de testare. Acest articol dorește să vă arate unul din modurile în care noi ne testăm munca cu propriul produs.

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

Pentru a consolida resursele QA, bunele practici și instrumentele de automatizare disparate în cadrul unei afaceri, dar și pentru a optimiza performanţa de testare, multe companii recurg la Testing Centers of Excellence (TCoEs). În același timp, un TCoE nu este un panaceu pentru fiecare companie, deoarece instalarea sa necesită mult efort de organizare, iar rezultatele performanţelor TCoE pot să nu fie pe măsura acestui efort.

BDD sau behaviour-driven development (dezvoltare bazată pe comportament), este o metodă de dezvoltare software bazată pe TDD (test-driven development sau dezvoltare bazată pe testare). Se concentrează în principal pe gestionarea procesului de dezvoltare software atât din perspectiva business cât și cea tehnică. BDD încearcă să elimine ceea ce se numește „costul traducerii” - ceea ce spune partea de business și ceea ce înțelege persoana tehnică. Cu BDD, acest lucru ar trebui să fie mult mai clar. BDD este implementat printr-un DSL (domain-specific language) simplu, folosind propoziții clare și concise în limba engleză care exprimă comportamentul și rezultatul așteptat. Inițiatorul BDD este Dan North în 2006.

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

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