O scurta prezentare a companiei SC GentLab SRL

GentLab SRL este o companie de dezvoltare de software ce ofera soluții si construieste

aplicații în multe platform.
Are o activitate de peste 10 ani in dezvoltare soluții software.
De-a lungul anilor, a lucrat cu companii precum IBM, Microsoft si Raiffeisen Bank.
Până în prezent, produsele pe care le-a dezvoltat sunt distribuite în principal, și aplicații de
sine stătătoare. Tehnologia evoluează într-un ritm mai rapid , prin urmare, compania este în
continuă creștere de programare și marcare a limbajelor moderne, dintre care enumera cele mai
populare:
- metodologia eficientă:
Executa studii de fezabilitate (studiu al unui proiect sau al unei investiții din punctul de vedere
al posibilităților tehnice de realizare și al rentabilității ) pentru fiecare proiect. Acestea permit să
cerceteze posibile probleme viitoare și să le abordeze înainte ca acestea să apară
- soluţii personalizate
Odată ce un prototip satisfăcător a fost stabilit, se v-a ajunge să se lucreze la produsul în sine,
ținând cont de toate preocupările și ideile propuse.
Compania este specializata in dezvoltarea de aplicații personalizate bazate pe web pentru
aplicații distribuite și de sine stătătoare.
- testarea profesională
Se testeaza fiecare linie de cod înainte de a o publica - se face acest lucru nu numai pentru
lansări de produse, dar, de asemenea, pentru lucrările de întreținere și sarcinile de îmbunătățire
continuă pe care le-ar putea sugera.
Software-ul ca serviciu (SAAS)
Compania este abonata la sistemul SAAS pentru a scapa de grijile cu privire la costurile ridicate
si functiile consumatoare de timp precum:
- achizitia si suportul pentru infrastructura bazata pe un server si necesarul de software
instalare, mentenanta, upgrade-uri periodice
- timpul consumat pentru intretinerea echipamentelor, descarcarea si instalarea de patch-uri
regulat
- reducerea spatiului necesar instalarii tuturor echipamentelor de IT, care trebuie sa
indeplineasca anumite conditii de securitate si fiabilitate (temperatura constanta etc.)
(Ideea din spatele ofertei Software as a Service (SaaS) este foarte simpla si poate fi asemanata cu
modul in care toate companiile achizitioneaza energie electrica. 99,99% dintre companii au acces
la reteaua de electricitate si nu folosesc pentru necesarul de energie generatoare de curent electric
proprii. In acelasi mod este privita in prezent si achizitia de software care, in mod traditional este
foarte costisitoare atat la prima achizitie cat si dupa aceea, prin nevoia de achizitie a unei noi
licente sau ale unor noi caracteristici ale software-ului respectiv. )
Solutia noastra SAAS
De ce SaaS?
Produsele SaaS înlocuiesc aplicații desktop, deoarece acestea sunt la fel de ușor de operat,
dar mai puțin pretențioase din punct de vedere al resurselor. Acest lucru le face ideale pentru
companiile care s-au axat pe creștere.
În calitate de furnizori SaaS, menținem toate componentele software și hardware ale soluției.
 - Acces online
