Category: Notiuni IT

Implementarea Setup și Teardown în testele Selenium cu TestNG și Java

Atunci când dezvoltăm teste automate pentru aplicații web cu Selenium și Java, este important să avem un mediu bine configurat pentru a asigura că testele rulează corect și eficient. O abordare comună în acest sens este utilizarea setup și teardown, oferite de framework-ul TestNG. În acest articol, vom explora cum să implementăm setup și teardown în teste Selenium folosind Java și TestNG.

Setarea mediului cu Setup

Metoda @BeforeClass din TestNG este utilizată pentru a executa cod înaintea primului test dintr-o clasă de teste. Această metodă este ideală pentru operațiile de setup care trebuie realizate o singură dată pentru întregul set de teste.

import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;

public class SeleniumTest {

    @BeforeClass
    public void setup() {
        // Configurare WebDriver, deschidere browser, etc.
        System.out.println("Setup pentru testele Selenium");
    }

    @Test
    public void test1() {
        // Test 1
        System.out.println("Execută Test 1");
    }
}

În exemplul de mai sus, metoda setup() va fi apelată înaintea execuției oricărui test din clasă. Aici poți configura WebDriver-ul, deschide browser-ul sau executa orice alte operațiuni de setup necesare.

Cleanup cu Teardown

Metoda @AfterClass din TestNG este utilizată pentru a executa cod după ce toate testele dintr-o clasă au fost rulate. Aceasta este o oportunitate ideală pentru operațiunile de cleanup sau pentru închiderea resurselor deschise în timpul setup-ului.

import org.testng.annotations.AfterClass;
import org.testng.annotations.Test;

public class SeleniumTest {

    @BeforeClass
    public void setup() {
        // Configurare WebDriver, deschidere browser, etc.
        System.out.println("Setup pentru testele Selenium");
    }

    @Test
    public void test1() {
        // Test 1
        System.out.println("Execută Test 1");
    }

    @Test
    public void test2() {
        // Test 2
        System.out.println("Execută Test 2");
    }

    @AfterClass
    public void teardown() {
        // Închidere browser, eliberare resurse, etc.
        System.out.println("Teardown după testele Selenium");
    }
}

Metoda teardown() este apelată după ce toate testele din clasă au fost rulate, oferind un loc potrivit pentru operațiuni de curățare și eliberare a resurselor.

O practică recomandată în dezvoltarea de teste automate este organizarea metodelor de setup și teardown într-o clasă separată, numită adesea TestBase sau BaseTest. Această clasă servește drept punct central pentru toate operațiunile de configurare și curățare și este extinsă de către clasele de teste specifice.

Avantaje ale utilizării unei Clase de Bază (BaseTest):

  1. Reutilizare a Codului: Prin plasarea metodelor de setup și teardown într-o clasă separată, poți reutiliza aceste metode în toate clasele de teste care extind această clasă de bază. Acest lucru conduce la un cod mai curat și mai ușor de întreținut.
  2. Consistență: Toate clasele de teste care extind BaseTest vor beneficia de aceeași configurare și curățare, asigurând consistența întregii suită de teste.
  3. Flexibilitate: Prin intermediul clasei de bază, poți adăuga și gestiona cu ușurință alte funcționalități globale necesare pentru testele tale, cum ar fi gestionarea datelor de test, logging-ul, sau interacțiunea cu servicii externe.

Iată un exemplu simplu pentru o clasă de bază (BaseTest) care conține metodele de setup și teardown:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterClass;
import org.testng.annotations.BeforeClass;

public class BaseTest {
    protected WebDriver driver;

    @BeforeClass
    public void setup() {
        System.setProperty("webdriver.chrome.driver", "C:\\path\\to\\chromedriver.exe");
        driver = new ChromeDriver();
        driver.manage().window().maximize();
        // Alte operațiuni de configurare
    }

    @AfterClass
    public void teardown() {
        if (driver != null) {
            driver.quit();
        }
        // Alte operațiuni de curățare
    }
}

O dată ce ai definit clasa de bază, poți extinde această clasă în toate clasele tale de teste specifice, precum SeleniumTest:

import org.testng.annotations.Test;

public class SeleniumTest extends BaseTest {

    @Test
    public void test1() {
        // Test specific
        // Nu este nevoie să configurezi WebDriver-ul sau să gestionezi cleanup-ul explicit
    }

    @Test
    public void test2() {
        // Alt test specific
    }
}

Această organizare a codului facilitează menținerea și extinderea suitei de teste și contribuie la un cod mai curat și mai ușor de gestionat în timp.

Utilizarea setup și teardown în teste automate cu Selenium și Java oferă o structură bine organizată și modulară pentru gestionarea configurării și închiderii mediului de test. TestNG facilitează aceste operațiuni prin intermediul anotărilor @BeforeClass și @AfterClass. Implementând aceste practici, poți asigura că testele tale rulează într-un mediu coerent și că resursele sunt gestionate eficient.

Cum să faci un screenshot folosind librăria Selenium în Java

Selenium este o librărie populară pentru automatizarea testelor pe aplicații web. Printre numeroasele funcționalități pe care le oferă, se numără și posibilitatea de a realiza capturi de ecran (screenshot-uri) ale paginilor web. În acest articol, vom explora cum poți utiliza Selenium în Java pentru a realiza un screenshot al unei pagini web.

Pasul 1: Configurarea proiectului Java

