Contribuii

Cercetarea descris n aceast lucrare a fost realizat prin

intermediul studiilor de caz care extind corpul empirice de
dovezi privind executia software i dezvoltarea n lumea real ,
combinat cu o literatur sistematic. Evidena dificultilor
intalnite pe parcursul testul de automatizare a fost inclusa in
analiza sistematica. In continuare avem principalele rezultate:
1. S-a efectuat o list complet in privinta potenialelor
impedimente raportate legat de automatizare de executie de
testare. De asemenea, s-a efectuat o analiz aprofundat a
modului n care astfel de impedimente sunt formate i cum pot
ele afecta performana unei dezvoltri in cadrul echipei.
2. O propunere pentru un model calitativ de interaciuni ntre
principalele grupuri de fenomene care contribuie la formarea
unor impedimente ntr-un proiect de automatizare de executie de
testare.
Aditional, s-au adus contributii si cu date empirice cantitative si
calitative din cadrul cazurilor industrial. Aceste date au fost
folosite ca un suport in ceea ce priveste anliza de fata dar pot fi
de folos si in viitoarele cercetari. In orice caz continutul
raportului este relatic mic si pe viitor va fi nevoie de o cercetare
mai amanuntita.

Raspunsuri la intrebarile de cercetare.

O prima intrebare a facut referire la tipul de obstacole care au
fost intalnite de software-ul organizatiilor de dezvoltare a
utilizarii unui test de automatizare si executie.
Acestea au fost impartite pe mai multe categorii precum:
impiedimente organizationale(planificare, comunicare,
aptitudini) si impiedimente in privinta testarii sistemului.
Au fost studiate si cauzele acestor impiedimente care se
datoreaza lipsei de intelegere in comportamentul automatizarii
unui proiect din punct de vedere tehnic si social. Testele de
automatizare de execuie depinde de stabilitate i structura n
testare. Nu vom putea avea un rezultat sadisfacator daca testarea
in general este nestructurata.
Contributiile din studiile de caz industrial
n timpul cercetrii descrise n aceast tez, a fost studiat
software-ul industrial de dezvoltare n trei uniti organiza ionale
diferite pentru a investiga ce problem i impedimente au fost
ntlnite de catre dezvoltatorii de software care utilizeaz
automat instrumente de testare. De la fiecare studiu empiric,
urmtoarele contribuii sunt:
datoria tehnic in test de automatizare: se refera o
investigaie cu
privire la experienele de dezvoltatori care i-au asumat
responsabilitatea pentru testarea de integrare a acestora, produs
ca parte a unui sistem mai mare.

 impedimente in Agile Software Development

contribuiile principale ale acestui studiu sunt: o
investigaie empiric pe ipoteze, discuie cu privire la
motivele i posibilele remedii pentru fenomenele observate
si informaii cantitative despre distribuia de lucru
impedimente in testarea automata: o privire de ansamblu a
problemelor avute de catre dezoltatori si prea putine
informatii disponibile despre experientele cu lumea reala, o
discutie in legatura cu problemele intampinate in cadrul
cercetarii anterioare.
Studiu de caz industrial: Impedimente in testarea
software-ului Agile
In urma cu aproximativ 3 luni inainte de acest studiu, o
transformare a organizatiei a fost initiate pentru a face trecerea
de la o ierarhie traditionala catre un mod mai agil. Obiectivul
studiului este de a aduna informaii despre proporiile dintre
diferite tipuri de munc. Datele au fost colectate din mai multe
surse si prin mai multe metode.
Observatii:
1. " RCA Light" - analiza investigaiilor impediment
existente. Cercetatorul principal a participat n calitate
de observator ntr-un atelier cu toate echipele din cadrul
departamentului , cu scopul pentru a identifica
impedimentele de top pentru progresul punerii n
aplicare i calitatea produsului. Informatiile au fost
colectate ca note scrise .

2. Supraveghierea directa a intalnirilor Scrum echipei A.

Se organizeaza intalniri zilnice pentru a inregistra
progresul si problemele care au fost observate cu
permisiunea echipei
Scopul sarcinii consiliului Scrum este de a vizualiza
ntrzierile sprint ntr-un mod util. Acesta ofer o ntotdeauna
dispozitie o reprezentare a stadiului actual al sprint , ceea ce este
progresul , la ceea ce se lucreaza, care sunt problemele i ceea ce
nu se face.
Consiliul de sarcin este elementul central n cadrul
reuniunilor Scrum , i discuiile sunt centrate pe modul n care s
se mute sarcinile la finalizare.
Imbunatatirea sarcinii de bord: in cazul n care echipa nu este n
msur s rezolve un impediment sau dac soluia problemei
este de ateptat s fie de un fel de interes general, se va obtine
ajutor echipa extern . Impedimentele generate vor fi utile pentru
imbunatatirea activitatii si astfel se vor colecta informatii pentru
diferite parti ale procesului si fluxului de lucru in cadrul
organizatiei.
Managementul bord Sarcina Echipa : Echipa de
management ( MT ) bord
conine elemente care echipa de management efectueaz ca parte
a de zi cu zi a acestora
munc. Am folosit aceste informaii pentru a analiza ceea ce
tipuri de obstacole
i mbuntiri necesare atenia conducerii

Clasificarea datelor
RUP(Rational Unified Process) a definit 6 principii ingineresti:
modelul de business
cerinte
analiza si design
implementare
test
desfasurare
Rezultate
Pentru a obine o perspectiv legat de munca realizata de catre
echipe si ce impedimente sunt de rezolvat, au fost colectate
informaii de la consiliului de mbuntire , precum i de la
echipa de management ( MT )
Validare
Construirea validarii se adreseaza studiilor masoara ce se
doreste sa se masoare.
Cea mai mare ameninare la adresa construirii valabilitatii in
acest studiu este folosind numrul de sarcini de mbuntire
pentru fiecare disciplin pentru a estima cantitatea i tipul de
obstacole ntlnite .
Validare interna a concluziilor studiului. S-au folosit mai
multe surse de informatii cantitative si calitative pentru a
minimiza amenintarea la adresa interna. Una dintre principalele
amenintari este referitoare la intervalul de timp al studiului.
Validare externa se adreseaza generalizarii concluziilor.

Fiabilitatea abordeaza repetabilitatea studiului.

Clasificarea datelor, principiile sunt bine definite , i se bazeaz
pe RUP , care este cunoscut i utilizat pe scar larg.
Concluzii:
Contrar ipotezelor iniiale n infrastructura de organizare , de
testare i de re-testare impedimente nu constituie majoritatea
impedimentele ntlnite. Acestea tin mai mult de organizare,
coordonare si comunicare. O mare parte din impedimentele de
infrastructur de ncercare ar fi putut fi evitate prin definirea
mprirea responsabilitii ntre infrastructura, organiza ie i
dezvoltare mai devreme , de asemenea, de numire a persoanelor
de contact ntre organizaiile .