Soluții SaaS pot fi accesate de pe orice dispozitiv care acceptă un browser web.
- Compatibilitate
Toți utilizatorii au aceeași versiune de software; actualizări și problemele de compatibilitate sunt
gestionate de către sistem în sine
- Scalabilitate
Extinderea unei licențe SaaS este mai ieftin și mai rapid decât alte licențe software. Personalul
dvs. nu va fi nevoie de upgrade-uri de stații de lucru pentru a utiliza un SaaS
- Nu necesită întreținere
Noi monitorizăm în mod constant bug-uri și îmbunătățiri potențiale, economisind timp
departamentul IT si banii companiei tale
- Flexibilitatea prețurilor
Costul lunar variază în funcție de numărul de utilizatori și nu trebuie să plătească pentru
modulele pe care nu le utilizați (întreținerea, administrarea și suport sunt gratuite)
Faza de testare
Tot ceea ce se dezvolta trece printr-un proces de testare agresiv, nimic nu merge in
productie pana nu se primeste un raport din partea echipei de testare.
Compania are testere in-house, adica testare interna de asigurare a calității, care încearcă să
“sparga” aplicațiile înainte ca acestea să fie lansata - ca rezultat. Datorita echipei de testare
compania poate garanta pentru toate proiectele pe care le da in productie.
In cadrul companiei exista o echipa de testare QA software care ajuta la imbunatatirea
aplicatiilor si depistarea problemelor acestora inainte de a ajunge in productie si reducerea
costurilor companiei.
TESTARE IN- HOUSE sau TESTARE INTERNA
Principalul avantaj al testelor in-house este abilitatea de a controla întregul proces și de a
aborda problemele cu promptitudine .
Dezavantaj este faptul că , aceast proces de testare este destul de costisitor , în comparație cu
unul externalizat . Acestea sunt costuri ascunse , inclusiv cheltuieli privind angajarea , formarea
oamenilor și a sprijini echipa full- time , chiar dacă nu aveți nevoie de serviciile sale în acest
moment .
Echipa de testare din cadrul companiei foloseste trei tipuri de testare :
- Testare automatizata
Folosind algoritmi dedicați, vom lăsa mașinile sa efectueze o serie de teste pentru a detecta
rapid problemele care ar putea apărea în timpul utilizării de zi cu zi. Testarea agila automate
oferă o rentabilitate mai mare în eforturile de dezvoltare.
- Testarea funcțională
Acest tip de testare se bazează pe specificațiile componentei software-ului în cadrul testului.
Definim cazuri de testare și de efectuare a testelor automate și manuale pentru a asigura ieșirea
corespunzătoare.
- Testarea manuală
Există unele lucruri care nu pot fi automatizate. Acesta este motivul pentru cel puțin un tester
care va juca rolul unui utilizator final și va verifica manual dacă exista problemele. Aceasta
este, de asemenea, o modalitate foarte bună de a detecta orice inconsistență UX și de a face
modificări ulterior.
Experiența utilizatorului
Cod trebuie să fie clar, concis și ușor de înțeles, deci este design-ul.
Echipa noastra UX tinteste incarcaturii cognitive minim asupra utilizarii soluțiilor
dumneavoastră. Software-ul noului Design-ul este intuitiv, asigurând un proces de învățare și de
adoptare rapidă.
Toate cele de mai sus sunt conduse spre maximizarea experienței utilizatorului, făcându-l
simplu în scopul de a acorda un acces rapid la informații într-un mod eficient.
Gentlab promoveaza un design inovator prin menținerea unui ochi cu privire la tendințele de
Apple și Google în ceea ce privește designul material și, în același timp, prin promovarea
propriului nostru mod de a face lucrurile.
Comunicarea in cadrul companiei intre echipe se realizeaza prin intermediul retelei de
socializare de business HipChat din pachetul Atlassian, Yahoo Mail, Gmail.
Compania are si Software de consultare
Având în vedere experiența echipei tehnice, sunt siguri si capabili de a oferi îndrumare și
sugestii de îmbunătățire pentru clienți ori de câte ori este nevoie.
Motivul principal pentru a alege compania GentLab în acest domeniu ar fi parteneriatul acesteia
cu BrainConcert care garantează că sunt în contact cu cele mai noi tehnologii și faptul că
stăpânesc unele dintre ele.
De fapt, unii dintre dezvoltatorii software cei mai experimentați sunt formatori certificați și
predau cursuri pentru partenerii companiei ori de câte ori este nevoie, iar tehnologia implicată
permite acest lucru.
Compania are Sistemul de management al calităţii conform standardului ISO 9001:2008.
 TESTAREA SOFTWARE SI ASIGURAREA CALITATII