Pentru a începe, asigură-te că ai configurat un proiect Java și ai adăugat librăria Selenium în claspath-ul proiectului tău. Poți face acest lucru prin adăugarea dependenței în fișierul de configurare Maven (pom.xml) sau prin descărcarea și adăugarea manuală a bibliotecilor Selenium.

Exemplu pentru Maven:

  <dependencies>
    <dependency>
        <groupId>org.seleniumhq.selenium</groupId>
        <artifactId>selenium-java</artifactId>
        <version>4.16.1</version> <!-- Asigură-te că utilizezi ultima versiune disponibilă -->
    </dependency>
</dependencies>

Pasul 2: Inițializarea driver-ului Selenium

Înainte de a realiza un screenshot, trebuie să inițializezi un driver Selenium pentru a controla un browser. În exemplul nostru, vom utiliza ChromeDriver.

public class HotToTakeScreenshotWithSelenium {

	
	 public static void main(String[] args) {

	        // Inițializează un obiect WebDriver pentru Chrome
	        WebDriver driver = new ChromeDriver();

	        // Deschide o pagină web
	        driver.get("https://www.keybooks.ro");

	        // Realizează un screenshot și salvează-l într-un fișier
	        try {
	            // Utilizează metoda getScreenshotAs pentru a realiza captura de ecran
	            File screenshotFile = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
	            
	            // Salvează captura de ecran într-un fișier
	            FileUtils.copyFile(screenshotFile, new File("poze/screenshot.png"));
	        } catch (IOException e) {
	            e.printStackTrace();
	        }

	        // Închide browser-ul
	        driver.quit();
	    }
	
}

Pasul 3: Adăugarea excepțiilor și importurile necesare

În exemplul de cod de mai sus, am adăugat un bloc try-catch pentru a trata excepțiile care pot apărea în timpul realizării și salvării capturii de ecran. De asemenea, am importat clasele necesare pentru a gestiona aceste operațiuni.

import java.io.File;
import java.io.IOException;

import org.apache.commons.io.FileUtils;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

Concluzie:
Utilizând librăria Selenium în Java, realizarea unui screenshot al unei pagini web devine o sarcină simplă. Acest exemplu furnizează o bază solidă pentru începerea automatizării testelor și a altor activități care implică capturi de ecran în cadrul proceselor de dezvoltare software.

Exemplul de cod poate fi accesat aici: github.com

De ce testarea manuala este un job sigur pentru viitor?

Testarea manuală a software-ului este o parte critică a ciclului de dezvoltare a software-ului. Este procesul de testare a software-ului în mod manual, adică fără utilizarea automatizării. Deși automatizarea testelor a devenit o parte din ce în ce mai importantă a testării software-ului, testarea manuală rămâne încă o necesitate.

În prezent, testarea manuală a software-ului continuă să fie un job important pentru viitor, cu o cerere ridicată pe piața muncii. Există mai multe motive pentru care testarea manuală a software-ului este considerată un job pentru viitor, iar acestea includ:

  1. Creșterea complexității software-ului – Pe măsură ce software-ul devine din ce în ce mai complex și mai sofisticat, este necesară o testare manuală mai riguroasă pentru a verifica că funcționează corect și că îndeplinește cerințele utilizatorilor.
  2. Limitările automatizării testelor – Deși automatizarea testelor poate fi eficientă în multe situații, există încă limite ale automatizării. Unele aspecte ale testării software-ului necesită încă o abordare manuală, cum ar fi testarea interfeței cu utilizatorul sau verificarea calității graficii.
  3. Creșterea cererii de testare – O cerere în creștere pentru dezvoltarea rapidă a software-ului și de livrare continua duce la o creștere a cererii pentru testare manuală a software-ului, deoarece este necesară o abordare rapidă și flexibilă pentru testare.
  4. Necesitatea testării de securitate – Pe măsură ce amenințările cibernetice devin tot mai sofisticate, testarea manuală devine mai importantă pentru a detecta vulnerabilitățile de securitate ale software-ului. Testarea manuală poate ajuta la identificarea problemelor de securitate și la prevenirea unor probleme grave înainte de lansarea software-ului în producție.

În concluzie, testarea manuală a software-ului va continua să fie un job important pentru viitor. Deși automatizarea testelor poate fi eficientă, există încă limite ale automatizării, iar cererea pentru testare manuală a software-ului este în creștere. Testarea manuală poate fi o opțiune interesantă de carieră pentru persoanele care sunt pasionate de tehnologie și care doresc să lucreze într-un mediu dinamic și provocator. Cu toate acestea, este important să se continue dezvoltarea abilităților și cunoștințelor în domeniul testării, deoarece industria continuă să se schimbe și să evolueze.

Daca esti interesat sa inveti testare software, te asteptam la curs: Curs testare manuala

Poate AI (Artificial Intelligence = Inteligenta Artificiala) sa inlocuiasca testarea manuala?

 

Photo by : https://www.pexels.com/@tara-winstead/

Inteligenta artificiala (IA) poate fi utilizata in testarea software-ului pentru a imbunatati eficienta si acuratetea procesului, dar nu poate inlocui complet testarea manuala, cel putin nu inca.

IA poate fi folosita pentru a identifica pattern-uri in datele de test, astfel incat sa poata fi create scenarii de test automate mai bune si mai robuste. De asemenea, IA poate fi folosita pentru a testa software-ul in mod repetitiv si pentru a identifica probleme care pot fi dificil de observat prin intermediul testarii manuale.

