Differences
This shows you the differences between two versions of the page.
|
mps:laboratoare:laborator-10 [2018/11/26 13:38] iulia.stanica |
mps:laboratoare:laborator-10 [2023/01/10 13:30] (current) iulia.stanica [Exercitiul 1 (10 minute)] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Laborator 10 - Testarea si asigurarea calitatii unui proiect ====== | + | ====== Laborator 10 - Conducere, motivare, inteligență emoțională ====== |
| + | ====== Ce inseamna "conducere"? ====== | ||
| + | Actul conducerii ("leadership" sau "management") poate fi definit cel mai bine prin scopul său. Două definiții edificatoare: | ||
| - | ==== Termeni ==== | + | "Leadershipul înseamnă crearea unui context prin care un grup de oameni pot contribui la înfăptuirea de lucruri extraordinare." - // Alan Keith // |
| - | **Bug** - O problemă, eroare, defect, posibilitate nedocumentată, greșeală într-un sistem software care împiedică sistemul să funcționeze așa cum este de așteptat este un bug. | + | "Leadershipul este capacitatea de a agrega resursele disponibile cu mediul intern și extern în scopul de a atinge obiectivele organizației - sau ale societății." - // Ken Ogbonnia // |
| - | **Bug report** - Un raport care detaliază un bug într-un program, adică cum se manifestă, când, care parte a codului este responsabilă, eventual și o soluție posibilă. | + | Contrar părerii generale, actul conducerii NU înseamnă putere, cât mai ales RĂSPUNDERE. Primul lucru pe care trebuie să îl înțeleagă un lider este ca el poartă răspunderea întregii organizații subordonate, respectiv că eșecul unui membru al organizației este deopotrivă un eșec al conducerii organizației. //Demonstrație: întrucât leadershipul presupune crearea contextului în care poate fi atins un obiectiv, rezultă că succesul sau eșecul în atingerea obiectivului nu pot fi niciodată desprinse de actul conducerii.// |
| - | **Bug tracking** - Bug tracking-ul este un mod organizat de a ține evidența bugurilor și a stărilor acestora (deschis, rezolvat, testat, închis). Acesta poate varia de la forme neorganizate (întâlniri în echipă) la forme organizate (liste de discuții, mail-uri, soluții specializate). | + | În același timp, responsabilitatea NU trebuie confundată cu implicarea directă, respectiv cu imixtiunea nemijlocită! //Actul conducerii nu presupune schimbarea unui bec sau spălarea cu mopul, ci definirea organizației, a proceselor și a resurselor astfel încât schimbarea unui bec sau spălarea cu mopul să se întâmple în mod firesc. :-)// |
| - | **Sistem de bug tracking** - O aplicație software care are ca rol ușurarea bug tracking-ului (este o metodă eficientă centralizată și ușor utilizabilă.) Există soluții gratuite, dar și soluții enterprise cu prețuri foarte ridicate. Un sistem de bug tracking este un subtip de sistem de issue tracking. | + | Al doilea punct esențial este complementar primului: anume, actul conducerii trebuie să fie ADAPTIV. Nu există rețete universale sau șabloane, ci doar principii și direcții. //Actul conducerii înseamnă construcție inteligentă și nu aplicare.// |
| - | **Sistem de issue tracking** - O aplicație software care are ca rol centralizarea și adresarea tuturor cererilor legate de unul sau mai multe produse, de la probleme la schimbări de design și aplicări de patch-uri. Cele mai multe sunt în același timp și bug trackere. În general, sunt mai complexe decât bug trackerele. | ||
| - | **Patch** - O mică bucată de software creată spre a rezolva problemele și a îmbunătăți performanțele unui program. Aceasta include, dar nu este limitata la: repararea de bug-uri, creșterea vitezei, îmbunătățirea graficii. Unele patch-uri creează și probleme noi. | + | ====== Fundamentele actului de conducere ====== |
| - | **Patch management** - Procesul de a stabili o strategie și a plănui ce patch-uri să fie aplicate, la ce sisteme și când este momentul potrivit pentru aplicarea lor. | + | La baza actului de conducere trebuie să stea în permanență scopul final, respectiv crearea acelui context "câștigător". Crearea și menținerea unui asemenea context se desfășoară simultan pe mai multe planuri. Ele nu trebuie înțelese în sens strict, ci interdependente, cu ponderi flexibile și aplicate în mod adaptiv: |
| + | * **Planificare**: definirea obiectivelor și calendarului, ce trebuie să se întâmple și când | ||
| + | * **Organizare**: definirea organizației, repartizarea și gestiunea resurselor disponibile | ||
| + | * **Coordonare/Directionare**: direcționarea organizației către atingerea obiectivelor | ||
| + | * **Control**: monitorizarea proiectului în concordanță cu planurile | ||
| + | * **Motivare**: mobilizarea membrilor echipei către atingerea obiectivelor | ||
| + | {{:mps:laboratoare:management-functions.gif|}} | ||
| - | ==== Aplicații === | + | * Sursa: http://www.cognitive-technologies.com/ |
| - | === GitHub === | + | |
| - | Așa cum a fost descris în cadrul laboratorului 4, [[https://github.com/|GitHub]] permite și un management al bug-urilor. | + | |
| - | === Redmine === | + | Se spune că un leadership (sau management) bun este invizibil deoarece creează iluzia că lucrurile merg spontan, firesc, "de la sine". Consecințele unui leadership de calitate: |
| - | [[http://www.redmine.org|Redmine]] este un tool complex, care oferă și suport pentru bug tracking. | + | |
| - | Prin secțiunea "New issue" se pot publica bug-uri, iar aceastea pot fi urmărite. | + | |
| - | === Bugzilla === | + | * succese ale organizației |
| - | [[http://www.bugzilla.org/about/|Bugzilla]] este unul dintre cele mai populare sisteme de urmărire a bug-urilor având o multitudine de [[http://www.bugzilla.org/features|functionalitati]]. | + | * personal motivat |
| + | * procese eficiente | ||
| + | * mediu de lucru plăcut | ||
| + | * obiective clare pentru fiecare și în armonie cu ale celorlalți membri | ||
| - | === Trac === | + | Semnele unui leadership slab: |
| - | [[http://trac.edgewall.org/|Trac]] nu este atât de sofisticat ca Bugzilla în ce privește urmărirea bugurilor (adică bug tracking), dar oferă mult mai multe alte facilități precum un navigator de Subversion și un wiki, deci o platformă completă de colaborare între utilizatori și dezvoltatori. De asemenea Trac poate fi extins ușor prin intermediul [[http://trac.edgewall.org/wiki/TracPlugins|modulelor]], unul dintre cele mai populare fiind cel pentru code review. | + | |
| - | === Debian bug tracking software === | + | * nesiguranța sau amânarea deciziilor dincolo de o limită rezonabilă |
| - | Fiecare bug are o adresă de mail distinctă. Comentariile și controlul bug-urilor se face cu emailuri tipizate. | + | * nemulțumiri și/sau frustrări în rândul personalului |
| + | * efort și stres percepute ca prea mari în raport cu realizările | ||
| + | * lipsa de eficiență a grupului în ansamblu | ||
| + | * divergența de obiective între persoane/echipe/departamente diferite | ||
| + | * eșec repetat în atingerea obiectivelor | ||
| - | === Launchpad === | ||
| - | [[https://launchpad.net|Launchpad]] este o aplicație web și un site pentru publicarea proiectelor software (în special cele open source). Printre multe alte facilități interesante dispune și de [[https://launchpad.net/+tour/bugs|bug-tracking]]. | ||
| - | Launchpad poate centraliza rapoartele bugurile din mai multe surse independente și oferă posibilitatea dezvoltatorilor de a discuta despre acel bug într-un singur loc. Launchpad se integrază bine cu trackere externe: Bugzilla, Trac, Sourceforge, Roundup, Mantis, RT și Debian BTS. Launchpad încearcă să elimine patchurile scrise în comentarii prin oferirea posibilității de publicare a unei ramure de cod (branches). | + | ==== "Management" vs "Leadership" ==== |
| - | Bugurile pot fi urmărite prin email și atom feeds, fiecare bug având asociată o adresa de email (ex: 249177@bugs.launchpad.net). | + | |
| + | Ambii termeni desemnează actul de conducere, însă termenul "leadership" s-a desprins odată cu lucrarea lui J. M. Burns ("Leadership", 1978) ca un stil de conducere axat pe interacțiunea umană (comunicare-direcționare-motivare) și mai puțin pe "tranzacții" impersonale (control-stimulare-penalizare). Folosind o metaforă, managementul este "știința" care creează organizații funcționale și eficiente, iar leadershipul este un adaos de interacțiune umană care poate aduce în plus entuziasm. :-) | ||
| - | ==== Patch-uri ==== | + | Obiectivul acestui laborator va fi leadershipul. |
| - | Un fișier patch e un fișier text care descrie diferențele dintre două versiuni ale unui fișier sau dintre două fișiere distincte. Există două formate standard pentru astfel de fișiere: tipul normal și context copiat. | ||
| - | Mai jos este prezentat un format îmbunătățit, **Context unificat**, care este cel mai întâlnit și mai ușor de vizualizat format. | ||
| - | Structura unui fișier patch cu context unificat: | + | ==== Leadership: cum? ==== |
| - | <code> | + | Leadershipul înseamnă direcționare și motivare. Nu vom discuta aici partea "tehnică" de planificare, construcție și control ale unei organizații, ci doar funcționarea ei optimă în condițiile unei structuri fixe. |
| - | --- original_file_name comentarii (ștampilă de timp, versiunea fișierului în svn/git/etc., etc.) | + | |
| - | +++ modified_file_name comentarii (idem) | + | |
| - | @@ -start_line__original_file,nr_lines__original_file +start_line__modified_file,nr_lines__modified_file @@ | + | |
| - | context_line_before_1 | + | |
| - | context_line_before_2 | + | |
| - | ... | + | |
| - | context_line_before_n | + | |
| - | - original_line_1 | + | |
| - | - original_line_2 | + | |
| - | ... | + | |
| - | - original_line_m | + | |
| - | + modified_line_1 | + | |
| - | + modified_line_2 | + | |
| - | ... | + | |
| - | + modified_line_p | + | |
| - | context_line_after_1 | + | |
| - | context_line_after_2 | + | |
| - | ... | + | |
| - | context_line_after_n | + | |
| - | </code> | + | |
| - | Exemplu de fișier patch cu context unificat: | + | Gândiți membrii unei organizații ca număr de vectori (forțe) cu origini fixe (posturile în cadrul organizației) însă cu direcții și module variabile în timp (oamenii). Pentru ca rezultanta să fie maximă în aceste condiții, este nevoie de două lucruri: |
| + | * vectorii să aibă direcții și sensuri cât mai apropiate | ||
| + | * variația vectorilor să fie coerentă (respectiv maximele să se suprapună cât mai mult iar minimele cât mai puțin) | ||
| - | <code> | + | Direcția și sensul înseamnă că membrii organizației împart un set comun de obiective. Variația vectorilor reprezintă evoluția în timp a motivării, a direcției, a efortului depus. În aceste condiții, leadershipul presupune următorul //checklist//: |
| - | --- v1.c 2008-11-18 02:34:38.000000000 +0200 | + | |
| - | +++ v2.c 2008-11-18 02:38:14.000000000 +0200 | + | |
| - | @@ -261,8 +261,18 @@ | + | |
| - | if (build_key(argv[1])) | + | |
| - | return 2; | + | |
| - | + | ||
| - | - display("original message: [%s]\n", msg, blocks); | + | |
| - | - | + | |
| - | + //display("original message: [%s]\n", msg, blocks); | + | |
| - | + if (blocks) | + | |
| - | + { | + | |
| - | + char c; | + | |
| - | + char * fmt = "original message: [%s]\n"; | + | |
| - | + int len = blocks; | + | |
| - | + c = msg[len-1]; | + | |
| - | + if (c == 'X') | + | |
| - | + msg[len-1] = '\0'; | + | |
| - | + printf(fmt, msg); | + | |
| - | + msg[len-1] = c; | + | |
| - | + } | + | |
| - | + | ||
| - | apply(msg, blocks, normalize); | + | |
| - | encrypt((unsigned short*) msg, blocks/2); | + | |
| - | </code> | + | |
| - | ==== Creare patch ==== | + | Definirea unor **obiective** "SMART" ale grupului: |
| + | * **Specific** – obiectivele trebuie să fie clare | ||
| + | * **Measurable** – trebuie să existe o metrică de măsurare a gradului de atingere a obiectivelor | ||
| + | * **Achievable** – sunt obiectivele tangibile în mod absolut? | ||
| + | * **Realistic** – sunt obiectivele tangibile cu resursele disponibile? | ||
| + | * **Time-based** – în ce interval de timp trebuie atinse? | ||
| - | === diff === | + | * comunicarea acestor obiective membrilor grupului |
| + | * definirea unui context comun (sistem valoric, terminologie, etc) împărtășit de toți membrii grupului | ||
| + | * transmiterea informației adecvate și într-un mod neechivoc | ||
| + | * **translatarea** obiectivelor organizației în obiective individuale ale membrilor grupului | ||
| + | * înțelegerea aptitudinilor și slăbiciunilor membrilor grupului în mod individual | ||
| + | * identificarea rolurilor potrivite/nepotrivite pentru fiecare | ||
| + | * derivarea unor obiective individuale (de asemenea SMART) in concordanta cu obiectivele organizatiei | ||
| + | * definirea unor metrici pentru gradul de atingere a acestor obiective | ||
| + | * translatarea obiectivelor individuale în **beneficii** individuale | ||
| + | * cunoașterea membrilor grupului, înțelegerea nevoilor/dorințelor/problemelor fiecăruia | ||
| + | * definirea beneficiului adecvat fiecăruia, respectiv a resortului care îl determină să acționeze pentru îndeplinirea obiectivelor sale individuale | ||
| + | * definirea regulii de corelare a atingerii obiectivului cu obținerea beneficiului individual | ||
| + | * monitorizare | ||
| + | * detectarea și măsurarea abaterilor de la obiectivul global | ||
| + | * translatarea acestora în abateri de la obiectivele individuale | ||
| + | * înțelegerea cauzelor care au condus la acestea | ||
| + | * corectarea cauzelor: | ||
| + | * medierea conflictelor | ||
| + | * clarificarea neînțelegerilor | ||
| + | * dacă este cazul, redefinirea obiectivelor și beneficiilor individuale | ||
| - | '''''diff''''' e un program cu care se pot crea fișiere de tip patch având la dispoziție fișierul original și fișierul modificat. ''diff'' poate crea fișiere patch în oricare din cele trei formate standard: | + | //În mod simplist, obiectivul organizației poate fi "livrarea proiectului, fără buguri, la termen", un obiectiv individual poate fi "layerul de acces la baza de date până la milestone-ul X" iar beneficiul individual poate fi "nota 10" sau "salariul Y". Această abordare asimilează însă (naiv) oamenii cu automate deterministe, neglijând faptul că indivizii sunt de fapt animați de resorturi interioare mult mai profunde, complexe și adeseori iraționale.// |
| - | * **normal** | + | |
| - | <code> | + | |
| - | diff origial_filename modified_filename | + | |
| - | </code> | + | |
| - | * **context unificat** | + | |
| - | pentru a crea un fișier patch cu un număr implicit de linii de context ''unificat'': | + | |
| - | <code> | + | |
| - | diff -u origial_filename modified_filename | + | |
| - | </code> | + | |
| - | pentru a crea un fișier patch cu x linii de context ''unificat'': | + | |
| - | <code> | + | |
| - | diff -Ux origial_filename modified_filename | + | |
| - | </code> | + | |
| - | === git format-patch === | ||
| - | ''git'' poate genera fișiere de patch care descriu diferențele între două commit-uri. | ||
| - | Implicit ''git format-patch'' crează un fișier diff în format unificat (cel mai răspândit format în lumea open-source) și îl scrie la stdout. Pentru a-l scrie într-un fișier pe disc, trebuie redirectată ieșirea către un fișier:<code> | ||
| - | git format-patch [optional parameters] > file.patch | ||
| - | </code> | ||
| + | ==== Motivare ==== | ||
| + | //Motivația// este un sinonim pentru energia mentală pe care este dispus un individ să o investească în atingerea unui scop. **Motivarea** înseamnă "energizarea" unui individ în vederea unui obiectiv //(observați faptul ca definiția subînțelege un factor extern individului)//. | ||
| - | === Utilizare patch === | + | Orice acțiune din partea unui individ presupune o anumită energie mentală: |
| + | //ex. deplasarea către un anumit loc.// | ||
| - | Un fișier ''patch'' nu este folosit doar pentru a vizualiza diferențele între două versiuni ale unor fișiere, ci și pentru a transmite un anumit set de modificări de la un utilizator la altul pentru a fi aplicate. | + | Uneori, această energie apare în mod spontan, **intrinsec**: |
| + | //ex. atunci când locul este camera prietenului/prietenei. :-)// | ||
| - | Utilitarul standard cu care se aplică patch-uri se numește ''patch''. | + | Alteori, energia nu este disponibilă în mod spontan, ci doar **extrinsec**, respectiv are nevoie de un aport extern: |
| + | //ex. atunci când trebuie să vă deplasați exact aceeași distanță, cu același efort, dar pentru a veni la facultate.// | ||
| - | Modul cel mai întâlnit de utilizare este:<code> | + | Într-un mediu profesional: |
| - | patch -pNUM < filename.patch | + | * indivizii motivați caută întotdeauna metode tot mai bune de a-și îndeplini obiectivele |
| - | </code> | + | * indivizii motivați sunt mai orientați către calitate |
| + | * indivizii motivați sunt mai productivi | ||
| - | ''patch'' își ia fișierul din stdin, de aceea trebuie redirectat fișierul de intrare. | + | Conform cu teoria clasică a lui Maslow (//A Theory of Human Motivation//), energia investită de un individ este alocată conform unei piramide de nevoi ale individului. La baza acestei piramide stau nevoile primare, fiziologice: hrana, respirația, etc. Pe nivelele superioare stau securitatea, apoi relaționarea cu apropiații (familia, etc), s.a.m.d. Individul nu va investi energie pentru un nivel superior al piramidei dacă nevoile de pe nivelele inferioare nu sunt satisfăcute. Lipsa de împlinire a nevoilor de pe nivelul inferior dă manifestări fiziologice. Lipsa de împlinire a nevoilor de pe celelalte nivele dă manifestari psihologice: nervozitate, oboseală psihică, anxietate, etc. Însă, odată nevoile de pe un nivel satisfăcute, individul își va concentra în mod constant energia pe nivelul superior, fără a mai "reinvesti" în nivelele inferioare altfel decât în mod temporar, atunci când este nevoit. |
| - | În fișierul ''filename.patch'', ''diff'' sau ''git format-patch'' va scrie și numele fișierelor pe care le-a comparat și din conținutul cărora a extras diferențele. E posibil ca ''diff'' sau ''git format-patch'' să fie rulate într-un alt director față de cel în care se va rula ''patch''. Cu opțiunea ''-pNUM'' se specifică numărul de nivele din calea specificată în fișierul ''filename.patch'' care vor fi ignorate când se va încerca să se determine. | + | {{:mps:laboratoare:maslow.png|}} |
| - | De asemenea, un patch poate fi aplicat cu comanda: <code>git am filename.patch</code> | + | **Motivarea poate fi gandită ca un joc de echilibristică între //amenințarea cu neîmplinirea// și //promisiunea împlinirii// acestor nevoi.** |
| - | ==== Test Cases ==== | + | Din start, motivarea prin amenințarea cu neîmplinirea este limitată în timp: individul se adaptează (caz în care ea nu mai are efect) sau renunță (efect contrar celui dorit). În plus, ea crește gradul de stres, ceea ce e contraproductiv. Din contra, motivarea prin promisiunea împlinirii este eficientă, are grad mai mic de stres și aplicabilitate de durată. |
| - | Pentru o testare de calitate, este important să existe o planificare riguroasă a testării încă din faza de proiectare sau development. Pe măsură ce se conturează definițiile modulelor, entităților de date, obiectelor, claselor, funcțiilor, etc. este recomandabil să se scrie și "scenarii" de testare ale acestora, fie //top-down//, fie //bottom-up//. | ||
| - | În industria software, "scenariile" de test se numesc **test cases**. | + | ==== Banii ==== |
| - | Un exemplu de test case: | + | Banii impactează nivelurile inferioare ale piramidei lui Maslow, deci sunt un factor puternic de motivare - însă nu unul de durată. Nivelurile superioare (//respectul de sine// și //atingerea potențialului maxim//) dau o motivație mai puternică și pe termen mai lung. |
| - | trebuie verificată funcționarea unei pagini de login care conține un input de user name și unul de parolă | ||
| - | * click pe "Login" fără a completa user/pass -> trebuie să rămân în pagină și să se afișeze un mesaj de eroare | ||
| - | * completat user corect, parola incorectă sau nulă, click pe "Login" -> trebuie să rămân în pagină și să se afișeze un mesaj de eroare | ||
| - | * completat user corect, parola corectă, click pe "Login" -> trebuie să fiu corect autentificat | ||
| - | * completat user corect, parola corectă, tastat "Enter" -> trebuie să fiu corect autentificat | ||
| - | Există "testare pozitivă" și "testare negativă", concretizată în **positive test cases** și **negative test cases**. Testarea pozitiva înseamnă //verificarea faptului că sistemul face ceea ce trebuie să facă//. Testarea negativă înseamnă verificarea faptului că sistemul //nu face ceea ce nu trebuie să facă//. | + | ==== Respectul de sine ==== |
| - | Pe cazul anterior: | + | Nivelul respectului de sine reunește generic nevoile de **posesie** în două subniveluri: |
| - | * testare pozitivă: se verifică faptul că la user/pass corecte se face login iar la user/pass incorecte se afișează un mesaj de eroare | + | |
| - | * testare negativă: se verifică faptul că la user/pass corecte NU se afișează un mesaj de eroare iar la user/pass incorecte NU se face login și NU se "sparge" sistemul | + | |
| - | În principiu, cele două approachuri sunt echivalente, însă în practică testarea pozitivă se referă la funcționarea "normală" a sistemului, iar testarea negativă la "corner cases". De exemplu, pentru testarea unui feature critic ca time to market dar non-critic ca și calitate (ex. twitter), se va prefera testarea pozitivă, care asigură că sistemul funcționează corect pentru cei mai mulți utilizatori. Pentru testarea unui feature critic ca și calitate (ex. online banking) se va insista pe teste negative, ex. se va încerca "spargerea" sistemului prin combinații incorecte. | + | - subnivelul inferior: |
| + | * statut | ||
| + | * recunoaștere/faimă/prestigiu | ||
| + | * atenție | ||
| + | - subnivelul superior: | ||
| + | * putere | ||
| + | * competență | ||
| + | * încredere în sine | ||
| + | * independență | ||
| + | * libertate | ||
| - | Există, ca în orice alt domeniu, tool-uri open source pentru managementul test cases: | + | Exercițiu (colectiv): //enumerați elemente care pot crește motivarea individului la nivelurile de mai sus.// |
| - | * Bugzilla Testopia: http://www.mozilla.org/projects/testopia/ | + | Multe elemente simple pot crește motivarea individului la aceste niveluri: |
| - | * Incremental Scenario Testing: https://sourceforge.net/projects/istt/ | + | |
| - | * QA Traq: http://www.testmanagement.com/ | + | |
| - | === Black Box Testing === | + | * nomenclatura postului :-) |
| + | * //administration associate// sau //administrator adjunct//? | ||
| + | * //documentation specialist// sau //inginer documentare//? | ||
| + | * //security expert// sau //inginer însărcinat cu securitatea//? | ||
| + | * poziția de conducere //("a fi șef")// | ||
| + | * recunoașterea publică a meritelor sale în cadrul organizației | ||
| + | * recunoașterea importanței și/sau dificultății sarcinilor care îi sunt atribuite | ||
| + | * libertatea de a lua decizii în cadrul atribuțiilor sale | ||
| + | * delegarea unor responsabilități importante | ||
| + | * arătarea respectului și atenției față de el | ||
| + | * //deschiderea de a asculta problemele sale// | ||
| + | * //posibilitatea de a discuta direct, de la egal la egal, cu managementul de pe nivele superioare// | ||
| + | * //tonul amabil al comunicației// | ||
| + | * //sarcinile exprimate în mod prietenos și nu imperativ// | ||
| - | Se aplică în cazul în care pentru programul ce trebuie testat sursele nu sunt disponibile, ci doar interfața de acces (binarul, o interfața implementată de clasa testată, etc). | + | Alte elemente motivaționale de pe acest nivel pot apela la psihologia inversa. Anume, deși individul are o performanță bună, poate primi un feedback ușor negativ care îi poate afecta imaginea de sine -- ceea ce îl va împinge să încerce să compenseze acest lucru prin eforturi suplimentare de a se afirma prin ceea ce face. Astfel, individului i se poate spune că: |
| - | Cum se testează: | + | |
| - | Se aplică un set de intrări, iar ieșirile sunt comparate cu un set de ieșiri corecte. | + | |
| - | * Intrări - un set de intrări ce vor fi trimise programului pentru execuție. Intrările nu trebuie neapărat să fie niște fișiere ci pot fi niște apeluri de funcții sau un alt program ce simulează alte module ce interacționază cu programul testat. | + | |
| - | * Ieșiri - pentru fiecare intrare se definește un set de ieșiri posibile cu care se testează ieșirea programului. În multe din cazuri ieșirea e deterministică și trebuie doar comparate ieșirea programului cu ieșirea așteptă, iar în alte cazuri este necesară scrierea unui program. | + | |
| - | //Exemplu// | + | * nu face destule eforturi |
| - | Testarea unui program care la intrare primește un string pe care vrea să îl parseze în | + | * nu e destul de creativ |
| - | * număr întreg | + | * colegii nu au atâtea nevoi și plangeri ca el |
| - | * limitele inferioare și superioare | + | |
| - | * Unordered List Item câteva constante mici (0, -1, 1) | + | |
| - | * câteva constante mari | + | |
| - | * întregi negativi | + | |
| - | * caractere invalide (de exemplu, pentru baza 10 nu putem avea A) | + | |
| - | * numere care au 0 în față (dar excesiv de lungi gen: 00000000000000000000000000000666) | + | |
| - | * același lucru pentru diferite baze (dacă sunt suportate) | + | |
| - | * float | + | |
| - | * ca mai sus, dar în principal trebuie ținut cont de valorile speciale definite în standardul [[http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4610935|IEEE 754]] | + | |
| - | * -0.0 != 0.0 | + | |
| - | * Nan, -Nan | + | |
| - | * inf, -inf | + | |
| - | * un șir de caractere | + | |
| - | * limbajul acceptat (LFA style) | + | |
| - | * un vector | + | |
| - | * se aplică cazurile de la numere întregi (pentru 1 element) | + | |
| - | * 0 elemente, 1 element, 2 elemente, 5 elemente, număr maxim de elemente | + | |
| - | * caractere de despărțire / elemente invalide | + | |
| - | === Boundary testing === | + | O altă teorie despre motivare este așa-numita "teorie a așteptărilor" (Vroom, 1964). Conform acesteia, indivizii sunt motivați atunci când sunt convinși că: |
| - | Boundary testing sau boundary value analysis este o metodă de proiectare a suitelor de teste pentru cazurile în care se folosesc **valori la limită** acceptate de program. În general, accentuează testarea "corner case"-urilor. | + | * efortul suplimentar va duce la o performanță mai bună |
| - | Unele teste care fac parte din suita boundary testing sunt "stress tests". | + | * o performanță mai bună va duce la beneficii atribuite din partea organzației |
| + | * beneficiile respective sunt previzibile și valoroase pentru angajat | ||
| - | În general, boundary value analysis se realizează în doi pași: | ||
| - | # identificarea claselor de echivalență | ||
| - | # proiectarea suitelor de test | ||
| - | Primul pas înseamnă, de obicei, partiționarea valorilor posibile în clase valide și invalide. | ||
| - | //Exemplu// Un program care primește valori pozitive până în 99, va avea trei clase: | ||
| - | * clasa validă (0 < n <= 99) | ||
| - | * prima clasă invalidă (n <= 0) | ||
| - | * a doua clasă invalidă (n > 99) | ||
| - | Al doilea pas înseamnă proiectarea unei suite de teste care vor selecta anumite valori care să verifice reacția programului la valori valide sau invalide. | + | ==== Stiluri de conducere ==== |
| - | //Exemplu// Dacă un program primește valori în domeniul [-999,999], atunci o suită posibilă de test ar fi: | + | |
| - | * testare valoare -999 | + | |
| - | * testare valoare 999 | + | |
| - | * testare valoare -998 | + | |
| - | * testare valoare 998 | + | |
| - | În general, testele trebuie să includă prima și ultima valoare posibilă. De asemenea, se recomandă testarea de condiții extreme de intrare sau ieșire (valori foarte mici, foarte mari, invalide etc.) | + | Am vorbit mai devreme despre //checklistul// unui leader, dar nu și despre felul în care el "implementează" acest checklist. Din acest punct de vedere, există câteva stiluri de conducere rezumate în imaginea următoare: |
| - | Problemele pe care le detectează boundary testing sunt, de obicei: | + | {{:mps:laboratoare:leadstyle.jpg|}} |
| - | * folosirea incorectă a operatorilor relaționali (mai mic, mai mare etc.) | + | |
| - | * folosirea de valori constante inițializate incorect | + | |
| - | * erori de calcul care ar putea realiza overflow sau wrap-around în cazul conversiei între diverse tipuri de date | + | |
| - | === Link-uri utile === | + | După cum se vede, diferențele constau în gradul de delegare a responsabilităților și de participare al subalternilor la decizii. Este important de reamintit că **în leadership nu există rețete, ci construcție.** Un leader experimentat din punct de vedere tehnic care lucrează cu o echipă neexperimentată poate avea rezultate bune pe termen scurt și mediu printr-un management autoritativ sau paternalist, dar acest lucru poate frâna dezvoltarea membrilor echipei, ceea ce dăunează pe termen lung. Invers, un leader care lucrează cu o echipă experimentată are probabil cel mai mult succes printr-o delegare a responsabilităților și deciziilor, însă aici apare pericolul ca echipa să diveargă de la obiectivele organizației către obiectivele proprii. |
| - | * [[http://blogs.msdn.com/imtesty/archive/2008/11/04/boundary-testing-isn-t-guessing-at-numbers.aspx|Boundary testing isn't guessing at numbers]] | ||
| - | * [[http://www.geocities.com/xtremetesting/BoundaryValues.html|boundary values software testing]] | ||
| - | * [[http://www.win.tue.nl/~mousavi/testing/1.pdf|Boundary Value Testing]] | ||
| - | * [[http://www.cs.swan.ac.uk/~csmarkus/CS339/dissertations/NeateB.pdf|Boundary Value Analysis]] | ||
| - | === Unit testing === | + | ==== Inteligența emoțională ==== |
| - | **Unit testing** este o metodă folosită pentru a testa fiecare componentă a unui proiect. O //unitate// este cea mai mică componentă a unei aplicații. În mod ideal modulele de test sunt independente unele de celelalte. Pentru fiecare //unitate// se fac teste separate. | + | Inteligența emoțională este un concept vehiculat din ce în ce mai mult în ultimii ani, atât în ceea ce privește actul de conducere cât și în ceea ce privește dezvoltarea personală. |
| - | Există și o abordare **Test Driven Development - TDD** în care se scrie testul pentru unitate înainte de scrierea codului. | + | Inteligența emoțională se definește drept "capacitatea de a conștientiza, evalua și gestiona emoțiile proprii sau ale altora". Este ușor de văzut de ce este importantă pentru un leader: capacitatea sa de a relaționa cu membrii organizației la un nivel emoțional îi va atrage sprijinul și atașamentul grupului și va echilibra în același timp grupul. |
| - | == Stubs == | + | Cei mai buni lideri sunt aceia care nu doar conduc, ci și "inspiră" grupul. Jerald Greenberg ("Organizational Behavior: The State of the Sciences", 1994) identifică mecanismele acestei "inspirații": |
| - | O problemă des întâlnită în testarea proiectelor este testarea unei părți a proiectului înainte ca alte părți să fie gata. Se pot folosi pentru asta interfețe, numite **Stubs**, care simulează funcțiile de bază ale obiectului respectiv fără să efectueze și teste de integritate a datelor sau ale fluxului logic al problemei. Ele sunt des folosite în cursul dezvoltării unităților proiectului care depind de obiectul simulat. | + | * **viziune** coerentă și în concordanță cu valorile de bază ale grupului |
| + | * **pasiune** și credință fermă în această viziune | ||
| + | * **încredere în sine**, hotărâre, **consecvență** | ||
| + | * **imagine personală** construită în mod conștient | ||
| + | * **modelare** -- grupul se va identifica cu valorile pozitive ale liderului, lăsându-se astfel modelat de acesta | ||
| + | * **reprezentare externă** -- liderul își asumă rolul de a reprezenta grupul în fața unui mediu extern | ||
| + | * **responsabilitate și încredere acordate membrilor grupului** -- liderul comunică așteptările sale, ca și încrederea că grupul le va putea împlini | ||
| + | * **comunicare inspirațională** -- comunicarea liderului nu este seacă, ci însuflețită, colorată, puternică | ||
| - | == Mockup == | ||
| - | **Mockups** sunt tot implementarea unor interfețe care testează mai aprofundat funcțiile necesare. Ele simulează spre exemplu funcționarea unui server pentru a putea testa facilitățile clientului și testează de asemenea autentificarea clientului înainte ca acesta să poată efectua anumite tranzacții. Pentru o utilizare mai facilă se recomandă folosirea interfețelor și utilizarea lor în funcția de testare. O implementare pentru testare este o implementare care conține numai cod de test și imită cât mai bine funcționarea viitorului obiect. Mockup-urile sunt utile în multe situații precum: | + | ==== Psihologia grupului ==== |
| - | * cazul când obiectul în sine nu există | + | |
| - | * obiectul real/funcția reală ia foarte mult timp să ruleze | + | |
| - | * obiectul real este prea dificil de pus în funcțiune | + | |
| - | * funcția reală returnează valori nedeterministe și se dorește testarea comportării cu toate valorile limită | + | |
| - | * funcția reală necesită interacțiunea cu utilizatorul și nu se poate folosi în teste automate | + | |
| - | **Important** este ca atunci când se folosesc obiecte pentru simulare, trebuie să se țina cont de faptul că obiectul trebuie să simuleze cât mai bine realitatea. Există și facilități implementate pentru folosirea mockup-urilor în .NET precum NMock, POCMock, .NET Mock Object. | + | Poate părea surprinzător, dar **grupurile se comportă foarte diferit față de indivizii care le compun** - sau, cu alte cuvinte, **indivizii se comportă diferit în grup versus singuri**. Vom menționa pe scurt câteva caracteristici: |
| - | === Regression testing === | + | * **"Facilitarea socială"**: Individul singur este mai relaxat și mai indiferent la mediu. În prezența grupului, nivelul său de atenție (alertă) crește. Ca o consecință, individul va executa mai bine sarcinile ușoare (sau automatismele) dar mai prost sarcinile complexe ("Social Facilitation" - Guerin, 1993). |
| + | * **Polarizare**: Un grup ai cărui membri împărtășesc opinii similare tinde să treacă prea ușor peste contraargumente atunci când ia o decizie. Membrii grupului concentrează energia pe sublinierea punctelor cu care sunt de acord și evită concentrarea de energie pe cele asupra cărora există semne de întrebare. Deciziile au de aceea tendința de a fi impulsive, unilaterale și dezechilibrate, neglijând aspectele asupra cărora grupul nu este întru totul de acord și exacerbându-le pe cele cu care este de acord. Simultan, are loc o amplificare reciprocă a energiei, care poate conduce la reacții supradimensionate //(este mecanismul prin care manifestațiile pașnice se pot transforma în lupte de stradă, dar și mecanismul prin care membrii unei echipe se motivează/demotivează reciproc)//. | ||
| + | * **Diluarea responsabilității** și **efectul bystander**: Cu cât un grup este mai mare, cu atât influența individuală asupra grupului este mai mică. Aceasta conduce la o //diluare a responsabilității// resimțită de fiecare individ din grup. Efectul bystander (= martor) este un fenomen observat în justiție, respectiv agresiuni petrecute în văzul a zeci de martori //care nu au intervenit//. Explicația este o combinație a polarizării și a diluției de responsabilitate: pe de o parte, fiecare membru al grupului așteaptă ca ceilalți să intervină (diluția responsabilității) și pe de altă parte când observă că ceilalți nu intervin are tendința să acționeze în concordanță cu comportamentul grupului (polarizare). //În cadrul unei echipe, efectul bystander poate însemna că un email prin care soliciți ceva are șanse mai mari de succes dacă este trimis unui individ față de cazul în care este trimis pe o listă.// | ||
| - | "Also as a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. Theoretically, after each fix one must run the entire batch of test cases previously run against the system, to ensure that it has not been damaged in an obscure way. In practice, such regression testing must indeed approximate this theoretical idea, and it is very costly." -- Fred Brooks, The Mythical Man Month (p 122) | + | ==== Cultura organizațională ==== |
| - | **Regression testing** implică verificarea ca odată cu avansarea în proiect să nu se piardă funcționalități deja implementate, sau să se genereze erori noi. | + | Ansamblul de valori, termeni de specialitate, reguli, procedee, obiceiuri - formale dar mai ales informale - din cadrul unei organizații poartă numele de **cultura organizațională** și este **contextul comun în care comunică membrii organizației**. Noii veniți într-o organizație "învață" de la membrii vechi această cultură organizațională și ajung să și-o însușească. |
| - | Cea mai simplă și eficientă metodă de regression testing este să se păstreze toate testele într-un batch care să se ruleze periodic, astfel orice bug nou va fi remarcat imediat și poate fi remediat. Desigur, asta implică ca testele respective să poată fi rulate automat. | + | Lipsa ori fragilitatea unei culturi organizaționale înseamnă că membrii grupului sunt permanent expuși neînțelegerilor reciproce (fiecare presupune altceva) și de aici înșelarea așteptărilor, frustrări și lipsa de randament. |
| - | === Fault injection === | + | |
| - | 'Fault injection' este o metodă de testare software care implică generarea de input-uri care să ducă programul pe căi (în general de error handling) care altfel ar fi parcurse foarte rar în decursul unei testări normale, îmbunătățind astfel foarte mult code coverage-ul. | + | O organizație este atât de bună pe cât este cultura sa organizațională. |
| - | Există atât software cât și hardware fault injection. | ||
| - | === HWIFI(Hardware Implemented Fault Injection) === | + | ==== Relația cu managementul superior ==== |
| - | Există încă din 1970, și implică crearea de scurtcircuite pe placă, generând astfel erori. | + | Dacă ierarhia unei organizații este un arbore, atunci actul conducerii se exercită în toate nodurile acestui arbore, la toate nivelurile. Pentru a completa tabloul actului de conducere, trebuie să vorbim și despre relația unui manager cu superiorii săi. |
| - | === SWIFI(Software Implemented Fault Injection) === | + | Tipic, un //project manager// sau un //development manager// fac parte din ceea ce se numește //middle management//. Superiorii către care aceștia raportează și cu care relaționează pot fi atât din //middle management//, cât și din //executive management//: |
| - | Se împarte în două mari categorii | + | {{:mps:laboratoare:executiveteam-cubist.png|}} |
| - | # Compile time injection | + | |
| - | # Run time injection | + | |
| - | == Compile time injection == | + | * **CEO** - Chief Executing Officer, conduce întreaga organizație și raportează unui //board// de directori sau investitori |
| + | * **CTO** sau **CIO** - Chief Technical (sau Information) Officer, responsabil de tehnologie și de organizația de engineering | ||
| - | Modificarea de linii de cod la compilare pentru a genera comportamente eronate. | + | Sunt câteva lucruri fundamentale care trebuie întelese despre superiorul ierarhic, fie el senior sau middle management: |
| - | Ex: a++ poate fi modificat în a--; | + | |
| - | == Run time injection == | + | * **vede "mai de sus"**. Aceasta înseamnă că el are context mai larg și o viziune mai de ansamblu, dar în același timp că nu vede atât de multe detalii ca și tine. Corolar: nu îi vorbi mai tehnic decât îți vorbește el. |
| + | * **este o resursă shared**. Capacitatea lui de prelucrare a informației este aceeași cu a ta, însă el are mai multe proiecte similare cu al tău. Ca atare, timpul alocat de el proiectului tău este mai mic decât al tău, iar "cuantele" lui informaționale sunt mai mari decât ale tale. El nu poate - și nu trebuie! - să fie la curent cu toate detaliile. | ||
| + | * **este un client**. Tu trebuie să îl informezi, să îi preiei feedbackul - dar să îi și "vinzi", respectiv ori de câte ori îi ceri ceva, să îi comunici clar beneficiile din punctul **lui** de vedere. | ||
| - | * Coruperea spațiului de memorie al procesului | + | ==== Exemple ==== |
| - | * Interceptarea syscall-urilor și introducerea de erori în ele | + | |
| - | * Reordonarea, coruperea și distrugerea pachetelor de pe rețea. | + | |
| - | ==== Platforme de testare ==== | + | 1. Ai nevoie de niște servere pentru deploymentul proiectului tau, iar bugetul de hardware al firmei este limitat. |
| + | * **"cerere"**: Poți cere CTO-ului serverele așa: //"am nevoie de trei servere noi, îmi trebuie pentru proiectul X"//. Va raspunde foarte probabil "nu putem acum". | ||
| + | * **"vânzare"**: Sau, le poți cere așa, "vânzând" beneficiile: //"ne apropiem de finalul proiectului X. Asa cum știți, proiectul X ne va dubla profitul și numărul de utilizatori. Pentru un user experience cât mai bun, recomandăm trei servere noi"// | ||
| - | * Java: una din cele mai cunoscute platforme de testare este [[http://www.junit.org/|JUnit]] pentru care găsiți [[http://www.cavdar.net/2008/07/21/junit-4-in-60-seconds/|aici]] un tutorial. | + | 2. Ai nevoie de un upgrade al versiunii de PHP, care presupune rescrierea unor părți de cod fără a aduce un profit vizibil. Trebuie să obții acordul CEO-ului. El nu este o persoană tehnică dar este deschis și îți poate acorda cinci minute din timpul lui ca să îl convingi de ce upgrade-ul de PHP este necesar. |
| - | * C#: pentru cam toate platformele .NET există [[http://www.nunit.org/index.php|NUnit]]. Un tutorial gasiți la adresa http://www.nunit.org/index.php?p=quickStart&r=2.4 | + | * **"așa nu"**: //"vrem un upgrade al versiunii de PHP de la 4.0.4 la 5.2.12... am putea si la 5.2.12 RC 3 dar încă investigăm dacă merge cu Zend Server 5.0... upgrade-ul e necesar pentru că 5.2.12 fixează bugul de popen care produce un segfault atunci când pasezi întregi octali care nu sunt moduri de acces"// |
| - | * [[http://docs.python.org/library/unittest.html|Python unittest]] pentru Python. | + | * **"așa da"**: //"în momentul de față site-ul este vulnerabil și potențial instabil din cauza unui bug de PHP. Versiunea nouă fixează acest bug. Va trebui să rescriem și porțiuni de cod, dar în final site-ul va fi mai sigur și mai stabil pentru useri."// |
| - | ==== Testarea interfețelor grafice ==== | + | |
| - | Există mai multe utilitare pentru testarea automată a programelor cu interfețe grafice (o listă mai detaliată aveți [[http://en.wikipedia.org/wiki/List_of_GUI_testing_tools|aici]]). | + | 3. Echipa X este foarte competentă. Rezolvă cele mai dificile probleme tehnice ale proiectelor fără ca development managerul să știe măcar că au aparut probleme. Echipa Y este mai puțin competentă. Atunci când apar probleme, ei încearcă să le rezolve, nu reușesc, își informează superiorul ierarhic despre dificultăți și cer ajutor sau uneori apelează direct la membrii echipei X pentru consultanță. După un timp, echipei X i se crește salariul cu 5% iar echipei Y cu 20%. |
| + | //Explicația: din punctul de vedere al superiorului ierarhic, activitatea echipei X este plată, ei par să își facă treaba fără să se fi lovit de probleme. Echipa Y a avut însă probleme, a încercat să le rezolve, a informat despre ele, a cerut ajutor, a primit în final ajutor de la membrii echipei X. Concluzia superiorului: echipa X nu e foarte încărcată (de aceea a avut timp și să ajute Y) iar echipa Y a primit cele mai grele proiecte (de aceea au avut atâtea probleme) și s-a străduit exemplar (așa cum se vede și din comunicările făcute).// | ||
| - | === AutoIt === | + | ==== Bibliografie ==== |
| - | [[http://www.autoitscript.com/autoit3/|AutoIt]] este un limbaj de programare asemănător Visual Basic cu un compilator ce rulează pe Windows și care permite (printre altele): | + | * http://books.google.com/books?id=kchznb5VKKoC&printsec=frontcover&source=gbs_v2_summary_r&cad=0#v=onepage&q=&f=false |
| - | * apelul unor funcții din DLL-uri Win32 | + | * http://en.wikipedia.org/wiki/Motivation |
| - | * execuția de aplicații (consolă/GUI) | + | * http://en.wikipedia.org/wiki/Leadership |
| - | * creare de interfețe GUI (ferestre de mesaje, atenționare, de introducere de date, etc.) | + | * http://en.wikipedia.org/wiki/Outstanding_leadership_theory |
| - | * manipulare sunete | + | * http://www.nwlink.com/~donclark/leader/leadstl.html |
| - | * simulare mișcări de mouse și apăsare taste și combinații de taste | + | * http://www.mindtools.com/pages/article/newLDR_84.htm |
| - | * manipulare ferestre și procese | + | * http://en.wikipedia.org/wiki/Emotional_intelligence |
| - | * manipulare elemente în cadrul unei ferestre | + | * http://allpsych.com/psychology101/groups.html |
| + | * http://en.wikipedia.org/wiki/Change_management_(people) | ||
| - | Scripurile pot fi compilate sub forma unor executabile Win32. | ||
| - | Două tutoriale de AutoIt: interacțiune cu [[http://www.autoitscript.com/autoit3/docs/tutorials/notepad/notepad.htm|notepad]] și instalare [[http://www.autoitscript.com/autoit3/docs/tutorials/winzip/winzip.htm|winzip]] | + | ====== Exercitii (50 de minute) ====== |
| + | ===== Exercitiul 1 (10 minute) ===== | ||
| + | Raspundeti la intrebarile din testul urmator https://www.arealme.com/eq/en/ pentru a va afla scorul EQ si descrierea inteligentei voastre emotionale. Conform descrierii obtinute, cu ce credeti ca va ajuta inteligenta voastra emotionala in meseria de zi cu zi? | ||
| - | === Abbot === | + | ===== Exercitiul 2 (10 de minute) ===== |
| + | Parcurge [[http://www.pickthebrain.com/blog/21-proven-motivation-tactics/ | acest site]] și alege cele mai relevante 3-5 elemente care te motivează. | ||
| + | * Există elemente care te-ar motiva foarte puțin, deloc, sau negativ? | ||
| - | [[http://abbot.sourceforge.net/doc/overview.shtml|Abbot]] este o platformă de testare automată a aplicațiilor GUI scrise în Java. Testele sunt scrise sub forma unor unit-test-uri. Mai multe detalii pe site-ul proiectului. | + | ===== Exercitiul 3 (30 de minute) ===== |
| + | Grupati-va pe echipe (echipele de proiect). | ||
| + | In 10 minute obtineti un achievement cat mai mare aici: | ||
| + | https://clickclickclick.click | ||
| + | In urmatoarele 10 minute avansati cat mai multe niveluri (dungeons) aici: | ||
| + | https://codecombat.com/play/dungeon | ||
| - | == Code coverage, Code profiling == | + | Calculati scorul fiecarei echipe. Cine a castigat? |
| + | Calculul se face in felul urmator: | ||
| + | Adunati procentul de achievement de la primul task cu numarul de niveluri depasite la al doilea task inmultit cu 5 si adunati experienta obtinuta (tot la al doilea task). | ||
| - | Deși folosite în special pentru optimizări și pentru identificarea bottleneck-urilor din sistem, utilitarele de tip code-coverage și code-profiling pot fi folosite pentru detectarea anumitor tipuri de probleme precum bucle infinite, sincronizare ineficientă etc. | ||
| - | === Code coverage === | + | <hidden> |
| + | Exercitii extra in cazul in care timpul va permite. | ||
| + | Urmăriți [[http://www.youtube.com/watch?v=u6XAPnuFjJc | filmul de aici]]. Discuții. | ||
| + | Alocă timp și răspunde la următoarele întrebări: | ||
| + | * Cine ești? (Atenție: **Cine**, nu **Ce**) | ||
| + | * Cine vrei să devii? Ce vrei să schimbi? | ||
| + | * Care sunt valorile tale? | ||
| - | Utilitarele de tipul code coverage sunt folosite în procesul de testare a programelor pentru inspectarea unei părți cât mai mari a programului. Diversele tipuri de mecanisme de tip code coverage sunt folosite pentru a determina ce funcții sunt acoperite la o rulare, ce instrucțiuni sunt apelate, ce fluxuri de execuție sunt parcurse. | + | Urmăriți [[http://www.youtube.com/watch?v=V74AxCqOTvg | filmul de aici]]. Discuții. |
| + | Gândește-te la o persoană care este, pentru tine, un model de lider. | ||
| + | * Numește 3 caracteristici ale acestei persoane care sunt reprezentative pentru ea ca lider. | ||
| - | Programele folosesc opțiuni speciale de code-coverage. Cu ajutorul acestor opțiuni se pot determina funcțiile sau instrucțiunile des (sau rar) folosite și oferă o imagine a nivelului de testare a anumitor părți dintr-un program. | + | Gândește-te că ești parte a unui grup, comunități, entități profesionale **ideale**. Care sunt cele 3 caracteristici importante ale persoanelor care fac parte din această comunitate? |
| - | În general, utilitarele de code coverage sunt privite ca utilitare pentru depanare automată și sunt folosite, de obicei, de inginerii de testare. Depanarea efectivă, cu utilitare de debugging specializate, este realizată, în general de dezvoltatorii care au cunoștință de codul inspectat. | + | Potential test din laboratorul trecut pentru extra punctaj (sau ceva in genul) |
| - | === Code profiling === | + | 1 - [3p] Enuntati Legea lui Brook. |
| - | Profilerele sunt utilitare care prezintă informații referitoare la execuția unui program. Sunt utilitare care intră în categoria "dynamic analysis" spre deosebire de alte programe care intră în categoria "static analysis". | + | 2 - [3p] Calcul SPI pentru: |
| + | module 90% 3 | ||
| + | view 70% 2 | ||
| + | controller 100% 4 | ||
| - | Profilerele folosesc diverse tehnici pentru colectarea de informații legate de un program. De obicei se obțin informații de timp petrecut în cadrul unei funcții (nivel ridicat) sau numărul de cache miss-uri, TLB miss-uri (nivel scăzut). | + | 3 - [3p] Un proiect cu 8 componente. |
| + | Cate interconexiuni in cazul abordarii: | ||
| + | stea | verticala | orizontala | ||
| - | În general, un program care este "profiled" este instrumentat astfel încât, în momentul rulării, să ofere la ieșire informațiile utile dorite. Spre exemplu, pentru a folosi opțiunile gprof, se folosește opțiunea ''-pg'' transmisă gcc. | + | BONUS: |
| - | ===== Software Quality Assurance (SQA) ===== | + | 4 - [3p]Service Oriented Architecture |
| - | * ciclu de asigurare a calității produsului software | + | |
| - | * se desfășoară de-a lungul întregului ciclu de dezvoltare a produsului software, pe care **îl îndrumă, monitorizează, auditează, evaluează și coordonează** | + | |
| - | * complementează procesul de dezvoltare a proiectului | + | |
| - | * (în mediile enterprise) este realizat de către un grup de resurse umane dedicate asigurării calității. | + | |
| - | === Domeniul QA === | + | Enumerati 4 principii |
| - | * metodologia QA a fost introdusă inițial în cadrul fabricilor, unde și-a demonstrat aportul la succesul producției de calitate | + | OFICIU: [1p] |
| - | * ulterior, s-a dorit adoptarea QA la mediul dezvoltator de aplicații software | + | |
| - | * //Problema//: produsul software nu este palpabil, deci măsurarea funcțiilor, a beneficiilor și a costurilor sunt mai dificil de determinat | + | |
| - | * //Soluția//: s-au adăugat concepte precum quality attributes (metrici software, cerinte functionale si non-functionale) pentru a putea măsura calitatea produsului software. | + | |
| - | Cel mai cunoscut //model de atribute// ale produselor software de calitate este **FURPS+ model**, care cuprinde următoarele atribute: | + | Total 10p (13 cu bonus). |
| - | - **funcționalitate** (//functionality//) | + | |
| - | * cuprinde toate cerințele funcționale ale sistemului așa cum au fost stabilite în SRS | + | |
| - | - **utilizabilitate** (//usability//) | + | |
| - | * cuprinde cerințe legate de ușurința de folosire a interfeței sistemului de către utilizator (interfața trebuie să fie estetică, intuitivă, ergonomică, consistentă, accesibilă și celor cu disabilități) | + | |
| - | - **încredere** (//reliability//) | + | |
| - | * cuprinde cerințe legate de precizia răspunsurilor, de disponibilitatea și toleranța la defecte a sistemului | + | |
| - | - **performanță** (//performance//) | + | |
| - | * cuprinde cerințe legate de timpii de lucru, precum timp de răspuns (response time), timp de revenire (recovery time), timp de lansare (startup time) | + | |
| - | - **avantaje suplimentare** (//supportability//) | + | |
| - | * cuprinde cerințe legate de ușurința testării (testability), a mentenanței (maintainability), a configurării (configurability), de gradul de scalare (scalability) și compatibilitate (compatibility) și de oferire de multiple traduceri ale conținutului interfeței cu utilizatorul. | + | |
| - | + | ||
| - | * "**+**" se referă la faptul că la acest model se pot adăuga și alte cerințe de calitate personalizate. \\ \\ | + | |
| - | + | ||
| - | Au apărut **standarde** dedicate produselor software, de tipurile: | + | |
| - | * **standarde de managementul calității** (//Quality management//) | + | |
| - | * //ISO 9000 – 3// Quality Management and Quality Assurance Standards – Part 3: Guidelines for the application of 9001 to the development, supply, installation and maintenance of computer software | + | |
| - | * **standarde de documentare** (//Documentation Standards//) specifică formatul și conținutul documentelor de planificare și control și a documentației produsului | + | |
| - | * **standarde de planificare** (//Producing plans//): //IEEE Std1059-1993// Guide for Software Verification and Validation Plans | + | |
| - | * **standarde de Project Management** | + | |
| - | * //General project management//: //IEE Std 1058.1-1987// Standard for Software Project Management Plans | + | |
| - | * **standarde de Software Engineering** | + | |
| - | * //Software Project Lifecycle//: //ISO/IEC WD 15288// System Life Cycle Processes | + | |
| - | * //Software Project Requirements//: //IEEE Std 1233-1996// Guide for Developing System Requirements Specifications | + | |
| - | * **standarde de proiectare** (//Design Standards//) specifică reguli și metode de proiectare a soluției pornind de la specificații și formatul și conținutul documentelor de proiectare | + | |
| - | * **standarde de codare** (//Code Standards//) specifică limbajele de programare alese, convențiile de stil, reguli de construire a interfețelor și modul de comentare a surselor.\\ \\ | + | |
| - | + | ||
| - | + | ||
| - | Ulterior, s-au definit **proceduri**: | + | |
| - | * sunt succesiuni de pași ce trebuie urmați pentru a împlini un proces (ex: testare, configuration management). | + | |
| - | + | ||
| - | ===Activități SQA=== | + | |
| - | //Activitățile principale SQA// sunt: | + | |
| - | * asigură că standardele și procedurile de calitate alese pentru a fi urmate în proiect sunt //adecvate// la specificul proiectului (stabilirea lor este critică pentru că standardele oferă criteriile de evaluare a produsului și procedurile criteriile de comparare pentru procesele de dezvoltare și control) | + | |
| - | * asigură că standardele și procedurile alese sunt //bine documentate// pentru că activitățile de monitorizare, audit și evaluare se bazează pe ele | + | |
| - | * monitorizarea proceselor de dezvoltare și control //în raport cu procedurile de calitate// (pașii urmați coincid cu cei ai procedurilor?) | + | |
| - | * evaluarea proiectului //în raport cu standardele de calitate//. | + | |
| - | + | ||
| - | Activitățile de evaluare și monitorizare au loc în cadrul **auditurilor**. //Auditul// este //tehnica SQA de bază// folosită pentru verificarea calității produsului | + | |
| - | + | ||
| - | * întocmește //rapoarte de audit// care sunt predate management-ului, ce afirmă gradul de implementare a calității și oferă //recomandări// pentru implementarea / sporirea calității în faza următoare a proiectului.\\ \\ | + | |
| - | Există **activități SQA specifice fazelor** ciclului de viață al proiectului | + | |
| - | - //faza de inițiere// | + | |
| - | * SQA intervine în redactarea și revizuirea planului de management | + | |
| - | * asigură că standardele și procedurile alese sunt potrivite, clare și pot servi ca bază de auditare | + | |
| - | - //faza cerințelor software// | + | |
| - | * SQA intervine în revizuirea specificațiilor | + | |
| - | * asigură că specificațiile sunt clar exprimate, sunt categorisite corect în cerințe funcționale și non-funcționale (de interfață, de performanță, etc.), acoperă toate cerințele utilizatorului, pot fi măsurate | + | |
| - | - //faza de proiectare// | + | |
| - | * SQA intervine în revizuirea documentelor de proiectare | + | |
| - | * asigură că toate cerințele software au fost traduse corect în componente software în raport cu standardele și procedurile de proiectare | + | |
| - | - //faza de dezvoltare// | + | |
| - | * SQA asigură că soluția este dezvoltată în concordanță cu documentul de proiectare și cu standardele și procedurile de codare | + | |
| - | - //faza de testare// | + | |
| - | * SQA asigură respectarea standardelor și a procedurilor de testare | + | |
| - | * anunță sfârșitul procedurii de testare a cerințelor funcționale | + | |
| - | - //faza de livrare// | + | |
| - | * SQA verifică și declară respectarea cerințelor non-funcționale | + | |
| - | * anunță că produsul final este gata de livrare | + | |
| - | - //faza de mentenanță// | + | |
| - | * SQA intervine pentru a asigura că subciclurile de dezvoltare respectă normele de calitate | + | |
| - | + | ||
| - | ===SQAP (Software Quality Assurance Plan)=== | + | |
| - | În general, scopul unei organizații este crearea unui **SQAP** care să asigure nivelul dorit de calitate a produsului.\\ \\ | + | |
| - | Din standardul [[http://ieeexplore.ieee.org/document/720573/ | IEEE 730-1998]], structura unui SQAP conține următoarele secțiuni: | + | |
| - | - Scopul documentului (Purpose) | + | |
| - | - Documente referite | + | |
| - | - Management | + | |
| - | - Documentație | + | |
| - | - Standarde, practici, convenții, metrici | + | |
| - | - Revizii și audituri | + | |
| - | - Managementul riscului | + | |
| - | - Raportarea problemelor și acțiuni de corecție | + | |
| - | - Utilitare, tehnici și metodologii | + | |
| - | - Controlul furnizorului | + | |
| - | - Training | + | |
| - | - Colectarea înregistrărilor, mentenanța | + | |
| - | Un exemplu de document SQAP puteți găsi [[http://people.cs.ksu.edu/~ganti/mse_sqa.htm|aici]]. | + | |
| - | + | ||
| - | ===== Terminarea unui proiect ===== | + | |
| - | + | ||
| - | ===Contexte de terminare=== | + | |
| - | Un proiect se poate finaliza în următoarele contexte: | + | |
| - | * **s-a terminat** (cazul cel mai fericit – proiect de //succes//) | + | |
| - | * **a fost oprit** din motive (proiect //eșec//): | + | |
| - | * **de afaceri** (apar oportunități noi de business care ar genera un profit semnificativ mai mare decât proiectul actual) | + | |
| - | * **de cost** (bugetul alocat proiectului a fost epuizat și nu mai există surse de finanțare) | + | |
| - | * **de calitate** (calitatea proiectului este foarte redusă, deci investiția nu mai merită) | + | |
| - | * **tehnice** (între timp, au fost lansate soluții mai viabile decât cea a proiectului actual, tehnologiile utilizate de proiect au devenit demodate) | + | |
| - | * **de timp** (timpul alocat proiectului s-a încheiat) | + | |
| - | + | ||
| - | **Feluri de terminare** a unui proiect: | + | |
| - | * //Extinctie// (proiectul se termină prin succes sau eșec și, pe viitor, nu se va mai lucra la proiect) | + | |
| - | * //Terminare prin adiție// (proiectul se termină cu succes și, pe viitor, echipa care a dezvoltat proiectul se va ocupa de mentenanța produsului) | + | |
| - | * //Terminare prin integrare// (proiectul se termină cu succes și resursele sunt reintegrate în alte proiecte ale companiei – modul cel mai frecvent) | + | |
| - | + | ||
| - | ===Checklist-ul terminării proiectului=== | + | |
| - | * cuprinde //activitățile rămase// din cadrul proiectului | + | |
| - | * cuprinde //activitățile colaterale// ce trebuie realizate pentru a încheia proiectul în conformitate cu procedurile actuale: | + | |
| - | * completarea și distribuirea rapoartelor de performanță | + | |
| - | * completarea și distribuirea documentației sistemului | + | |
| - | * completarea auditurilor de calitate | + | |
| - | * completarea auditurilor de vânzare | + | |
| - | * revizia sistemului împreună cu help desk | + | |
| - | * întâlnirea cu staff-ul operațional care urmează să preia software-ul (în vederea mentenanței) | + | |
| - | * împlinirea cerințelor de training ale staff-ului operațional | + | |
| - | * primirea sign-off-ului de la staff-ul operațional | + | |
| - | * oferirea detaliilor despre performanța membrilor proiectului (evaluarea echipei și evaluările individuale ale membrilor și a PM-ului) | + | |
| - | * primirea sign-off-ului de acceptare de la client și acceptarea formală a tuturor livrabilelor proiectului. | + | |
| - | + | ||
| - | În cazul în care se folosește un sistem de bug/issue tracking, trebuie ca //toate issue-urile să fie rezolvate// înainte de finalizarea proiectului chiar dacă ele nu au fost incluse în specificații. | + | |
| - | + | ||
| - | În cazul în care nu se poate acest lucru, cei care predau proiectul trebuie să se asigure că problemele rămase deschise sunt de prioritate scăzută și nu au un impact major asupra funcționalității. | + | |
| - | + | ||
| - | ===Procesul de terminare=== | + | |
| - | * se decide terminarea proiectului | + | |
| - | * se obțin aprobările necesare (de la clienți, sponsori) | + | |
| - | * se comunică decizia părților interesate | + | |
| - | * se realizează activitățile rămase din proiect și cele colaterale | + | |
| - | * se face post-performance analysis | + | |
| - | * se publică raportul final | + | |
| - | * se sărbătorește terminarea proiectului | + | |
| - | * se reasignează resursele (persoane și echipamente) | + | |
| - | * se efectuează închiderea financiară și administrativă | + | |
| - | + | ||
| - | == Post-Performance Analysis (PPA) == | + | |
| - | Încheierea unui proiect nu presupune numai livrarea produsului, ci și **oportunitatea de a învăța** din această experiență pentru îmbunătățirea contribuțiilor la proiectele viitoare.\\ \\ | + | |
| - | **Recomandări**: | + | |
| - | * analiza finală a proiectului să se bazeze pe //metrici// (așa se pot cuantifica acurat rezultatele); | + | |
| - | * exemplu de metrici: | + | |
| - | - **calitatea produsului**: | + | |
| - | - //Defects per KLOC// (Kilo Line Of Code): numărul de buguri per KLOC, unde **KLOC** este unitatea de măsură pentru codul produsului | + | |
| - | - //MTTC// (Mean Time To Change): cât timp este necesar pentru a localiza eroarea, a proiecta repararea, a o implementa si testa | + | |
| - | - //threat probability//: probabilitatea atacurilor ce exploatează vulnerabilitățile produsului pe o perioadă de timp | + | |
| - | - //security probability//: probabilitatea eliminării vulnerabilităților pe o perioadă de timp | + | |
| - | - **calitatea activităților QA**: | + | |
| - | - //Test Coverage//: numărul de unități testate (KLOC/FP) / dimensiunea sistemului, unde **FP** (function point) este unitate de măsură pentru codul produsului din perspectiva funcționalității de business oferite | + | |
| - | - //Number of tests per unit size//: numărul de teste per KLOC/FP | + | |
| - | - //Cost to locate defect//: costul de testare / numărul de defecte detectate | + | |
| - | - **//Quality of Testing//**: E / ( E + D ), unde E este numărul de erori identificate înainte de livrarea produsului, D numărul de erori identificate după livrare | + | |
| - | - //System complaints//: numărul de plângeri din partea clienților / numărul de plângeri rezolvate | + | |
| - | - //Test Planning Productivity//: numărul de teste proiectate / efortul pentru proiectarea și documentarea testelor | + | |
| - | - //Test Execution Productivity//: numărul de cicluri de testare executate / efortul de testare | + | |
| - | - //Test efficiency//: numărul de teste solicitate / numărul erorilor sistemului | + | |
| - | + | ||
| - | * să se determine //cauzele// ce au condus la valorile finale ale metricilor | + | |
| - | * să se rețină și să se înțeleagă aceste cauze, să se determine ce //posibilități// ar fi existat/ar exista pentru a evita producerea acestor cauze, ce posibilități sunt de stimulare a producerii a acestor cauze | + | |
| - | * să se colecteze //valorile reutilizabile// care au fost produse în cadrul proiectului (proceduri, checklisturi, guidelines) și să se facă publice | + | |
| - | + | ||
| - | **PPA**: | + | |
| - | * este //analiza situației finale// a proiectului în vederea concluzionării asupra factorilor de succes și a modalităților de stimulare a lor, precum și asupra factorilor de insucces și a modalităților de prevenire, rezolvare a efectelor lor | + | |
| - | * este //analiza ce stimulează procesul de învățare// din experiența proiectului | + | |
| - | * este recomandat să se realizeze periodic (imediat după milestone-uri) pentru a putea folosi concluziile analizei chiar in faza următoare | + | |
| - | + | ||
| - | **Procesul PPA** are următorii pași: | + | |
| - | - invitarea echipei la analiză (propunând ca fiecare membru să reflecteze asupra factorilor de succes/insucces și să vină cu propuneri de îmbunătățire – se trimite un chestionar de analiză) | + | |
| - | - colectarea individuală a feedback-ului fiecărei persoane implicate în proiect (individual pentru a înțelege întreaga panoramă a proiectului) | + | |
| - | - realizarea unei întâlniri a echipei în vederea concluzionării asupra: ce și cum s-a întâmplat, în ce moduri ar fi putut fi prevenite/soluționate problemele? | + | |
| - | - publicarea și arhivarea sumarului PPA. | + | |
| - | În general, se folosește **un chestionar** pentru colectarea informațiilor. De obicei, acesta are conținut diferit între team leaderi și team memberi.\\ \\ | + | |
| - | Câteva întrebări de chestionar sunt cele de mai jos: | + | |
| - | - Identificați lucrurile care au mers bine în cadrul acestui proiect. | + | |
| - | - Identificați lucrurile care au mers prost în cadrul acestui proiect. | + | |
| - | - Ce evenimente neprevăzute au afectat pozitiv sau negativ desfășurarea proiectului? | + | |
| - | - În cadrul acestui proiect, ce lucruri ați face diferit dacă ar fi repornit? | + | |
| - | - Descrie un lucru pe care tu l-ai fi putut realiza personal pentru a îmbunătăți calitatea produsului obținut din cadrul acestui proiect. | + | |
| - | - Ai fost informat despre ceea ce se așteaptă de la tine în cadrul acestui proiect? | + | |
| - | - Au fost rolurile membrilor echipei definite clar? | + | |
| - | - Echipa a făcut tot ce se putea face pentru a duce la bun sfârșit acest proiect? | + | |
| - | - Cum s-a comportat echipa în ansamblul său? | + | |
| - | - Care a fost componenta cea mai satisfăcătoare din cadrul proiectului? | + | |
| - | Un exemplu complet de chestionar găsiți [[http://michaelgreer.biz/?p=161|aici]] | + | |
| - | + | ||
| - | ==Exerciții (50 min)== | + | |
| - | + | ||
| - | Raspundeti la urmatoarele intrebari: | + | |
| - | - Se da urmatorul patch: [[https://curl.haxx.se/CVE-2016-8616.patch|patch]]. Precizati: | + | |
| - | * cate modificari s-au facut? | + | |
| - | * cate fisiere au fost modificate? | + | |
| - | * ce bug ar putea rezolva acest patch? | + | |
| - | * cum ati testa acest fix? | + | |
| - | - Ganditi-va la platforma vmchecker. | + | |
| - | * ce fel de testare face: Boundary testing / Black Box Testing? | + | |
| - | * argumentati si exemplificati | + | |
| - | * Dar dintre urmatoarele: Stubs / Mockups / Regression testing? | + | |
| - | * argumentati si exemplificati | + | |
| - | - Ce fel de testare este ilustrata [[http://i.imgur.com/KHaCdxA.png|aici]] ? | + | |
| - | - **[Bonus]** De unde vine denumirea de bug? | + | |
| - | + | ||
| - | **Nota**: fiecare subpunct valoareaza un punct, se acorda un punct pentru prezenta. Punctajul total aferent laboratorului curent este de **11p**. | + | |
| - | + | ||
| - | <hidden> | + | |
| - | Rezolvari: | + | |
| - | - 3 modificari (se vad in 3 locuri --/++), un singur fisier afectat. Bug: functie pasibila de erori la verificare username si parola (context: calcula un hash si il verifica sa semene cu unul existent din memorie, insa functia aia existenta nu era case-sensitive. | + | |
| - | - Black box - evident (considera tema trimisa ca un black box si ruleaza testele). Poate si si Boundry acceptat, daca se aduce ca exemplu o tema precum tema 0 de la SO, care verifica sa ruleze tema si pe o lista vida de cuvinte. Sigur nu Regression. Stabs este corect. Se accepta exemple precum o tema care verifica functionalitatile pas cu pas (tema 3 la SO). Si Mockups e un raspuns corect: anumite functionalitati din checker sunt mimate/emulate (exeplu: tema 1 la Protocoale de Comunicatie). | + | |
| - | - Boundry testing | + | |
| - | - Vezi ultimul link de la bibliografie. Special am pus bilbiografia dupa exercitii in aceeasi sectiune din lab (sa vedem daca au inspiratia sa se uite acolo). | + | |
| </hidden> | </hidden> | ||
| - | - Descrieți sumar conțintul unui SQAP pentru proiectul vostru. | + | ====== Lucru la proiect (50 de minute) ====== |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-11#sqap_software_quality_assurance_plan|Software Quality Assurance Plan]] | + | |
| - | - Pregătiți un checklist pentru terminarea proiectului vostru. Argumentați! | + | |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-11#terminarea_unui_proiect_10_min|Terminarea unui proiect]] | + | |
| - | - Răspundeți la întrebările de la procesul PPA pentru proiectul vostru. | + | |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-11#post-performance_analysis_ppa_10_min|Post-Performance Analysis]] | + | |
| - | + | ||
| - | == Bibliografie == | + | |
| - | * http://www.sqatester.com/methodology/PositiveandNegativeTesting.htm | + | Proiectul trebuie prezentat in laboratorul 12. |
| - | * http://www.opensourcetesting.org/testmgt.php | + | * Din perspectiva project managerului, ce strategie de motivare ar trebui sa folositi pentru a ajuta echipa sa duca la bun sfarsit task-urile? |
| - | * http://www.sqatester.com/documentation/testcasesmpl.htm | + | * Din perspectiva membrilor echipei, identificati o problema intampinata in timpul proiectului (rezolvata sau inca prezenta) pe care nu ati prezentat-o cum trebuie "conducerii". Prezentati-o sub alta forma si analizati daca reactia conducerii este diferita. |
| - | * http://www.computerhistory.org/tdih/September/9/ | + | |
| + | Lucrați la proiect în cadrul echipei. | ||