Scopul testorului este de a depista erorile softului cât mai devreme posibil şi se asigură că ele au
fost fixate şi luate măsuri în legătură cu aceasta.
Calitatea softului este indicată doar prin testarea acestuia. Un caz de test trebuie sa definească
neapărat ieşirea sau rezultatul dorit. Un programator ar trebui sa evite sa-şi testeze propriul
program.
Satisfacerea cerințelor clientului este cheia reușitei oricărei afaceri. Obținerea încrederii
clientului prin oferirea un soft bun, de calitate.
Erorile depistate și fixate în faza de descriere a specificațiilor nu costă practic nimic. Erorile
depistate după livrarea produsului mărește costul acestora de la mii la milioane de dolari.
Companiile de programare nu ar trebui să-şi testeze produsele proprii.
Fiecare rezultat al testului trebuie examinat foarte minuţios. Cazurile de test trebuie să fie scrise
atât pentru condiţii de intrare valide cât şi pentru cele invalide şi neaşteptate.
Desfacurarea activitatii pe parcursul practicii a fost impartita in doua “categorii” “
- teorie – am stabilit ca o zi pe saptamana sa ne fie prezentat cate un curs despre : domeniul
IT, asigurarea calitatii in IT, tipuri de testare , metode de testare... .
- testarea propriu-zisa a platformei Kinderunity, prin utilizarea platformei ca un utilizator
obisnuit si raportarea defectelor.
Standardul IEEE 610 – 1990: “Un set de intrari ale testului, conditii de executie si rezultate
asteptate, dezvoltat pentru un obiectiv anume, cum ar fi sa exercite o anume cale a unui program
sau sa verifice corespondenta cu o cerinta specifica.”
Standardul IEEE 829-1983: “Intrari specificate de documentatie, rezultate asteptate si un set de
conditii de executie pentru un item al testului.”
Ron Patton (2001): “Cazurile de testare sunt intrarile specifice pe care le veti incerca si
procedurile ce vor urma cand testati produsul software.”
De fapt, un test este o intrebare pe care o punem aplicatiei. Scopul ei
este de a aduna informatii.
Calitatea unui produs este uneori definita ca “ totalitatea caracteristicilor sale prin care el
satisface o serie de necesitati definite sau impuse”.
Calitatea unui produs software este data de « capacitatea sa de a putea fi utilizat eficient,
efectiv si confortabil, de catre un set de utilizatori, pentru un set de scopuri, in conditii
specificate ».
Caracteristicile de calitate ale unui produs software sunt proprietati ale produsului la care
utilizatorii sunt sensibili.
De exemplu : usurinta de utilizare, fiabilitatea, timpul de raspuns, s. a.
Exista diferite modele de clasificare a caracteristicilor (atributelor) de calitate ale unui produs
software. Modelele includ adesea si masuri pe baza carora se stabileste gradul in care produsul
intruneste fiecare atribut de calitate. Fiecare model poate avea un set de atribute diferit la nivelul
cel mai inalt al clasificarii, de asemenea selectia si definitiile atributelor pot sa difere la toate
nivelele.
Calitatea ceruta pentru un produs software trebuie sa fie definita in documentul de definitie a
cerintelor software (SRD). De asemenea, trebuie specificate definitiile atributelor de calitate,
metodele de masurare si criteriile de acceptare pentru atribute.
Caracteristici de calitate ale produselor software
Incercarile de standardizare a terminologiei referitoare la calitatea produselor software au
condus la standardul ISO 9126 (InformationTechnology-Software Product Quality, Part 1:
Quality Model, 1998). Standardul contine definitii in special pentru produsul final.
Sunt definite 6 caracteristici de calitate, impartite in 21 de subcaracteristici.
1) Functionalitatea: realizarea scopului de baza pentru care a fost realizat produsul
 Oportunitatea: prezenta unui set de functii adecate pentru tascuri specificate
 Precizia: furnizarea unor rezultate sau efecte corecte sau agreate
 Interoperabilitatea: capacitatea produsului de a interactiona cu sisteme specificate
 Securitatea: capacitatea de a preveni accesul neautorizat, accidental sau deliberat, la
programe sau date
 Conformitatea: adeziunea la standarde, conventii, legi si protocoale

2) Fiabilitatea: capacitatea produsului de a-si mentine nivelul de performanta, in conditii

definite, pentru o perioada de timp definita.
 Maturitatea: atribut bazat pe frecventa caderilor datorate greselilor in software
 Toleranta la defecte (robustetea): capacitatea de a-si mentine un nivel de perfomanta
specificat in cazuri de caderi software sau intrari neasteptate
 Restabilirea dupa caderi: capacitatea si efortul necesar pentru restabilirea nivelului de
performanta, recuperarea datelor afectate, dupa posibile caderi
 Conformitatea

3) Utilizabilitatea: efortul necesar pentru utilizarea sa de catre un set de utilizatori definit

 Usurinta de intelegere: efortul solicitat unui utilizator de a recunoaste conceptul logic si
aplicabilitatea sa
 Usurinta de invatare : efortul solicitat unui utilizator de a invata aplicatia, operarea,
intrarile si iesirile
 Operabilitatea: usurinta de operare si de control de catre utilizatori
 Puterea de atractie: capacitatea produsului de a fi atragator pentru utilizatori
 Conformitatea

4) Eficienta: relatia intre nivelul de performanta al produsului si cantitatea de resurse

utilizate, in conditii definite
 Timp la executie: viteza de raspuns, timpi de prelucrare, rata iesirilor la realizarea
functiilor
 Utilizarea resurselor: cantitatea de resurse utilizate si durata utilizarii pentru realizarea
functiilor sale
 Conformitatea

5) Usurinta de intretinere: efortul necesar pentru efectuarea modificarilor, inclusiv corectii,

imbunatatiri sau adaptari ale produsului la schimbari ale mediului de functionare, a cerintelor si
schimbarilor functionale
 Usurinta de analiza: efortul necesar pentru diagnoza defectelor, a cauzelor caderilor,
pentru identificarea partilor care trebuie sa fie modificate
  Usurinta de modificare: efortul necesar pentru inlaturarea defectelor sau schimbari
 Stabilitatea: riscul efectelor neasteptate in urma modificarilor
 Usurinta de testare: efortul necesar pentru a valida produsul modificat
 Conformitatea