Cu toate acestea, testarea manuala ramane o necesitate, in special in ceea ce priveste testarea functionalitatii si a interfetei cu utilizatorul. Testarea manuala poate fi necesara si pentru a verifica ca software-ul raspunde corespunzator la situatii neasteptate si ca respecta cerintele de afaceri si asteptarile utilizatorilor.

De asemenea, testarea manuala este necesara pentru a verifica ca documentatia si instructiunile sunt corecte si usor de inteles pentru utilizatorii finali. In concluzie, IA poate fi o tehnologie foarte utila in testarea software-ului, dar nu poate inlocui complet testarea manuala.

Testarea manuala va continua sa fie o parte importanta a procesului de dezvoltare a software-ului si va ramane un job important pentru viitor. 

5 principii esentiale in testarea automata

1. Setup & teardown

Mecanismul de setup si teardown se refera la crearea datelor de test in metode specifice de pre-run, iar apoi stergerea acestor date sau revenirea la valorile initiale in cazul in care au fost date doar modificate, in metode de post-run. Astfel, inaintea executiei unui test automat, pregatim datele de teste in metode de pre-run(setup), care pot insemna, diverse apelari de RestApi sau interogari si operatiuni in bazele de date ale aplicatiei sau chiar si generarea de date de test aleatorii folosind functii special create pentru aceasta.
Apoi, dupa executia test case-ului, intra in scena metoda de post-run(teardown), care presupune ca toate datele de test care au fost create si folosite in test case (date create in setup) sa fie sterse sau modificate la valorile lor initiale. Atentie, metodele de post-run trebuie sa se execute indiferent de statusul test case-ului, daca a fost Pass sau Fail.
O greseala comuna in testarea autoamata este nerularea metodelor de teardown in cazul in care test case-ul este Fail. In acest caz, tot ce a fost creat si modificat in setup, va ramane, putand astfel sa cauzeze un rezultat neasteptat la urmatoarele rulari.

2. Testele trebuie sa fie independente

Fiecare test case automat ar trebui sa poata rula independent fara a depinde de alt test case-uri. Aceasta dependenta se refera atat la datele de test, cat si la locul de unde incepe test case-ul sa se execute in aplicatie. De foarte multe ori am observat situatii in care se incepe automatizarea unui test case din locul unde test case-ul precendent a lasat aplicatia. De exemplu: daca aplicatia noastra are 10 ecrane si noi avem 10 test case-uri pentru fiecare ecran, daca test case-ul 5 incepe de unde a terminat test case-ul 4, este gresit. Aceasta presupune dependenta fata de testul precedent. Daca test case-ul 4 esueaza in momentul executiei, niciun alt test care urmeaza si care depinde de el nu va putea sa se execute cu succes.
Este valabil si in cazul datelor de test. Daca un test are nevoie de anumite date care ar trebui create de catre un alt test case, este deasemenea gresit. Datele de test pentru teste ar trebui intodeauna create folosind un mecanism de setup & teardown, asa cum a fost  descris la punctul 1.
Dependenta intre teste, omoara testarea paralela.

3. Introducerea unui mecanism de retry(re-rulare a testului)

De multe ori in testarea automata nu putem controla tot mediul de testare. Spre exemplu, nu avem niciun control asupra timpului in care un browser incarca aplicatia sau un API raspunde in urma unui apel HTTP. Acestea pot depinde de foarte multi factori care pot tine de la incarcarea masinii pe care executam testele, pana la latenta vitezei internetului in acel moment. Cum ne afecteaza lucrul acesta executia testelor automate? Prin faptul ca ne poate introduce rezultate neasteptate in momentul executiei. O greseala comuna este aceaa de a adauga timpi de asteptare de fiecare data cand intalnim astfel de comportamente. Este o abordare gresita pentru ca aceste asteptari nu fac nimic altceva decat sa adauge ceea ce numim timp mort in executie. Timpul mort este reprezentat de timpul in care suita de teste asteapta, de multe ori fara sa fie nevoie de aceste asteptari. Pe termen mediu si lung, privit macro (la nivel de suita de teste, nu de test case), acele cateva secunde pe care le adaugam se vor transforma in minute bune, cand le vom aduna din toate test case-urile. Nu este optim sa avem o suita de teste care sa se execute in zeci de minute sau poate chiar ore. Aici intervin mecanismele de retry, unde, atunci avem nevoie de o anumita conditie pentru a trece mai departe, in loc sa asteptam ca acea conditie sa se indepliuneasca dupa un anumit timp, introducem un mecanism de retry al pasului respectiv si incercam din nou in loc sa asteptam.

4. Executia paralela

Executia paralela ne ajuta sa micsoram timpul de rulare a testelor. Pentru orice companie care dezvolta software, “time to market” este esential si se traduce de cele mai multe ori in veniturile pe care compania respectiva este capabila sa le genereze. Time to market se refera la capacitatea organizatiei de a a livra un produs finit catre publicul tinta. Masoara timpul de la concept, pana in punctul in care utilizatorul final poate folosi produsul respectiv. Cu cat acest timp este mai mic, cu atat compania isi creste sansele de succes. In cazul in care timpul mare, exista riscul ca utilizatorii finali sa primeasca acealsi produs de la o companie concurenta, ceea ce va scadea sansele de succes. In acest context, cand totul se reduce la viteza de livrare,  o suita de teste automate care ofera un feedback dupa o executie care poate dura ore (pentru fiecare instalare in productie a aplicatiei) nu este cea mai buna idee. In aceste situatii, din pacate, exista riscul de a se sari peste executia testelor, pentru ca dureaza prea mult.

