Differences
This shows you the differences between two versions of the page.
|
mps:laboratoare:laborator-11 [2018/09/21 23:34] carina.mogos |
mps:laboratoare:laborator-11 [2024/12/19 11:25] (current) iulia.stanica [Suport pentru prezentare (10 minute)] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Laborator 11 - Testarea și asigurarea calității și finalizarea unui proiect ====== | + | ====== Laborator 11 - Tehnici de prezentare ====== |
| - | ==== Termeni ==== | ||
| - | **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. | ||
| - | **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ă. | ||
| - | **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). | ||
| - | **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. | + | ===== Suport pentru prezentare (10 minute) ====== |
| - | **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. | + | View [[https://www.slideshare.net/slideshow/sfaturi-prezentare20/2056731|presentations from Daniel Rosner]] |
| - | **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. | + | ===== Broșură / materiale promoționale ===== |
| + | În timpul unei prezentări către client, //materialele de prezentare// costumizate relativ la produs și la client pot aduce un plus prezentării. | ||
| + | Acestea denotă interes și atenție față de client și pot fi folosite pentru a transmite mai bine anumite informații și pentru a atrage atenția asupra avantajelor produsului.\\ \\ | ||
| - | **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. | ||
| + | ===== Împachetare, deployment (5 min)===== | ||
| + | Cum un proiect nu poate fi livrat către client sub formă de proiect NetBeans / Visual / etc, clientului îi va fi oferit, în general, proiectul sub forma unui installer. | ||
| - | ==== Aplicații === | + | Există diferite formate / metode de generare de installere, în funcție de sistemul de operare și de platforma software. |
| - | === GitHub === | + | |
| - | Așa cum a fost descris în cadrul laboratorului 4, [[https://github.com/|GitHub]] permite și un management al bug-urilor. | + | |
| - | === Redmine === | + | În general, mediile vizuale de dezvoltare oferă posibilitatea de generare automată a unui installer pentru proiect, prin intermediul unui proiect de tip installer. (Exemplu: http://support.microsoft.com/kb/307353 ). |
| - | [[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 === | + | Exemplu de aplicație dedicată: http://sourceforge.net/projects/installgen/ |
| - | [[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]]. | + | |
| - | === Trac === | + | ===== Scenariu de demo (5 min) ===== |
| - | [[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 === | + | În cadrul unei prezentări, este foarte important pentru client să vadă rezultatul concret. Prezentările teoretice și promisiunile sunt foarte bune în stadiul incipient al proiectului, dar la finalizarea proiectului important este rezultatul. |
| - | Fiecare bug are o adresă de mail distinctă. Comentariile și controlul bug-urilor se face cu emailuri tipizate. | + | |
| - | === Launchpad === | + | Pentru a putea demonstra clientului funcționalitatea produsului, se recomandă construirea unui scenariu de demo, care trece utilizarea programului printr-o serie de pași, accentuând funcționalitățile produsului. |
| - | [[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). | + | De asemenea, un scenariu de demo poate fi folositor și ca help guide. Există aplicații specializate în care pot fi realizate filme de prezentare pas cu pas a modului de funcționare a unui produs software și a modului de utilizare. |
| - | Bugurile pot fi urmărite prin email și atom feeds, fiecare bug având asociată o adresa de email (ex: 249177@bugs.launchpad.net). | + | |
| + | O astfel de aplicație este http://www.adobe.com/products/captivate/ | ||
| - | ==== Patch-uri ==== | + | Aplicații open source: |
| + | * http://camstudio.org/ | ||
| + | * http://recordmydesktop.sourceforge.net/about.php | ||
| + | * http://xvidcap.sourceforge.net/ | ||
| - | 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. | + | Un exemplu de help file realizat folosind captivate (dummy-proof) : http://elf.cs.pub.ro/~mps/labs/lab-12/navigation.html |
| - | 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: | + | ===== Ofertă de preț (5 min) ===== |
| - | <code> | + | În cele mai multe cazuri, scopul final al unui proiect este unul comercial. Astfel, proiectul trebuie să fie oferit la vânzare contra unui cost, care trebuie să: |
| - | --- original_file_name comentarii (ștampilă de timp, versiunea fișierului în svn/git/etc., etc.) | + | * acopere costurile de realizare, care pot include: |
| - | +++ modified_file_name comentarii (idem) | + | * cheltuieli cu personalul |
| - | @@ -start_line__original_file,nr_lines__original_file +start_line__modified_file,nr_lines__modified_file @@ | + | * cheltuieli cu aparatura |
| - | context_line_before_1 | + | * cheltuieli administrative |
| - | context_line_before_2 | + | * licențe |
| - | ... | + | * acopere costurile de întreținere, upgrade, bug fix-ing pe o perioada de timp pentru care o să fie oferit suport către client |
| - | context_line_before_n | + | * evident, trebuie să existe și un profit în final |
| - | - 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: | + | Există mai multe modele de vânzare, care depind și de natura proiectului: |
| + | * dacă proiectul este realizat la comandă, cel mai probabil va fi vândut unui singur client și din banii obținuți de la acesta trebuie acoperite toate cheltuielile | ||
| + | * contractul de vânzare poate include clauze de asigurare a mentenanței, training, bug-fixing, upgrading. Banii pentru aceste activități pot fi incluși, fie în suma inițială, fie într-o sumă periodică stabilită prin contract. | ||
| + | * dacă proiectul este unul general, care va fi vândut mai multor clienți: | ||
| + | * se poate alege varianta cea mai des folosită - clientul cumpără inițial o licență, și primește softul, un anumit grad de suport bine definit, acces la bug-fixuri și upgrade-uri. | ||
| + | * în ultimul timp, a devenit din ce în ce mai populară varianta în care compania vinde servicii reprezentate de anumite acțiuni posibile folosind soft-ul dezvoltat (**Software as a Service**). O astfel de abordare se pretează foarte bine serviciilor online. | ||
| + | * o altă variantă este cea în care compania distribuie soft-ul gratuit, iar clientul plătește servicii de suport. Serviciile de suport pot reprezenta servicii de modificare a aplicației pentru nevoile clientului, pregătirea unui installer pentru mediul clientului, suport pentru instalare și pentru folosirea produsului, și alte variante în care clientul deși poate folosi soft-ul gratuit, trebuie să plătească. | ||
| - | <code> | + | ===== Estimare costuri (5 min) ===== |
| - | --- v1.c 2008-11-18 02:34:38.000000000 +0200 | + | Un mod simplist de a realiza o estimare a costurilor ar fi următorul: |
| - | +++ v2.c 2008-11-18 02:38:14.000000000 +0200 | + | ^ Ce ^ Unitate ^ Cantitate ^Total ^ |
| - | @@ -261,8 +261,18 @@ | + | | Dezvoltare | 40RON/oră*om | 500 ore*om | 20000 RON| |
| - | if (build_key(argv[1])) | + | | Suport | 20RON/oră*om | 200 ore*om|4000 RON | |
| - | return 2; | + | | Bug fixing | 20RON/oră*om | 200 ore*om | 4000 RON| |
| - | + | | Costuri promovare | - | - | 4000 RON| | |
| - | - display("original message: [%s]\n", msg, blocks); | + | | Chirie | 800RON/lună | 2 luni | 1600 RON| |
| - | - | + | | Costuri administrative | 800RON/lună | 2 luni | 1600 RON| |
| - | + //display("original message: [%s]\n", msg, blocks); | + | | Rate (amorsare) echipamente | 800RON/lună | 2 luni | 1600 RON| |
| - | + if (blocks) | + | | Rate (amorsare) licențe | 800RON/lună | 2 luni | 1600 RON| |
| - | + { | + | |
| - | + 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 ==== | + | ===== Exerciții ===== |
| - | === diff === | + | ==== Exercitiul 1: Prezentare (20 de minute) ==== |
| + | Parcurgeti una dintre aceste prezentari [1]. Ce parti bune/rele observati? Sustineti prezentarea aleasa. | ||
| - | '''''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: | + | [1] https://drive.google.com/drive/folders/0B7WjsFvWhalPRV9VSWRmNEM2UG8?resourcekey=0-T9Qgl0EgpBLVv6BJ6lMjFw&usp=sharing |
| - | * **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. | + | ==== Exercitiul 2: Realizarea unei prezentari (40 de minute) ==== |
| - | 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> | + | Imaginați-vă că ar trebui să realizați acum o prezentare pentru unul din produsele urmatoare dezvoltate de echipa voastra: |
| - | git format-patch [optional parameters] > file.patch | + | * **Program pentru afișarea online a mersului trenurilor și achiziția online de bilete pentru o companie de cai ferate**. Programul va include și interfețe pentru gestionarele de la ghișeele clasice de bilete. |
| - | </code> | + | * **Sistem de home-banking** ce permite clienților să folosească servicii online cum ar fi: transfer bancar, schimb valutar, tipărirea de bilanțuri, autorizarea tranzacțiilor online. |
| + | * **Sistem de supraveghere a traficului dintr-o rețea** destinat corporațiilor. Sistemul va permite prin intermediul unei interfețe grafice închiderea accesului la anumite servicii (yahoo, youtube) a căror utilizare în timpul programului de lucru de către angajați nu aduce un beneficiu companiei. De asemenea, va putea afișa și rapoarte despre activitatea web a fiecărui angajat. | ||
| + | Scopul este ca aceasta prezentare sa convinga clientul sa achizitioneze produsul vostru. | ||
| + | Care este structura acestei prezentari? Ce elemente esentiale ar trebui sa contina? Imaginati-va ca ceilalti colegi ai vostri sunt reprezentantii companiei si prezentati-le cat mai atractiv produsul. | ||
| + | <hidden> ==== Exercitiul 3: Logo-uri (30 de minute) ==== | ||
| + | Pe rand, studentii vor folosi https://awwapp.com/ pentru a desena un logo. In cadrul aplicatiei online se poate genera un link catre desen (asistentul poate genera linkul astfel incat oricine sa poata desena pe acelasi canvas sau fiecare persoana care deseneaza partajeaza ecranul sau trimite un link read-only). Ceilalti participanti trebuie sa ghiceaza logo-ul. Persoana care a ghicit preia rolul celui care deseneaza (daca nu a fost deja in acest rol, altfel desemneaza pe cineva care nu a desenat). | ||
| - | === Utilizare patch === | + | Exercitii old/fizic |
| - | 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. | + | Impartiti-va in doua echipe (sau in 3, conform impartirii proiectului 2). |
| - | Utilitarul standard cu care se aplică patch-uri se numește ''patch''. | ||
| - | Modul cel mai întâlnit de utilizare este:<code> | + | Din fiecare echipa, pe rand, se desemneaza cate un membru care se duce la tabla si deseneaza pentru echipa lui cate un logo din cele puse la dispozitie de catre asistent. Scopul este sa il recunoasca ceilalti membri (ca la mima, sau ca la jocul Activity). |
| - | patch -pNUM < filename.patch | + | |
| - | </code> | + | |
| - | ''patch'' își ia fișierul din stdin, de aceea trebuie redirectat fișierul de intrare. | + | </hidden> |
| - | Î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. | + | <hidden> |
| + | Sunt peste 30 de logo-uri din care sa aleaga. See [1]. | ||
| - | De asemenea, un patch poate fi aplicat cu comanda: <code>git am filename.patch</code> | ||
| - | ==== Test Cases ==== | + | [1] https://docs.google.com/document/d/1Cfh8CkTS0VezY7XFX84fSpxuMFyjlIOT1Ls1h_EBb8k/edit?usp=sharing |
| + | </hidden> | ||
| - | 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**. | + | <hidden> In limita timpului |
| - | Un exemplu de test case: | + | ==== Exercitiul 3: Motto-uri ==== |
| + | Analog, doar ca se va primi cate un slogan/motto. Studentii desemnati il vor scrie pe tabla. La fel, scopul este ca fiecare echipa sa ghiceasca (daca se poate) cat mai multe dintre motto-urile propuse. | ||
| - | trebuie verificată funcționarea unei pagini de login care conține un input de user name și unul de parolă | + | Sunt peste 30 de motto-uri. See [2]. |
| - | * 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ă//. | ||
| - | Pe cazul anterior: | + | [2] http://pastebin.com/0EkDi0Rk |
| - | * 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. | ||
| - | Există, ca în orice alt domeniu, tool-uri open source pentru managementul test cases: | + | Doar cand ajung la tabla asistentii vad (eventual le arata asistentul de pe latop/telefon sau ceva, sau le printeaza inainte de curs....) logo-urile sau motto-urile. |
| - | + | ||
| - | * Bugzilla Testopia: http://www.mozilla.org/projects/testopia/ | + | |
| - | * Incremental Scenario Testing: https://sourceforge.net/projects/istt/ | + | |
| - | * QA Traq: http://www.testmanagement.com/ | + | |
| - | + | ||
| - | === Black Box Testing === | + | |
| - | + | ||
| - | 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). | + | |
| - | 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// | + | |
| - | Testarea unui program care la intrare primește un string pe care vrea să îl parseze în | + | |
| - | * număr întreg | + | |
| - | * 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 === | + | |
| - | + | ||
| - | 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. | + | |
| - | Unele teste care fac parte din suita boundary testing sunt "stress tests". | + | |
| - | + | ||
| - | Î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. | + | |
| - | //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.) | + | |
| - | + | ||
| - | Problemele pe care le detectează boundary testing sunt, de obicei: | + | |
| - | * 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 === | + | |
| - | + | ||
| - | * [[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 === | + | |
| - | + | ||
| - | **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. | + | |
| - | + | ||
| - | Există și o abordare **Test Driven Development - TDD** în care se scrie testul pentru unitate înainte de scrierea codului. | + | |
| - | + | ||
| - | == Stubs == | + | |
| - | + | ||
| - | 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. | + | |
| - | + | ||
| - | == 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: | + | |
| - | * 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. | + | |
| - | + | ||
| - | === Regression testing === | + | |
| - | + | ||
| - | "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) | + | |
| - | + | ||
| - | **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. | + | |
| - | + | ||
| - | 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. | + | |
| - | === 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. | + | |
| - | + | ||
| - | Există atât software cât și hardware fault injection. | + | |
| - | + | ||
| - | === HWIFI(Hardware Implemented Fault Injection) === | + | |
| - | + | ||
| - | Există încă din 1970, și implică crearea de scurtcircuite pe placă, generând astfel erori. | + | |
| - | + | ||
| - | === SWIFI(Software Implemented Fault Injection) === | + | |
| - | + | ||
| - | Se împarte în două mari categorii | + | |
| - | # Compile time injection | + | |
| - | # Run time injection | + | |
| - | + | ||
| - | == Compile time injection == | + | |
| - | + | ||
| - | Modificarea de linii de cod la compilare pentru a genera comportamente eronate. | + | |
| - | Ex: a++ poate fi modificat în a--; | + | |
| - | + | ||
| - | == Run time injection == | + | |
| - | + | ||
| - | * Coruperea spațiului de memorie al procesului | + | |
| - | * Interceptarea syscall-urilor și introducerea de erori în ele | + | |
| - | * Reordonarea, coruperea și distrugerea pachetelor de pe rețea. | + | |
| - | + | ||
| - | ==== Platforme de testare ==== | + | |
| - | + | ||
| - | * 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. | + | |
| - | * 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 | + | |
| - | * [[http://docs.python.org/library/unittest.html|Python unittest]] pentru Python. | + | |
| - | ==== 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]]). | + | |
| - | + | ||
| - | === AutoIt === | + | |
| - | + | ||
| - | [[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): | + | |
| - | * apelul unor funcții din DLL-uri Win32 | + | |
| - | * execuția de aplicații (consolă/GUI) | + | |
| - | * creare de interfețe GUI (ferestre de mesaje, atenționare, de introducere de date, etc.) | + | |
| - | * manipulare sunete | + | |
| - | * simulare mișcări de mouse și apăsare taste și combinații de taste | + | |
| - | * manipulare ferestre și procese | + | |
| - | * manipulare elemente în cadrul unei ferestre | + | |
| - | + | ||
| - | 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]] | + | |
| - | + | ||
| - | === Abbot === | + | |
| - | + | ||
| - | [[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. | + | |
| - | + | ||
| - | == Code coverage, Code profiling == | + | |
| - | + | ||
| - | 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 === | + | |
| - | + | ||
| - | 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. | + | |
| - | + | ||
| - | 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. | + | |
| - | + | ||
| - | Î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. | + | |
| - | + | ||
| - | === Code profiling === | + | |
| - | + | ||
| - | 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". | + | |
| - | + | ||
| - | 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). | + | |
| - | + | ||
| - | Î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. | + | |
| - | + | ||
| - | ===== Software Quality Assurance (SQA) ===== | + | |
| - | * 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 === | + | |
| - | + | ||
| - | * metodologia QA a fost introdusă inițial în cadrul fabricilor, unde și-a demonstrat aportul la succesul producției de calitate | + | |
| - | * 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: | + | |
| - | - **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. | ||
| - | * 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 | ||
| - | * http://www.opensourcetesting.org/testmgt.php | ||
| - | * http://www.sqatester.com/documentation/testcasesmpl.htm | ||
| - | * http://www.computerhistory.org/tdih/September/9/ | ||