6) Portabilitatea: capacitatea produsului de a fi transferat de la o organizatie sau platforma

software/hardware la o alta
 Adaptabilitatea: capacitatea de adaptare la diferite medii specificate
 Usurinta de instalare: efortul necesar pentru instalarea produsului intr-un mediu specificat
 Co-existenta: capacitatea de a co-exista cu alte produse independente in acelasi mediu
 Oportunitatea si efortul necesar pentru a folosi produsul in locul altui produs intr-un
mediu particular
 Conformitatea

Asigurarea calitatii produselor software

Rolul activitatilor de asigurare a calitatii software este de a stabili ca produsele si procedurile
sunt in conformitate cu standardele si planurile.
In proiectele mici asigurarea calitatii poate fi efectuata de echipa de dezvoltare, dar in
proiectele mari trebuie sa fie realizata de o echipa speciala.
Activitatile de asigurare a calitatii sunt documentate in Planul de Asigurare a Calitatii
(Software Quality Assurance Plan (SQAP).
Prin activitatile de asigurare a calitatii se urmareste:
• Concordanta planurilor cu standardele
• Realizarea proceselor in concordanta cu planurile
• Implementarea produselor in concordanta cu planurile
Verificarea si validarea produsului software sunt de asemenea activitati de asigurare a calitatii.
Un sistem de asigurare a calitatii este ansamblul activităţilor care trebuie întreprinse pentru ca un
produs să fie de calitate.
Un sistem de Asigurare a Calităţii:
a) Activităţile propriuzise de inginerie
- analiza;
- proiectarea (concepţia);
- codificarea
- testarea (metode şi instrumente)
b) Reviziile aplicate la fiecare pas al proiectului
c) Strategiile de testare
d) Controlul documentaţiei software şi a ţinerii ei la zi
e) Compatibilitatea cu standardele (dacă este cazul)
f) Mecanismele de măsurare şi raportare (pentru a avea o măsură cantitativă a calităţii)
Tehnici de testare :
- Black box
- White box
- Gray box
Testarea Black box este o tehnică de testare software care se bazează în întregime pe cerinţele
software şi specificaţiile acesteia. În Testarea Black box ne concentrăm doar asupra intrărilor şi
ieşirilor ale sistemului şi NU suntem interesaţi de structura internă a programului software.
 Aceasta metodă testează funcționalitatea aplicației, nu abordează deloc codul și procesele
interne ale aplicației. Tester-ul nu trebuie să știe decat ceea ce trebuie să faca programul, nu și
cum face. Se urmărește „funcția de transfer” a programului: se dau date de intrare și se verifică
datele de ieșire, fără a se știi cum se face prelucrarea lor. Cazuri de testare se construiesc în jurul
cerințelor și specificațiilor. Aceste teste pot fi funcționale (cele mai multe) sau nefuncționale.
Aceasta metodă se poate aplica la toate nivelele de testare: de unitate, de integrare, de sistem și
de acceptare.
Deci se testează:
- Funcționalitatea
- Validarea datelor de intrare (să nu se accepte date de intrare neconsistente, ca”-1” la data
nașterii)
- Datele de ieșire
- Trecerea dintr-o stare în alta a sistemului (de exemplu la programul de instalare, componentele
unei aplicații se instalează intr-o anumita ordine, sau la realizarea unei conexiuni).[3]

Testarea White Box (cutia transparentă sau cutia deschisă) – tehnica de creare a cazurilor de test
asupra codului programului pentru a detecta orice scenariu cu potenţial eşec.
Testarea prin metoda cutiei albe (sau cutiei de sticlă/transparenta), sau testarea structurală este o
tehnică de testare care verifică structura internă și modul de prelucrare a datelor (În opozitie cu
testarea black-box descrisa mai sus). Pentru a efectua o astfel de testare, evaluatorul trebuie să
știe cum a fost făcut programul și să aiba experienta în programare. Testerii introduc elemente de
testare în cod care îi ajuta să determine dacă instrucțiunile s-au executat corect pânăîn punctele
introduse. Este similar cu testarea unui circuit electronic în care se masoara din loc în loc
parametrii pentru a evalua funcționarea corecta.
Se poate aplica la nivelul de unitate, de integrare și de sistem, dar cel mai des se
folosește la nivelul unității. Deși astfel se descopera multe erori și probleme, nu se
detectează partile neimplementate sau specificații și cerințe lipsa.
În categoria cutiei albe sunt incluse:
- Testarea fluxului de control
- Testarea cailor pe care le poate lua programul
- Testarea căii de date
- Testarea tratării corecte a erorilor
Testarea gray-box
Testarea prin metodă cutia cutiei gri presupune ca testerul să cunoască algoritmii
și structurile de date din interiorul programului, dar să testeze ca un utilizator (ca la
black-box). Nu are nevoie de acces la codurile sursa. Manipularea datelor de intrare și
de ieșire nu se califică în testarea gray-box, intrucât acestea se afla inafară sistemului
(cutiei), insa modificarea structurii de date se incadreaza în aceasta categorie, pentru
că, în mod normal, un utilizator nu ar putea schimba datele dinafara sistemului.
Testarea gray-box poate include și ingineria inversa pentru a determina, de pildă,
valorile maxime și mesajele de eroare.
Cunoscand conceptele din spatele produsului software, un tester poate face
alegeri mai bune și în cunostinta de cauza în ceea ce priveste tipurile de teste care
trebuie efectuate. În general, unui astfel de tester i se permite pregătirea unui mediu de
test propriu (de exemplu, sa adauge propriile date intr-o baza de date și apoi să creeze
propriile scripturi SQL pentru a vedea răspunsurile).