Dar ce facem daca testele sunt pur si simplu foarte multe si dureaza foarte mult? Solutia este: testarea in paralel. In primul rand, ca sa putem testa in paralel, toate principiile de mai sus trebuie sa fie implementate in suita noastra de teste. Daca testele sunt independente si nu depind unele de altele sau de acelasi seturi ale datelor de test, atunci, imaginati-va o suita de teste care in mod normal se executa in 4 ore, ca poate fi impartita pe 4 fire de executie separate (chiar si pe 4 masini diferite) si vor rula in doar 1 ora. Daca adaugam alte 4, vor rula in 30 de minute. O astfel de abordare ne ajuta sa economisim timp. Alt avantaj este si faptul ca reducand timpul de executie total, putem rula suita la fiecare schimbare de cod pe care programatorii o fac, astfel crescand increderea in calitatea software-ului livrat.

5. Executia in CI/CD

CI (Continuous Integration)/CD(Continuous deployment) sunt practici din dezvoltarea software care presupun o integrare si instalare continua in productie a schimbarilor aduse in programul software. Ele ne ajuta sa atingem acel time to market de care  aminteam mai sus. Ca aceste lucruri sa se poata intampla fara incidente majore, software-ul trebuie sa fie testat. Insa nu putem atinge acea viteza si integrare continua daca trebuie sa ne oprim tot timpul sa asteptam ore sau zile testarea aplicatiei. Testarea trebuie sa se intample rapid, continuu si fara sa aduca timpi de asteptare mari. Am intalnit multe situatii in care se scriu teste automate si se executa de pe calculatorele individuale. Altfel spus, sunt teste automate executate manual. Este o abordare gresita! Testele automate trebuie sa fie executate in mod automat, declansate de schimbarile in cod pe care le fac programatorii aplicatiei si sa actioneze ca o poarta de siguranta. Daca un programator schimba ceva in cod, se vor declansa testele automate, iar daca un test pica, atunci schimbarea facuta de programator nu trebuie sa treaca mai departe pana nu analizam daca a cauzat testul care a fost fail. Acesta este unul din scopurile testelor automate: sa te aiguri ca ceea ce ai implementat nu strica ceea ce exista deja in aplicatie.

In concluzie, nu este suficient sa stim doar sintaxa unui limbaj de programare si metodele unei librarii pentru a scrie teste automate.

O suita de teste construita corect trebuie sa se bazeze inca de la inceput pe principii corecte, pe un  mod corect de a structura codul scris, astfel incat sa putem avea atat stabilitate, perfomanta, scalabilitate pentru noi teste , dar si un nivel de mententanta cat mai redus.

Ce este testarea software?

In zilele noastre, lumea a ajuns sa fie condusa de catre technologie. Regasim programe software aproape in orice dispozitiv cu care interactionam. In multe cazuri ne lasam viata pe mana unor programe software fie fara sa stim, fie sperand ca ele nu vor esua niciodata.

Pe masura ce numarul dizpozitivelor care se bazeaza pe diverse programe software creste, nevoia de testare software este din ce in ce mai crescuta si abilitatile pe care testerii software le detin au devenit din ce in ce mai cautate.

In ciclul de viata al unui produs de la design pana in productie, testarea este primul proces prin care se evalueaza calitatea software-ului construit.
Testarea software este un proces prin care se evalueaza criteriile functionale si nefunctionale ale uneii aplicatii cu scopul de a identifica defecte.
Este un proces de verificare si validare a unui produs software.

Care este scopul testarii software?

Scopul testarii software nu este sa gaseasca defecte asa cum multi cred. Scopul testarii este sa ne asiguram ca produsul dezvoltat este in conformitate cu cerintele utilizatorilor finali si ca este dezvoltat asa cum a fost specificat in documentele de design.

Astfel, prin testare ne asiguram ca produsul poate fi folosit asa cum este intentionat a fi folosit, ca respecta cerintele utilizatorilor si nu are defecte majore care sa pericliteze experienta utilizatorului final.

De ce avem nevoie de testare software?

Avem nevoie de testare software pentru ca aceasta minimizeaza riscul aparitiei defectelor in programele software.

Aceste defecte, pot cauza de la pierderi monetare foare mari pana la pierderi de vieti omenesti.

Cateva exemple de asfel de defecte:

  • Din cauza unui defect software un avion Airbus A300 al companiei China Airlines s-a prabusit in anul 1994. Au murit 264 de oameni.
  • Tot din cauza unui defect software, racheta Ariane5 a explodat la cateva zeci de secunde de la lansare. Racheta nu avea echipaj uman la bord, dar urma sa plaseze pe orbita doi sateliti. Costul pierderii rachetei si celor doi sateliti se ridica la peste 400 milioane de dolari.
  • Starbucks a fost nevoit la un moment dat sa inchida peste 60% din localurile din USA si Canada din cauza unui defect la sistemul de plati.

Astfel de erori apar zilnic in procesul de dezvoltare al unui produs software. De aceea, companiile producatoare de software acorda o importanta la fel de mare testarii precum este acordata si procesului de dezvoltare.

Companii precum Google, nu mai fac de foarte mult timp diferente intre programatori si testeri. Pentru Google toti sunt ingineri software responsabili de calitatea produsului dezvoltat.

Cine poate face testare software?

Sunt multe voci care spun ca nu oricine poate face testare software. Pentru ca testerii au un anumit tip de gandire (mindset) care ii ajuta sa gaseasca probleme acolo unde un dezvoltator spre exemplu nu s-ar uita niciodata.

Aceasta afirmatie este partial adevarata: nu oricine are acest tip de gandire, pentru ca acesta se invata. Oricine poate fi tester daca are un mentor bun, daca ii place testarea si investeste timp si pasiune in a invata aceasta meserie. Sa fii tester fara a trece print-un program de invatare nu este posibil.

In general un tester bun isi dezvolta urmatoarele abilitati:

  • Gandire critica.
  • Capacitatea de analiza.
  • Comunicare eficienta.
  • Abilitati technice.
  • Capacitatea de a intelege cerinte de bussines.

Toate aceste abilitati pot fi invatate si transpuse catre caracteristicile domeniului IT.

Testing is a skill. While this may come as a surprise to some people it is a simple fact..

Fewster and Graham

Tipuri de testare software?

In practica testarea software este impartita in foarte multe tipuri. In functie de natura si scopul aplicatiei testate decidem ce fel de teste trebuie sa executam.Aceste tipuri de teste pot fi impartite in doua mari categorii: teste functionale si teste nefunctionale.

Cateva exemple din categoria testelor functionale sunt:
  • Unit testing
  • Integration testing
  • System testing
  • Sanity testing
  • Smoke testing
  • Interface testing
  • Regression testing
  • Acceptance testing
  • Black box testing
  • White box testing
Cateva exemple din categoria testelor nefunctionale sunt:
  • Performance testing
  • Load testing
  • Volume testing
  • Stress testing
  • Security testing
  • Compatibility testing
  • Penetration testing

Viitorul testarii software?

O data cu revolutia social media a aparut un fenomen care da o putere extraordinar de mare consumatorilor. Puterea de a raspandi feedback-ul lor foarte rapid in grupuri foarte mari de oameni.

Acesta viralizare a feedbackului poate foarte simplu sa induca sucessul sau esecul unui produs. Din aceasta cauza companiile producatoare de software, sunt si vor fi si mai mult pe viitor atente la nevoile si parerile consumatorilor finali.

Un exemplu foarte bun in acest sens il reprezinta lansarea jocului Cyberpunk 2077. O lansare cu foarte multe defecte nerezolvate. In comunitatile de gaming aceste defecte au iscat un val masiv de nemultumiri,  care apoi sau viralizat foarte rapid, astfel incat o parte din cei care cumparasera jocul au cerut returnarea banilor. Firma producatoare a fost nevoita sa ofere si reduceri masive din pretul initial al jocului in urma valurilor de nemultumiri.

Toate aceste actiuni reprezinta pierderi financiare si de imagine pentru companiile producatoare.De aceea, va exista pe viitor un focus si mai mare pe zona de testare, pentru ca testarea diminueaza riscul consumatorilor finali de a avea o experienta neplacuta cu produsul software.

Astfel testarea, indiferent ca este facuta manual sau automat, ajuta companiile sa livreze produsele cu nivelul de calitate adecvat, minimizand astfel eventuale pierderi financiare sau de imagine. Testarea software va continua sa reprezinte o plasa de siguranta inaintea lansarii produselor mult timp de acum inainte.

In testare exista o zicala: daca nu l-ai testat, nu stii daca functioneaza!

Happy testing!

PS: In curand vom incepe un nou Curs Practic de Testare Software. Poti afla mai multe despre acesta aici. 

Ce face un software tester?

Un software tester, sau QA analyst sau software test engineer este o persoana la fel de importanta in procesul de dezvoltare a unui produs cum este si un dezvoltator, sau programator sau software engineer.

Cele doua roluri sunt complementare in ciclul de viata al unui produs software.

Programatorul este responsabil pentru scrierea codului sursa al programului respectiv, iar testerul este persoana care se asigura de integritatea, calitatea , eficienta si buna functionalitate a codului scris.

Mai pe scurt, un tester software se ocupa cu verficarea unui program, sau a unei parti a unui program cu scopul de a identifica eventuale deficiente de rulare.

Aceste deficiente pot fi cauzate de: erori de design, intelegere gresita a cerintelor clientului, erori de programare, etc.

In general in industria IT ne referim la membrii echipei de testare sub titulatura de QA (Quality Assurance).

Aceasta este o denumire generica, iar in realitate vom intalni testeri care sunt specializati pe anumite tipuri de testare, sau care au diferite roluri in cadrul echipei de testare sau a echipei de proiect.

Ca si structura generala (care poate avea mici variatii de la companie la companie) a unei echipe de QA, cel mai des intalnim urmatoarele roluri:

 

Structura tipica a unei echipe de QA

In functie de cat de mare este echipa de QA, aceste roluri se pot granula in specializari pe diverse tipuri de testare (performance tester, uat tester, security tester , etc) sau nivele de senioritate (junior, regular, senior, expert).

Aceste diferentieri se fac pentru a defini cat mai bine care sunt competentele si responsabilitatile fiecaruia.

Responsabilitati generale ale unui tester software

In general o mare parte a proceselor si responsabilitatilor sunt comune.

Ca si termini generali, cand ne referim la responsabilitatile de zi cu zi ale unui tester ne gandim la urmatoarele aspect:

  • Crearea si documentarea scenariilor de test
  • Executia testelor conform test planului si a strategiei de testare asumate la nivel de produs sau companie
  • Analiza si raportarea rezultatelor procesului de testare
  • Analiza si raportarea deficietelor (defecte) gasite in procesul de testare