Tipuri de testare
Stilurile dominante de testare black box sunt:
 Testare functionala - se referă la cerințele funcționale ale aplicației și cuprinde faptul cît
de bine sistemul execută funcțiile sale. Acesta include comenzi de utilizare, manipulare
de date, căutări și procese de afaceri, integrări.
 Testare de manuala
 Testare de stress
 Testare de regresie - (black & white box) reprezintă procesul de re-testare dupa remedieri
sau modificări ale produsului sau ale mediului său.
Se numesc astfel testele executate după corectarea erorilor, pentru a se verifica dacă în cursul
corectării nu au fost introduse alte erori. Aceste teste sunt efectuate de regulă în timpul
întreţinerii. Pentru uşurarea lor este necesar să se arhiveze toate testele efectuate în timpul
dezvoltării programului, ceea ce permite, în plus, verificarea automată a rezultatelor testelor
regresive. Duce la automatizare.
 Testare de sistem - (black box) testarea completă a sistemului (echipă de testeri).
Acestea sunt teste ale sistemului de programe şi echipamente complet. Sistemul este instalat
şi apoi testat în mediul său real de funcţionare. Sunt teste de conformitate cu specificaţia
cerintelor de sistem (software) :
- teste functionale, prin care se verifica satisfacerea cerintelor functionale
- teste prin care se verifica satisfacerea cerintelor ne-functionale :
 de performanţă,
 de fiabilitate,
 de securitate, etc.
Adesea, testele de sistem ocupă cel mai mult timp din întreaga perioadă de testare.
 Testare de performanta
 Testare automata
 Determinarea cazurilor de test
Testarea unui modul, a unui subsistem sau chiar a întregului program presupune stabilirea unui
set de cazuri de test.
Un caz de test cuprinde:
- un set de date de intrare;
- funcţia / funcţiile exersate prin datele respective;
- rezultatele (datele de ieşire) aşteptate;
În principiu (teoretic) testarea ar trebui să fie exhaustivă, adică să asigure exersarea
tuturor căilor posibile din program. Adesea o astfel de testare este imposibilă, de aceea trebuie să
se opteze pentru anumite cazuri de test. Prin acestea trebuie să se verifice răspunsul programului
atât la intrări valide cât şi la intrări nevalide.
Sunt două metode de generare a cazurilor de test, care nu se exclud, de multe ori fiind
folosite împreună. Ambele metode pot sta la baza unor instrumente de generare automată a
datelor (cazurilor) de test:
1. Cazurile de test se determină pe baza specificaţiei componentei testate, fără cunoaşterea
realizării ei; acest tip de testare se numeşte testare “cutie neagra” (“black box”).
2. Cazurile de test se determină prin analiza codului componentei testate. Acest tip de
testare se mai numeşte şi testare “cutie transparentă”, sau testare structurală.
De ce testam?
- Ca sa gasim defecte!
- Pentru a reduce impactul defectelor aparute la client, pentru a
nu afecta costurile si profiturile ☺.
- Pentru a creste fiabilitatea sistemului.
- Pentru a creste calitatea produsului.
- Pentru a ne asigura ca un produs este conform cu cererile
clientilor.
Cand sa ne oprim din testare?
- Am acoperit ceea ce ne stabilisem.
- Rata de gasire a defectelor a scazut sub o rata stabilita.
- Echipele implicate in proiect cad de acord ca produsul poate fi
livrat.
- Managementul decide ca produsul sa fie livrat.

METODE DE TESTARE SI
CICLUL DE VIATA AL PRODUSELOR INFORMATICE (SOFTWARE)

Modelul ciclului de viață de dezvoltare de software este utilizat pentru managementul de

proiect și implică procese de analiza de fezabilitate pentru menținerea cererii completate.
Ciclul de viata al unui produs: perioada de timp intre momentul aparitiei cererii prin care se
solicita realizarea unui produs si momentul scoaterii lui din exploatare. Ciclul de realizare al unui
produs: partea din ciclul de viata al unui produs in cadrul careia se realizeaza respectivul produs.
Abordare structurata a notiunilor de testare, evaluare si validare are drept scop configurarea
finala a sitemului dezvoltat astfel incat acesta sa respecte cerinte si specificatiile initiale ale
clientului.
Pentru a indeplini acest obiectiv se vor detalia urmatoarele aspecte:
• determinarea criteriilor de testare, evaluare si validare a sistemelor;
• descrierea categoriilor de teste si evaluari implicate;
• planificarea testarilor si evaluarilor in cadrul duratei de dezvoltare a sistemului;
• pregatirea sistemului pentru testare si evaluare;
• efectuarea testelor, culegerea datelor de test, pregatirea raportului de evaluare;
• modificarea parametrilor sistemului in functie de concluziile raportului de
evaluare.

Metodologia Waterfall sau Cascada

Abordarea Cascada a fost primul model SDLC care urmează să fie utilizate pe scară largă în
Inginerie Software pentru a asigura calitatea si succesul proiectului.
În "Cascada" abordare, întregul proces de dezvoltare a software-ului este împărțit în faze
separate. În cazul modelului Cascada, de obicei, rezultatul uneia acte de fază ca intrare pentru
următoarea fază secvențial.

Cerința Colectarea și analiza (Requirement Gathering and analysis):

Toate cerințele posibile ale sistemului care urmează să fie dezvoltate sunt capturate în această
fază și documentate într-un document de specificație cerință.
Proiectarea sistemului (System Design):
 Specificațiile cerințelor din prima fază sunt studiate în această fază și este pregătit sistemului de
proiectarea. Sistemul de proiectare ajută la specificarea cerințelor hardware și de sistem și de
asemenea, ajută la definirea arhitecturii sistemului în ansamblu.
Implementarea (Implementation) :
Cu intrări de la proiectarea sistemului, sistemul este dezvoltat pentru prima oară în programe
mici, numite unități, care sunt integrate în faza următoare. Fiecare unitate este dezvoltat și testat
pentru funcționalitatea sa, care este menționată ca unitate de testare.
Integrarea și testarea ( Integration and testing):
Toate unitățile dezvoltate în faza de implementare sunt integrate într-un sistem după testarea
fiecărei unități. Integrarea post-întregul sistem este testat pentru orice defecte și eșecuri.
Implementarea sistemului (Deployment of system): Odată ce testarea funcțională și
nefuncțională se face, produsul este implementat în mediul de client sau eliberat în piață.
Întreținere ( Maintenance ): Există unele probleme care apar în mediul de client. Pentru a
remedia aceste probleme de patch-uri sunt eliberate. De asemenea, pentru a îmbunătăți produsul
unele versiuni mai bune sunt eliberate. Întreținere se face pentru a livra aceste schimbări în
mediul de client.
Folosind aceasta metodologie :
· Cerințele sunt foarte bine documentate, clare și fixe.
· Definirea produsului este stabilă.
· Tehnologia este înțeleasă și nu este dinamic.
· Nu există cerințe ambigue.
· Resurse ample cu expertiza necesară sunt disponibile pentru a susține produsul.
· Proiectul este scurt.

Pro-uri
· Simplu și ușor de înțeles și de utilizat
· Ușor de gestionat din cauza rigiditatea modelului. Fiecare fază are rezultate specifice și a unui
proces de revizuire.
· Fazele sunt prelucrate și completate unul la un moment dat.
· Funcționează bine pentru proiecte mai mici, în cazul în care cerințe sunt foarte bine înțelese.
· Etape bine definite si in mod clar inteles repere.
· Ușor de a aranja sarcini.
· Procesul și rezultatele sunt bine documentate.

Contra
· Nici un software de lucru se produce până târziu în timpul ciclului de viață.
· Nu este un bun model pentru proiecte complexe și orientate spre obiect.
· Modelul slab pentru proiecte lungi și în curs de desfășurare.
· Nu este potrivit pentru proiectele în care cerințele sunt la un risc moderat ridicat de schimbare.
· Este dificil să se măsoare progresele înregistrate în cadrul etapelor.
· Nu se poate acomoda schimbarea cerințelor.
· Ajustarea domeniului de aplicare în timpul ciclului de viață se poate termina un proiect.
 Modul iterativ
În modelul iterativ, proces iterativ începe cu o implementare simpla a unui set mic de cerințele
software și iterativ consolidează versiunile în evoluție până când sistemul complet este
implementat și gata pentru a fi utilizate.
Un model de ciclu de viață iterativ nu încearcă să înceapă cu o specificație de cerințe. In schimb,
dezvoltarea începe prin definirea și punerea în aplicare doar o parte a software-ului, care este
apoi revizuit în scopul de a identifica cerințe suplimentare. Acest procedeu este apoi repetat,
producând o nouă versiune a software-ului de la sfârșitul fiecărei iterație a modelului.

Metodologia Agile
Agile este metodologia de dezvoltare de software.
Un ghid organizational care sprijina un mediu in care exista sau pot exista prea multa schimbare.
Ca raspuns la schimbarea continua a mediului, Agile Software incurajeaza interactiunea si
colaborarea frecventa cu clientii, livrare constanta a produselor si serviciilor.
Agile Software Development este o familie de metodologii de project management în ingineria
software, bazată pe dezvoltarea incrementală și care îmbrățișează și promovează schimbările ce
evoluează de-a lungul întregului ciclu de viață al unui proiect. Aceste metodologii se
caracterizează prin divizarea problemei în subprobleme mici și planificarea lor pe durate scurte.
Se evită planificarea în detaliu pe termen lung, deoarece inerent în dezvoltarea de software apar
întârzieri frecvente din cauza schimbărilor și detalierii cerințelor clientului.
Este foarte eficient în cazul în care clientul își schimbă frecvent cerința lui.

Caracteristici cheie:
• Codul de proprietate colectivă și libertatea de schimbare.
• Abordarea incrementală (de exemplu, povești de utilizator sunt puse în aplicare treptat)
• De automatizare (de exemplu, TDD - Test de Driven Development).
• Orientarea spre client (de exemplu, internă și utilizatorii externi și analiști de afaceri sunt
clienții dumneavoastră imediate)
• Proiectarea trebuie să fie simplu. Proiectarea este o activitate în curs de desfășurare cu
constanta de re-factoring pentru a atinge regulile de cod simplitate ca nici o dublare, verificată
prin teste automate, separarea responsabilităților, precum și numărul minim de clase, metode și
linii.
Scopul principal este ca, la terminarea fiecărui ciclu de dezvoltare (denumit iterație, și a cărui
durată este de obicei ordinul câtorva săptămâni) să existe o versiune cât de cât funcțională (deși
incompletă) a software-ului dezvoltat (cu număr minim de buguri).

O altă caracteristică importantă este comunicarea frecventă între membrii echipei, care, în
multe cazuri, se întâlnesc într-o scurtă ședință zilnică, denumită stand-up sau scrum în care
fiecare prezintă pe scurt progresul său în ultima zi de lucru și problemele cu care s-a confruntat.
Acestora li se alătură și un reprezentant al clientului, care trebuie să fie informat de aspectele
dezvoltării, pentru a ști ce modificări este realist să ceară și cât de mult ar putea costa ele. Astfel,
toată lumea are cunoștințe despre fiecare aspect al dezvoltării aplicației și poate prelua munca
altuia sau ajuta pe altcineva.
 PROTOCOL INTERNET

Protocolul Internet sau IP este un protocol prin care datele sunt trimise de la un calculator la
altul prin intermediu Internetului. Fiecare calculator (cunoscut sub denumirea de „gazdă”), are pe
Internet cel puțin o adresă IP unică, care îl identifică între toate computerele din rețea. Când
cineva trimite sau primește informații (de ex.: poștă electronică, pagini web) mesajul este
împărțit în blocuri de mici dimensiuni denumite pachete. Fiecare pachet cuprinde adresa
expeditorului și pe cea a destinatarului. Fiecare pachet este trimis, prima dată la un calculator-
pasarelă, care înțelege o mică parte din internet.
Calculatorul pasarelă citește destinația pachetelor și trimite pachetele către o altă pasarelă, și
așa mai departe, până ce pachetul ajunge la pasarela vecină cu computerul destinatar.
Adresa IP este utilizată la nivelul programelor de prelucrare în rețea. În schimb, la nivelul
utilizatorilor cu acces la Internet, identificarea calculatoarelor se face printr-un nume de gazdă
gestionat de sistemul DNS.

Funcționare
Comunicația în Internet funcționează după cum urmează: nivelul transport preia șiruri de date
și le divide în datagrame. Teoretic, datagramele pot avea fiecare până la 64 KO, dar în practică
ele nu depășesc 1500 de octeți (pentru a intra într-un cadru Ethernet). Fiecare datagramă este
transmisă prin Internet, fiind eventual fragmentată în unități mai mici pe parcurs. Când toate
aceste „fragmente” ajung la mașina destinație ele sunt reasamblate de nivelul rețea în datagrama
originală. Datagrama este transparentă nivelului transport, care o inserează în șirul de intrare al
procesului receptor.
Cea mai mică adresă este 0.0.0.0, iar cea mai mare 255.255.255.255. Adresa IP 0.0.0.0 este
folosită de gazde atunci când sunt pornite. Adresele IP cu 0 ca număr de rețea se referă la rețeaua
curentă. Aceste adrese permit ca mașinile să acceseze propria rețea fără a cunoaște numărul de
rețea (dar trebuie cunoscută clasa rețelei pentru a ști câte zerouri trebuie introduse). Adresele
care constau numai din 1-uri permit difuzarea în rețeaua curentă, în mod uzual o rețea locală.
Toate adresele de forma 127.xx.yy.zz sunt rezervate pentru testări în buclă locală. Pachetele
trimise către această adresă nu sunt trimise prin cablu ele sunt prelucrate local și tratate ca
pachete sosite.
O datagramă IP (un pachet) constă dintr-o parte de antet și o parte de text. Antetul are o parte
fixă de 20 octeți și o parte opțională de lungime variabilă.
Fiecare gazdă și ruter din internet are o adresă IP, care codifică adresa sa de rețea și de gazdă.
Combinația este unică: în principiu nu există două mașini cu aceeași adresă IP. Toate adresele IP
sunt de 32 biți și sunt folosite în câmpurile „Adresă sursă” și „Adresă destinație” a pachetelor IP.
Este important de observat că o adresă IP nu se referă la o gazdă. Se referă, de fapt, la o interfață
de rețea. Cu alte cuvinte, dacă o gazdă este în două rețele, trebuie să folosească două adrese IP .
Rețelele sunt dinamice și este posibil ca 2 pachete IP de la aceeași sursă să plece pe căi
diferite (BGP – protocolul porților de graniță) și să ajungă la aceeași destinație. Pachetele IP
(dupa cum s-a mai spus) nu au garanția că vor ajunge la destinație, acest lucru fiind lăsat în
seama protocoalelor adiacente (TCP UDP etc).

REALIZAREA UNUI CASE TEST SOFTWARE

Pentru testarea unui produs trebuie realizată o secvență de activitate de testare.

Automatizarea testării
Scopul testării automate este de a minimiza cantitatea de muncă manuală în executara testului
și acoperirea unei game mai mari de valori pentru a face testul prin aplicarea unui număr mai
mare de teste. Testara automată are un impact major asupra metodelor de testare concepute și al
uneltelor folosite pentru testare. Prin testarea automată se detectează blocările programelor și
operațiile curente oferind informații de diagnosticare.
Un model de testare poate fi reprezentat astfel:
PREZENTAREA PLATFORMEI KINDERUNITY

In cadrul companiei am ocupat functia de QA tester. Pe parcursul desfasurarii stagiului de

practica am testat platforma Kinderunity aplicand metodele de testare invatate.
Platforma Kinderunity a pornit de la ideea parintilor de a fi informati despre copilul lor atunci
cand este la gradinita si din dorinta de a consolida procesul educational din gradinita.
Kinderunity este platforma online care faciliteaza comunicarea dintre parinti, copii si educatori ,
oferind un set complet de imstrumente pentru a construi cea mai buna experienta in primii ani de
viata ai copilului.
Parintii au o imagine completa asupra nutritieicopilului putand sa ofere recomandari specifice si
detaliate precum : alergii alimentare sau preferinte culinare, optiunea fiind accesibila prin
modulul Nutritional.
Kinderunity este o platforma creata din mai multe modele.
Deschiderea de defecte este activitatea principala a unui tester. Programul pe care l-am folosit
pentru a deschide defecte a fost JIRA.
EXEMPLU DE SCENARIU DE TESTARE

Scenariu
I- CREEAZĂ PROGRAM

1. Intră în contul dvs. - org kinderunity

2. Du-te la:
- Pagina de pornire kinderunity și adăugați noul program
SAU
- My kindergarden - Administrare - Programe și adăugați noul program

3. completeaza toate zonele din formular în special cele obligatorii

4. Verificați dacă introduceți datele corect, apoi salvați

EXEMPLU DE POZE CU DEFECTE DIN APLICATIE

Apare la accesarea setarilor din administratie

Meniurile se duplica la modificarea acestora din planificare masa
Pozele din album nu sunt incarcate

Eroare la invoirea copilului

Pagina nu se incarca cum trebuie

Eroarea apare la citirea notificarii primite pentru un pinboard nou

In statistici lista copiilor nu se incarca
PORTOFOLIUL DE PRACTICA - 2016

Student: SIMION EMANUELA DANIELA

Grupa : 632 CB
Facultatea si specializarea: IMST /IMC