Un tester are cunsostinte foarte bune legate de metodele de design al scenariilor de test, modelelor de test aplicabile in functie de aplicatia testata, metodelor de executie a testelor si nu in ultimul rand abilitati de comunicare foarte bune.

 

Cum am pus in diagrama de mai sus, intalnim foarte des doua ramuri clar differentiate in ceea ce priveste cariera de tester software.

Prima este zona de testare manuala a aplicatiilor si cea de a doua este zona de testare autoamata a acelorasi aplicatii.

QA Manual Tester

Acest tip de testare se bazeaza pe executarea scenariilor de test intr-un mod manual. Adica exact cum procedeaza un utilizator final cu aplicatia.

Spre exemplu, daca testam un magazine online, un scenariu tipic de test presupune parcurgerea de la crearea unui cont pana la adaugarea in cos a unui produs si incercarea platii.

Acest scenariu se executa manual, prin deschidera intr-un browser a magazinului respectiv si parcurgerea tuturor pasilor de test folosind mouse-ul si tastatura. Exact cum facem oricare dintre noi cand comandam un produs online.

Testerul manual este specializat in a gasi defecte acolo unde testarea automata nu poate, bazandu-se pe experienta, pe abilitatile de observare si pe ceea ce in industria IT numim “Tester mindset”.

Acest “tester mindset” se invata si reprezinta un mod de a gandi scenariile de test si executia lor in functine de unde este cel mai probabil a se gasi defecte.

De obicei ne referim la acest mindset sub forma : Testerul intodeauna se gandeste cum sa “strice” programul testat.

Responsabilitatile de zi cu zi ale unui tester manual pot include:

  • Parcurgerea documentatiei primite de la client pentru a intelege cerintele si nevoile clientului
  • Comunicarea continua cu clientul
  • Scrierea de scenarii de test
  • Raportarea defectelor gasite
  • Ajutarea programatorilor in reproducerea defetelor
  • Executarea scenariilor de test
  • Raportarea progresului testarii
  • Contribuirea la definirea strategiei de test sau a planului de testare

Aceste sunt cele mai comune, dar in functie de specificul si stadiul proiectului sau de nivelul de senioritate al testerului se pot adauga sau scoate din responsabilitati.

 

QA Automation Tester

Acest tip de testare se bazeaza pe scrierea de programe (scripturi) care in mod automat (programatic) sa execute scenarii de test.

Daca ne referim la acealsi scenariu de mai sus in magazinul online, un test automat presupune scrierea de cod sursa, care sa simuleze parcurgerea acelorasi pasi fara utilizarea mouseului sau a tastaturii. Totul se face prin simulare programatica.

Testerul automat este cel mai aproape de dezvoltator ca si profil pentru ca ambii scriu cod sursa, difernta fiind ca unul (dezvoltatorul) scrie un program, iar testerul automat scrie un program cu care testeaza programul scris de dezvoltator.

Este foarte des intalnit in idustria IT ca  foarte multi QA Automation testeri sa faca pasul catre cariera de dezvoltator dupa o perioada.

De ce avem nevoie de acest profil cand dezvoltam software? Pentru ca de cele mai multe ori numarul scenariilor de test cresc pe masura ce produsul software se dezvolta sin oi functionalitati sunt adaugate.

Astfel avem nevoie de o modaliate de a testa cat mai repede ce a fost deja dezvoltat pentru a ne asigura ca noile functionalitati adaugate nu strica vechile functionalitati. Astfel testarea autoamata ajuta testerul manual sa se concentreze pe testarea functionalitatilor noi in loc sa piarda timpul cu retestarea celor vechi.

Cateva dintre responsabilitatile  de zi cu zi pot include:

 

  • Scrierea de teste automate folosind diverse limbaje de programare si framework-uri (instrumente specifice cu ajutorul carora se scriu si executa testele)
  • Executia testelor automate
  • Analiza rezultatelor testelor
  • Mentenanta testelor automate
  • Raportarea defectelor intalnite
  • Analiza de programe noi pentru testare automata.

 

QA Lead/ QA Manager

Acestea reprezinta roluri de management de echipa. Sunt roluri de coordonare a caror principala responsabiliate este aigurarea la nivel de companie a unui proces si strategie de testare in conformitate cu standardele companiei.

In general aceste pozitii sunt ocupate de catre testerii care au ajuns la un nivel de senioritate de expert si care demonstreaza deasemenea si abilitati de coordonare.

Ca si responsabilitati generale putem enumera:

  • Pregatirea strategiei de testare la nivel de companie au proiect
  • Recrutarea de personal (testeri)
  • Alocarea testerilor in functie de competente si senioritate pe proiecte
  • Definirea de indicatori de calitate
  • Reprezentarea echipei de QA in sedintele de management
  • Supervizarea activitailor de testare si raportarea lor catre managementul superior
  • Identificarea de noi procese de testare si ajustarea proceselor naturale.

Acestea sunt responsabilitatile comune, care se regasesc indiferent de specificul companiei in care opereaza echipa de QA.

 

 

Ce reprezinta un ”load balancer”?

Acest articol face parte dintr-o serie, in care ne propunem sa explicam in termeni cat mai simpli, o parte din notiunile folosite in industria IT.

Pentru ca o mare parte din termenii folositi in industrie sunt in limba engleza si nu au neaparat o traducere exacta in limba romana. De aici si confuzia multora in ceea ce priveste semnificatia multora dintre acesti termeni.

Asadar, astazi vom vorbi despre “Load balancer

Cand ne referim la termenul de “load balancing”, ce vrem sa spunem este procesul prin care se face distributia traficului pe care serverele aplicatiei noastre il primesc de la consumatorii ei.

De ce avem nevoie de load balancing ?

Pentru ca aplicatiile din zilele noastre sunt accesate concomitent de un numar foarte mare de utilizatori in acelasi timp. Acest lucru pune presiune pe serverele aplicatiei si poate cauza un timp de raspuns mai mic asupra actiunilor utilizatorilor finali, ceea ce inseamna o nemultumire a acestora legata de modul in care aplicatia raspunde la comenzi.

Sa luam exemplu Instagram, unde sute de mii sau milioane de oameni cer sa acceseze fotografii in acelasi timp.
Serverul trebuie sa fie capabil sa raspunda cu fotografia ceruta in cel mai scurt timp posibil.

Ca acest lucru sa se intample dezvoltatorii adauga din ce in ce mai multe servere care sa proceseze aceste requesturi cat mai repede.

Astfel avem nevoie de o modalitate de a distribui aceste request-uri, catre toate serverele aplicatiei, si aici apare nevoia de load balancing.

Un load balancer se intrepune intre utilizatorii finali si serverele aplicatiei cu scopul de a :

  • Distribui requesturile venite din partea utilizatorilor pe mai multe servere
    • Sa asigure disponibilitatea si accesibilitatea aplicatiei prin distributia cererilor doar catre serverle care le pot gestiona (nu au load mare, nu sunt offline, etc)
    • Permite adaugarea si scoaterea de servere din ecosistemul aplicatiei in functie de cerinte
    • Automat redirecteaza toate requesturile cand un server trece offline catre restul serverelor

Mai jos o sunt cativa algoritmi care se folosesc pentru load balancing:

Round robin : Acest tip de algoritm permite ca requesturile sa fie distribuite secvential catre fiecare server in parte.

Weighted Round Robin : Acest alogritm functioneaza la fel ca metoda round robin, doar ca in cazut acesta, fiecarui server I se atribuie o pondere, si serverul cu o pondere mai mare va primi mai mult trafic iar serverul cu o pondere mai mica ba primi un trafic mai mic.

Least connection : Acest algoritm ia in considerare incarcarea serverului, astfel, traficul va fi distribui pe baza numarului de sesiuni active. Serverul cu cele mai putine sesiuni active va fi favorizat in a primi traficul.

Weighted least connection:  Acest algoritm este construit pe baza technicii de mai sus, doar ca in plus fiecarui server I se atribuie o pondere. Daca doua servere detin acelasi numar de sesiuni active, atunci se ia in considerare si ponderea, iar traficul va fi directionat catre serverul cu ponderea mai mare.

Least response : Acest algoritm ia in considerare atunci cand redirectioneaza traficul catre un server, care este serverul cu cel mai mic timp de raspuns si care are cele mai putine sesiuni active.

Acestia sunt doar cativa algoritmi care sunt folositi, in general difera in functie de cum sunt construite applicatiile din punt de vedere architectural.

Ce reprezinta “Technology stack” sau “Tech stack”

Acest articol face parte dintr-o serie, in care ne propunem sa explicam in termeni cat mai simpli, o parte din notiunile folosite in industria IT.

Pentru ca o mare parte din termenii folositi in industrie sunt in limba engleza si nu au neaparat o traducere exacta in limba romana. De aici si confuzia multora in ceea ce priveste semnificatia multora dintre acesti termeni.

Asadar, astazi vom vorbi despre “Technology stack”, “Tech stack” sau “Application stack”

In interiorul industriei IT, folosim zilinc aceasta expresie pentru a ne referi la technologiile care sunt folosite intr-un anumit proiect.

Exemplu : Care este tech stack-ul proiectului tau ?

Intrebarea se refera la :

Care sunt limbajele de programare  si bazele de date care sunt folosite in interiorul proiectului.

Care sunt technologiile folosite in interiorul aceluiasi proiect si care sunt produsele software care sunt folosite pentru dezvoltarea produsului.

Putem spune ca este o sumarizare a technologiilor folosite pentru crearea unui produs software.

In general, atunci cand recruteaza, companiile se refera direct la tech stack-urile folosite pentru a recruta candidati.

Cateva categorii care compun un tech stack sunt (nu va faceti griji pentru denumirile in engleza, le vom explica in articole ulterioare):

Limbajele de programare : Aceste sunt alese in functie de specificul aplicatiei pentru care se dezvolta, daca este doar pentru aparate mobile sau de orice tip, in functie de zona de dezvoltare, daca vorbim de partea de server sau de partea cu care utilizatorul final interactioneaza (UI = user interaction; website sau interfata unei aplicatii).

Exemple de limbaje de programare populare sunt : Java; Python, JavaScript, Ruby, Swift, C#, C++, Go, PHP

Servere si load balancing  : Acestea reprezinta partea de server, partea de distributie a continutului in cadrul retelei, partea de rutare si de cache (datele “cache” sunt informatii transmise de catre un website sau o aplicatie care sunt ulterior stocate, pentru a fi folosite mai tarziu)

Servicii populare in aceasta categorie sunt : AWS, Google Cloud, Azure, Apache, Ngnix, CloudFlare

Stocare si cautare de date : Aceasta parte este reprezenta de catre bazele de date si alte tipuri de aplicatii care iti permit sa stochezi si sa cauti in acele stocuri de date. Spre exemplu date legate de produsele unui site de cumparaturi, sau datele legate de comportamentul unui user care mai tarziu iti permit sa imbunatatesti aplicatie pe baza acestui comportament.

Produse populare in aceasta categorie sunt : MySql, MongoDD, Cassandra, PostgresSql, Azure SQL, RedShift, Oracle

Frameworks pentru zona de backend :  Simplist spus, framework este o colectie de limbaje, librarii si alte utilitati care sunt folosite de catre programatori pentru a crea aplicatii. Tot simplist, backend se refera la zona de management de contiut a aplicatie. Este compus din mai multe parti (server, baza de date, aplicatie).

Produse populare in aceasta categorie sunt : Spring, Django, Laravel, RubyOnRails, .Net

Frameworks pentru zona de frontend : Simplist spus frontend se refera la zona de interactiune cu userul final. Website-ul sau interfata unei aplicatii.

Produse populare in aceasta categorie sunt : AngularJs, React, Flutter, Boostrap, JQuery, EmberJS

Monitorizare : In aceasta categorie intra produsele folosite pentru a tine sub observatie performanta si modul in care o aplicatie se comporta in momentul in care este folosita. Se iau in considerare diverse tipuri decomportamente (performanta, scalabilitate, etc). Ele analizeaza intreaga aplicatie de la bazele de date pana la zona de interactiune cu utilizatorul final.

Produse populare in aceasta categorie sunt : DataDog, Nagios, Zabbix, Dynatrace, AppDinamics

Acestea sunt doar cateva dintre categorii, dar care sunt printre cele mai importante de mentionat.

Acum ca sa ne facem o idee si mai clara, haideti sa vedem care sunt cateva dintre tech stack-urile catorva dintre cele mai uzuale aplicatii de zi cu zi :

SnapChat :

Limbaje de programare:  Java, Kotlin, Objective-C, Swift, JavaScript

            Frameworks: AngluarJs, JQuery, React, Boostrap

            Cloud: Google App Engine, Google Compute Engine, Google Cloud Datastore

            Baze de date: MySql, MongoDB, Redis

Netflix:

Limbaje de programare:  Java, Python, Kotlin, Swift, JavaScript

            Frameworks: NodeJS, React, Restify, RxJS

            Cloud: Amazon EC2, AMAzon S3, Amazon RDS, Amazon EMR etc

            Baze de date: MySql, PostgresSQL, Redis, Cassandra

Uber:

Limbaje de programare:  Java, Python, Objective-C, Swift, JavaScript, GO

            Frameworks: NodeJS, React, ExpressJS, BackboneJS

            Cloud: Amazon EC2, AMAzon S3, Amazon RDS, Amazon EMR etc

            Baze de date: MySql, PostgresSQL, Redis, Cassandra, MongoDB

Ce reprezinta ”SaaS”?

Acest articol face parte dintr-o serie, in care ne propunem sa explicam in termeni cat mai simpli, o parte din notiunile folosite in industria IT.

Pentru ca o mare parte din termenii folositi in industrie sunt in limba engleza si nu au neaparat o traducere exacta in limba romana. De aici si confuzia multora in ceea ce priveste semnificatia multora dintre acesti termeni.

Asadar, astazi vom vorbi despre “Saas” sau “Software as a Service

SaaS (Software ca serviciu) este unul din cele trei mari categorii ale cloud computing. Pe scurt, cloud computing este un concept care reprezinta un ansamblu distribuit de servicii, aplicatii si baze de date, pe care utilizatorul le acceseaza via internet, fara a avea nevoie sa le instaleze sau sa le configureze local.

O traducere in limba romana pentru termenul cloud computing nu exista.

Dar sa revenim. Cum spuneam, Saas este unul din cele trei mari categorii ale cloud computing, alturi de IaaS (Infrastructure as a Service = Infrastructura ca serviciu) si PaaS (Platform as a Service = Platforma ca serviciu)

SaaS ne permite sa utilizam aplicatii care nu sunt instalate la noi pe calculator, sau in reteaua noastra. Putem spune astfel, ca orice aplicatie care ofera un serviciu si pe care o accesam via internet reprezinta un SaaS.

Multi oameni folosesc deja SaaS fara sa stie ca o fac. Aplicatii ca Gmail, Hotmail, Yahoo, Google Docs, WordPress, Slack, toate sunt SaaS.

Chiar si Netflix este tot un SaaS. Netflix vinde un serviciu pe care il platesti sub forma de subscriptie lunara pentru a urmari filme si documentare care sunt licentiate (deci nu pot fi descarcate gratuit).

Tot ce tine de partea de hardware si software necesar pentru functionarea aplicatiei este gestionata de catre cei care pun la dispozitie aceasta aplicatie, din partea noastra neffind necesar sa instalam sau sa configuram aplicatia respectiva.

Aplicatiile SaaS sunt atat pentru scop personal cat si pentru bussines. Cum spuneam sim ai sus, Gmail este un exemplu foarte uzual pentru scop personal. Pentru firme, aplicatii gen Salesforce, Sap, sau diverse alte ERP-uri sunt foarte commune.

O confuzie des intalnita, este daca toate website-urile sunt SaaS ?, pentru ca sunt applicatii accesibile via internet.

Raspunsul simplu este nu. Raspunsul mai lung suna asa: Nu toate website-urile ofera servicii. Multe website-uri sunt doar pentru prezentare, sunt bloguri sau doar pentru impartasit idei si asa mai departe. Dar nu ofera un serviciu pe care utilizatorul final il foloseste.

Cateva (doar cateva) exemple de tipuri de servicii sunt mai jos: