CAPITOLUL 4 PLANUL DE TESTARE 4.1.

Elemente generale Prin intermediul unui plan de testare se ofer posibilitatea organizrii resurselor de timp, a celor umane, financiare i materiale cu privire la cum ar trebui s se desfoare i la ce rezultate s ne ateptm de la procesul de testare. PT reprezint un instrument managerial de organizare sistematic a resurselor disponibile i de sistematizare a cunotinelor n vederea derulrii cu succes a procesului de testare n scopul atingerii unor rezultate scontate, pe fondul formulrii unei opinii cu privire la corespondena dintre cerine i realizri. Prin intermediul PT se asigur o modalitate eficien, de cele mai multe ori, de comunicare n interiorul unitii de testare, dar i cu ceilali membrii ai echipei de programare implicate n elaborarea/dezvoltarea unei aplicaii informatice, i nu numai. Din punct de vedere practic e ist dou orientri n conceperea unui plan de testare, i anume! a. Planul de testare integrat (PTI), care se refer la tot procesul de testare, sau la ntregul efort de testare, inclusiv definirea tuturor cazurilor individuale de testare "#$T% & numite adesea set de teste sau suite de teste & pe care le va efectua echipa. b. Plan de testare structurat (PTS) n dou documente! i. un plan de testare propriu'zis ii. un plan al procedurilor de testare, n care se prevd detaliile referitoare la procedurile de testare. (n cazul n care aceeai echip de testare primete ca sarcini de lucru n cadrul procesului de testare s efectueze testarea componentelor, testarea integrat i testarea sistemului, ntro faz avansat a procesului de elaborare a aplicaiei informatice se pune ntrebarea fireasc de cte planuri de testare va fi nevoie) Din descrierea prezentat rezult c sunt trei subproiecte de testare, ceea ce din punct de vedere managerial ar trebui abordate separat prin conceperea a trei planuri de testare coroborate ntre ele, deoarece se refer la! a. Raportarea la perioade di erite de timp. $nformaiile de lucru necesare celor trei proiecte sunt decalate n timp. (n condiiile utilizrii unui singur plan de testare multe din zonele din planul de testare sunt goale "n practic aceste zone libere sunt marcate cu *T+D, & urmeaz a se stabili%, ceea ce n mod firesc vor conduce la o ngreunare a nelegerii acestuia de ctre toi utilizatorii lui. !. Utili"area de metodologii di erite. Discuiile detaliate privind instrumentele de acoperire a codului i cele privind instrumentele de testare -.$ automatizate independente de platform nu prea se mpac. /a fel, n cazul echipamentelor, discuiile privind camerele termice, accelerometrele i testarea compatibilitii aplicaiilor business sunt un amestec prea eterogen pentru un singur plan.

#. $orm%larea %nor o!ie#ti&e di erite. Dac scopul const n ndeplinirea a trei obiective diferite & ca de pild gsirea de erori la componente, gsirea de erori la relaiile i interfeele dintre componentele integrate incremental i gsirea de erori ntr'un sistem complet integrat & scrierea de planuri separate pentru testarea de componente, testarea integrrii i testarea sistemului va a0uta echipa s'i concentreze atenia asupra fiecruia dintre aceste obiective n parte. d. Spe#iali'tii impli#a(i di er) *n %n#(ie de ie#are +%!proie#t *n parte. (n cazul n care apare un singur plan de testare detaliat pe fiecare subproiect, anumite zone din acesta nu vor atrage interesul tuturor participanilor la discuii. nu interseaz nici pe toi membrii echipei de testare i nici pe toi membrii echipei de programare. 1ste important de precizat faptul c utilizarea mai multor planuri de testare ar putea s conduc la apariia unor zone cu informaii comune, ceea ce ar putea nate discuii legate de redundaa informaional, i chiar uneori apariia unor necorelri informaionale. 1ste posibil ca n practic s apar un singur plan central cu subplanuri de testare separate. Din motivaii practice, testerii care scriu planurile de testare recomand a se utiliza notie de lucru sau ciorne de discuii, prin intermediul crora se solicit nformaii, detalii, opinia colegilor de echip, dar i a partenerilor de lucru. 2stfel, n primele variante ale planului de testare apar multe ntrebri, sarcini de efectuat, solicitri de opinii etc, ca n e emplu de mai 0os! 3T+D! De stabilit care este planul de alocare a echipamentelor.4 3T+D! 1chipa responsabil de configurare trebuie s defineasc schema de numerotare a revizuirii i procesrii.4 3T+D! Dle Popescu, v rog s'mi e plicai cum ar trebui s funcioneze acest lucru.4 5 asemenea abordare conduce implicit la eficientizarea planificrii activitilor de testare, cu privire la instrumente, procese, resurse umane i tehnologie. Primele drafturi de plan de testare constituie instrumente eficiente pentru a atrage atenia la probleme i subiecte de dicuii, at6t colegilor, c6t i partenerilor de proces, inclusiv managementului. 4.,. -odel%l IEEE .,/ $n etapa de planificare a testrii se planific n timp componentele unui proiect de testare din cadrul activitilor specifice elaborrii unei aplicaii informatice, pe baza Planului de Testare 7oft8are "7TP%. Planul de testare conform 7tandardului $111 9:; *7oft8are Test Documentation,, trebuie s cuprind urmtoarele seciuni.

Tabel <.=. Paralel structura 7TP conf. $111 9:; i structur sistematizat Cf. IEEE 829
a. #od de identificare a planului de testare !. $ntroducere #. 1lemente de testare d. #aracteristici ce trebuie testate e. #aracteristici ce nu trebuie testate . 2bordare g. #riterii de trecere/picare a testului de ctre elementele testate 0. #riterii de suspendare i cerine de reluare i. >ezultate finale ale testelor 1. 7arcini de testare 2. ?evoi de mediu l. >esponsabiliti m. ?evoi de personal i specializare n. Program o. >iscuri i evenimente neprevzute p. 2probri

Structurat
a. !. #. d. e. . g. 0. i. 1. 2. l. m. $dentificare $ntroducere 1lemente de testare @aciliti de testatA #riteriile de testareA #riteriile de finanlizare cu succes/insuccesA #riteriile de suspendare/reluare a procesului de testareA Teste livrabile "de distribuit%A ?ecesitile mediuluiA 5rganizaia "personal, pregatire, planificare responsabili%A 7arcini i programA >iscurile proiectului de testare 2probri

a. Cod%l de identi i#are a plan%l%i de te+tare este o simpl denumire sau numr de identificare a documentelor. 7e recomand utilizarea denumirii i conveniilor de stocare utilizate de proiect. !. Introd%#erea planurilor de testare $111 9:; permite o prezentare a proiectului de testare, concomitent cu o scurt descriere cu privire la ce se va testa i abordarea general de testare folosit. 7e prefer a se include i scopurile, metodologiile folosite i obiectivele stabilite, pentru a oferi cititorilor o imagine mai clar despre acest plan. Pentru nelegerea sistetic a sarcinii se recomand chiar includerea de imagini sau diagrame simple, arhitectura sistemeului de testat i chiar componente dezasamblate. #. Elementele de te+tare3 Cara#teri+ti#ile #e tre!%ie te+tate 'i Cara#teri+ti#ile #e n% tre!%ie te+tate se refer la domeniul de aplicare. (n ma0oritatea planurilor de testare, domeniul de aplicare implicit este ntreg sistemul, iar testarea se va concentra asupra poriunilor cu risc ridicat din sistemul respectiv, detaliate n seciunile intitulate Domeniul de aplicare i >iscuri privind calitatea. d. (n seciunea A!ordare, planul $111 prezint strategiile de testare utilizate la anumite teste. e. 7eciunile Criteriile de tre#ere4pi#are a te+t%l%i de #)tre elementele te+tate i Criteriile de +%+pendare 'i #erin(ele de rel%are se refer la #riteriile de intrare i #riteriile de ieire i respectiv #riterii de continuare. (n cazul testrilor la un nivel mai sczut, precum testarea componentelor, idea de a defini criterii discrete
3

de trecere/picare a testului de ctre elementele testate este oarecum logic, dar de cele mai multe ori se constat c nu se pot prezenta dec6t informaii agregate n timpul testrii sistemului. . Re"%ltatele inale ale testelor sunt rapoarte privind erorile i rezultatele procedurilor de testare, mpreun cu sisteme de msur agregate. (n unele cazuri, pot e ista i alte rezultate finale. (n cazul n care se cer i alte rezultate finale n afar de rapoarte privind erorile, rezultatele testelor i ale sistemelor de msur, acestea se pot meniona n subseciuni suplimentare adugate la aceeai seciune. g. 7eciunea Sar#ini de te+tare prezint informaii despre procedeele i activitile pe care specialitii cu testarea vor trebui s le ntreprind pentru efectuarea testelor. #u toate acestea, planul $111 poate conine de asemenea probleme de dezvoltare a testelor i configurare a mediului. 0. 7eciunea Ne&oi de medi% se refer direct la configuraiile tehnice i medii de testare. i. 7eciunile Re+pon+a!ilit)(i i Ne&oi de per+onal 'i +pe#iali"are. 1ste necesar a se face o discuie la nivel de echip de testare. 2ceste informaii sunt necesare pentru a obine o imagine a bugetului de timp i de resurs uman. 1. 7eciunile Program i Ri+#%ri se refer la programul de urmat i la evenimente poteniale sau posibile care ar putea ngreuna sau chiar mpiedica efectuarea planificrii testelor. 7ubiectele abordate pot fi nevoile de specializare, disponibilitatea asistenei suplimentare pentru rezolvarea erorilor n cazul unui numr e cepional de erori gsite i aa mai departe. 2ceste informaii pot fi cuprinse i n discuia despre criteriile de continuare.. 2. 7eciunea Apro!)ri din modelul $111 este rezervat beneficiarilor cheie ai efortului de testare & i probabil ai ntregului proiect & care trebuie s'l semneze pentru a semnala c sunt de acord cu planul de testare. 1ste firesc ca orice plan de testare s cuprind aprobarea at6t a managementului de proiect, c6t i a departamentului de dezvoltare. Bodelul planului de testare soft8are recomand soluia utilizrii unei foi de semnturi la sf6ritul planului. (n practic se obinuiete organizarea unei ntruniri de revizuire cu toi managerii implicai n procesul elaborrii. 7olicitarea de semnturi naintea nceperii activitilor de testare poate avea reacii adverse din partea colegilor de la dezvoltare. #um de altfel lipsa semnturilor poate s atrag responsabiliti suplimentare n caz de eec al procesului. 7e poate practica i varianta trimiterii 7TP prin email, cu rugmintea de a se face comentariile corespunztoare ntrun termen rezonabil. /ipsa reaciilor demonstreaz c destinatarii sunt de acord cu 7TP.

4.5. St%di% de #a"

http!//888.gerrardconsulting.com/tCb/guidelines/ieee9:;/e ample.html

T17T P/2? 5.T/$?1 "$111 9:; @ormat% =. Test Plan $dentifier :. >eferences D. $ntroduction E. Test $tems <. 7oft8are >isC $ssues F. @eatures to be Tested G. @eatures not to be Tested 9. 2pproach ;. $tem Pass/@ail #riteria =H. 7uspension #riteria and >esumption >eIuirements ==. Test Deliverables =:. >emaining Test TasCs =D. 1nvironmental ?eeds =E. 7taffing and Training ?eeds =<. >esponsibilities =F. 7chedule =G. Planning >isCs and #ontingencies =9. 2pprovals =;. -lossarJ 7ample Baster Test Plan T17T P/2? $D1?T$@$1>>7'BTPH=.D >1@1>1?#17 ?one $dentified. $?T>5D.#T$5? This is the Baster Test Plan for the >eassigned 7ales >e'8rite pro0ect. This plan 8ill address onlJ those items and elements that are related to the >eassigned 7ales process, both directlJ and indirectlJ affected elements 8ill be addressed. The primarJ focus of this plan is to ensure that the ne8 >eassigned 7ales application provides the same level of information and detail as the current sJstem 8hile allo8ing for improvements and increases in data acIuisition and level of details available "granularitJ%. The pro0ect 8ill have three levels of testing, .nit, 7Jstem/$ntegration and 2cceptance. The details for each level are addressed in the approach section and 8ill be further defined in the level specific plans. The estimated time line for this pro0ect is verJ aggressive "si "F% months%, as such, anJ delaJs in the development process or in the installation and verification of the third partJ soft8are could

have significant effects on the test plan. The acceptance testing is e pected to taCe one "=% month from the date of application deliverJ from sJstem test and is to be done in parallel 8ith the current application process. T17T $T1B7 The follo8ing is a list, bJ version and release, of the items to be tested! 2. 1KT5/ 1D$ pacCage, Lersion D.H $f a ne8 release is available prior to roll'out it 8ill not be used until after installation. $t 8ill be a separate upgrade/update pro0ect. +. D?7 P# 1D$ transaction pacCage, Lersion :.: $f a ne8 release is available prior to roll'out it 8ill not be used until after installation. $t 8ill be a separate upgrade/update pro0ect. #. #ustom P# 1D$ transaction pacCage "t8o distributors onlJ%. D. ?e8 reassigned sales soft8are, initial version to be Lersion =.H 2 detailed listing of programs, databases, screens and reports 8ill be provided in the sJstem and detailed design documents. 1. 5rder 1ntrJ 1D$ interface soft8are, #urrent version at time of pilot. #urrentlJ, version E.=. @. >eassigned 7ales 7Jstem reIuirements document, 77TM>NBT.OPD version E.= -. >eassigned 7ales 7Jstem Design Document, 77TM7P7D.OPD version D.H: Q. >eassigned 7ales Detail Design Document, 77TMDT/D.OPD version D.HE 75@TO2>1 >$7R $77.17 There are several parts of the pro0ect that are not 8ithin the control of the >eassigned 7ales application but have direct impacts on the process and must be checCed as 8ell. The local 27/EHH based vendor supplied 1D$ soft8are pacCage. This pacCage 8ill be providing all the reformatting support from the 2?7$ K=: 1D$ formats to the internal 27/EHH data base file formats. The P# based soft8are pacCage installed at each distributorSs location "both custom 8ritten and vendor supplied% 8ill be providing the formatting of the distributors data into the correct 1D$ K=: formats. +acCup and >ecoverJ of the 1D$ transmission files, local databases and restart of the translation process, must be carefullJ checCed. The abilitJ to restart the application in the middle of the process is a critical factor to application reliabilitJ. This is especiallJ true in the case of the transmission files as once the data is pulled from the mail bo it is no longer available there and must be protected locallJ. Database securitJ and access must be defined and verified, especiallJ for files shared bet8een the 5rder 1ntrJ application and the >eassigned 7ales process. 2ll basic securitJ 8ill be provided through the 27/EHH sJstems native securitJ process. @12T.>17 T5 +1 T17T1D The follo8ing is a list of the areas to be focused on during testing of the application. 2. ?e8 1D$ data acIuisition process. +. >edesigned 5n'line screens. #. >edesigned/#onverted reports. D. ?e8 2utomated 2rchive process. 1. $nterface to the 5rder 1ntrJ sJstem and data bases. @. #omputation of 7ales 2ctivitJ bJ region for commissions. @12T.>17 ?5T T5 +1 T17T1D The follo8ing is a list of the areas that 8ill not be specificallJ addressed. 2ll testing in these areas 8ill be indirect as a result of other testing efforts. 2. ?on'1D$ 5rder 1ntrJ processes. 6

5nlJ the 1D$ interface of the 5rder 1ntrJ application 8ill be verified. #hanges to the 1D$ interface to support >eassigned 7ales are not anticipated to have an impact on the 5rder Processing application. 5rder 1ntrJ is a separate application sharing the data interface onlJ, orders 8ill continue to process in the same manner. +. ?et8orC 7ecuritJ and dial'in access. #hanges to include 1D$ transactions for reassigned sales 8ill have no impact on the securitJ aspects of the net8orC or the 1KT5//1D$ interface. #. 5perational aspects of the 1D$ process. #hanges to include 1D$ transactions for reassigned sales 8ill have no impact on the operational aspects of the 1KT5//1D$ interface. D. P# based spreadsheet analJsis applications using >eassigned 7ales data. These applications are completelJ under the control of the customer and are outside the scope of this pro0ect. The necessarJ data base format information 8ill be provided to the customers to allo8 them to e tract data. Testing of their applications is the responsibilitJ of the application maintainer/developer. 1. +usiness 2nalJsis functions using >eassigned 7ales data. These applications are completelJ under the control of the management support team and are outside the scope of this pro0ect. The necessarJ data base format information 8ill be provided to the support team to allo8 them to e tract data. Testing of their applications is the responsibilitJ of the application maintainer/developer. @. BarCeting/@orecasting processes using >eassigned 7ales data. These applications are completelJ under the control of marCeting and are outside the scope of this pro0ect. The necessarJ data base format information 8ill be provided to marCeting to allo8 them to e tract data. Testing of their applications is the responsibilitJ of the application maintainer/developer. 2PP>52#Q Testing /evels The testing for the >eassigned 7ales pro0ect 8ill consist of .nit, 7Jstem/$ntegration "combined% and 2cceptance test levels. $t is hoped that there 8ill be at least one full time independent test person for sJstem/integration testing. Qo8ever, 8ith the budget constraints and time line establishedA most testing 8ill be done bJ the test manager 8ith the development teams participation. .?$T Testing 8ill be done bJ the developer and 8ill be approved bJ the development team leader. Proof of unit testing "test case list, sample output, data printouts, defect information% must be provided bJ the programmer to the team leader before unit testing 8ill be accepted and passed on to the test person. 2ll unit test information 8ill also be provided to the test person. 7P7T1B/$?T1->2T$5? Testing 8ill be performed bJ the test manager and development team leader 8ith assistance from the individual developers as reIuired. ?o specific test tools are available for this pro0ect. Programs 8ill enter into 7Jstem/$ntegration test after all critical defects have been corrected. 2 program maJ have up to t8o Ba0or defects as long as theJ do not impede testing of the program "$.1. there is a 8orC around for the error%. 2##1PT2?#1 Testing 8ill be performed bJ the actual end users 8ith the assistance of the test manager and development team leader. The acceptance test 8ill be done in parallel 8ith the e isting manual T$P/@2K process for a period of one month after completion of the 7Jstem/$ntegration test process.

Programs 8ill enter into 2cceptance test after all critical and ma0or defects have been corrected. 2 program maJ have one ma0or defect as long as it does not impede testing of the program "$.1. there is a 8orC around for the error%. Prior to final completion of acceptance testing all open critical and ma0or defects B.7T be corrected and verified bJ the #ustomer test representative. 2 limited number of distributors 8ill participate in the initial acceptance test process. 5nce acceptance test is complete, distributors 8ill be added as their abilitJ to generate the reIuired 1D$ data is verified and checCed against their @2K/T$P data. 2s such, some distributors 8ill be in actual production and some in parallel testing at the same time. This 8ill reIuire careful coordination of the control tables for the production sJstem to avoid posting test data into the sJstem. #onfiguration Banagement/#hange #ontrol Bovement of programs from the development portion of the U>1DV sJstem to the test portion of the U>1DV sJstem 8ill be controlled through the e isting #onfiguration Banagement application process, U1KT>2#TV. This 8ill ensure that programs under development and those in full test 8ill have the same version controls and tracCing of changes. The same e tract process 8ill be used to migrate the programs from the Development/Test U>1DV sJstem to the production U+/.1V sJstem once all testing has been completed according to published plans and guidelines. 2ll .nit and initial sJstem testing 8ill be performed on the Development 27/EHH U>1DV sJstem. 5nce the sJstem has reached a reasonable level of stabilitJ, no critical or ma0or defects outstanding, initial pilot testing 8ill be done on the production 27/EHH U+/.1V sJstem. 2ll testing done on the U+/.1V sJstem 8ill be done in a parallel mode 8ill all controls set to prevent actual updating of the production files. This 8ill allo8 some earlJ testing of the numbers received through the old T$P/@2K process and the higher level of detail received through the ne8 1D$ process. This 8ill also help identifJ potential problems 8ith the comparison of the t8o sets of numbers. 2ll changes, enhancements and other modification reIuests to the sJstem 8ill be handled through the published change control procedures. 2nJ modifications to the standard procedures are identified in the pro0ect plan change control section. Test Tools The onlJ test tools to be used are the standard 27/EHH provided utilities and commands. 2. The Program Development Banager "PDB% 8ill be used as the source version configuration management tool in con0unction 8ith the in'house checC'in/checC'out control utilitJ. The checC' in/out utilitJ is part of each developers standard 27/EHH access menu. +. The initial prototJpes for the ne8 screens 8ill be developed using the 27/EHH 7creen Design 2id "7D2%. The initial laJout and general content of the screens 8ill be sho8n to the sales administration staff prior to proceeding 8ith testing and development of the screens. #. 2ll editing, compiling and debugging 8ill be done using the 7ource 1ntrJ .tilitJ "71.%. D. Data acIuisition 8ill be from actual production files 8here available using the 27/EHH data base copJ command #PP@ and itSs various functions. 2dditional data 8ill be created and modified as needed using the Data @ile .tilitJ "D@.%. ?o changes 8ill ever be made to actual production files under anJ circumstances. 1. $nitial data for 1D$ testing 8ill be done using one or t8o beta sites and replicating the data at the mailbo location or locallJ in the control files, to create high volume data and to simulate multiple distributors sending in data. Beetings The test team 8ill meet once everJ t8o 8eeCs to evaluate progress to date and to identifJ error trends and problems as earlJ as possible. The test team leader 8ill meet 8ith development and the

pro0ect manager once everJ t8o 8eeCs as 8ell. These t8o meetings 8ill be scheduled on different 8eeCs. 2dditional meetings can be called as reIuired for emergencJ situations. Beasures and Betrics The follo8ing information 8ill be collected bJ the Development team during the .nit testing process. This information 8ill be provided to the test team at program turnover as 8ell as be provided to the pro0ect team on a bi8eeClJ basis. Defects bJ module and severitJ. Defect 5rigin ">eIuirement, Design, #ode% Time spent on defect resolution bJ defect, for #ritical W Ba0or onlJ. 2ll Binor defects can be totaled together. The follo8ing information 8ill be collected bJ the test team during all testing phases. This information 8ill be provided on a bi8eeClJ basis to the test manager and to the pro0ect team. Defects bJ module and severitJ. Defect 5rigin ">eIuirement, Design, #ode% Time spent on defect investigation bJ defect, for #ritical W Ba0or onlJ. 2ll Binor defects can be totaled together. ?umber of times a program submitted to test team as readJ for test. Defects located at higher levels that should have been caught at lo8er levels of testing. $T1B P277/@2$/ #>$T1>$2 The test process 8ill be completed once the initial set of distributors have successfullJ sent in reassigned sales data for a period of one month and the ne8 1D$ data balances 8ith the old T$P/@2K data received in parallel. Ohen the sales administration staff is satisfied that the data is correct the initial set of distributors 8ill be set to active and all parallel stopped for those accounts. 2t this point the ne t set of distributors 8ill begin the parallel process, if not alreadJ doing so. 5nlJ the initial set of distributors must pass the data comparison test to complete the testing, at that point the application is considered live. 2ll additional activations 8ill be on an as readJ basis. Ohen a distributor is readJ, and their data is verified, theJ 8ill then also be activated. 7.7P1?7$5? #>$T1>$2 2?D >17.BPT$5? >1N.$>1B1?T7 2. ?o Distributors are readJ for testing at pilot initiation. The pilot pro0ect 8ill be delaJed until at least three Distributors are readJ to initiate the pilot process. ?o additional elements 8ill be added to the >eassigned 7ales pro0ect during this delaJ. +. .navailabilitJ of t8o 1D$ mail bo es. $n the event t8o production lines and mail bo facilities cannot be obtained the current single production line and mail bo 8ill continue to be used until a second line becomes available. This 8ill necessitate careful coordination bet8een the 5rder 1ntrJ department and the >eassigned 7ales group. #. Distributor P# 1D$ soft8are delaJs. $n the event of a delaJ in the deliverJ or availabilitJ of the P# soft8are pacCage, the onlJ ma0or delaJ 8ill be in pilot testing. .nit, $ntegration and 7Jstems testing can continue using limited data until such time as the P# soft8are is readJ. This 8ill also add time to the lo8er levels of testing as full complete testing cannot be done 8ithout reasonable amounts of data. The data can onlJ be derived from actual transmissions from the P# soft8are pacCage. T17T D1/$L1>2+/17 2cceptance test plan 7Jstem/$ntegration test plan 9

.nit test plans/turnover documentation 7creen prototJpes >eport mocC'ups Defect/$ncident reports and summaries Test logs and turnover reports >1B2$?$?- T17T T27R7

T27R
#reate 2cceptance Test Plan #reate 7Jstem/$ntegration Test Plan Define .nit Test rules and Procedures Define Turnover procedures for each level LerifJ prototJpes of 7creens LerifJ prototJpes of >eports

2ssigned To
TB, PB, #lient TB, PB, Dev. TB, PB, Dev. TB, Dev

7tatus

Dev, #lient, TB Dev, #lient, TB

1?L$>5?B1?T2/ ?11D7 The follo8ing elements are reIuired to support the overall testing effort at all levels 8ithin the reassigned sales pro0ect! 2ccess to both the development and production 27/EHH sJstems. @or development, data acIuisition and testing. 2 communications line to the 1D$ mailbo facilitJ. This 8ill have to be a shared line 8ith the 5rder 1ntrJ process as onlJ one mailbo is in use. There 8ill have to be a coordinated effort to determine ho8 often to poll the mailbo as the order entrJ process reIuires that data be accessed everJ hour and the sales process reallJ onlJ needs to be pulled once a daJ. 2n installed and functional copJ of the 27/EHH based 1D$ vendor pacCage. 2t least one distributor 8ith an installed copJ of the P# based 1D$ vendor pacCage for sales data. 2ccess to the master control tables "data bases% for controlling the production/testing environment on both production and development sJstems. 2ccess to the nightlJ bacCup/recoverJ process. 7T2@@$?- 2?D T>2$?$?- ?11D7 $t is preferred that there 8ill be at least one "=% full time tester assigned to the pro0ect for the sJstem/integration and acceptance testing phases of the pro0ect. This 8ill reIuire assignment of a person part time at the beginning of the pro0ect to participate in revie8s etc... and appro imatelJ four months into the pro0ect theJ 8ould be assigned full time. $f a separate test person is not available the pro0ect manager/test manager 8ill assume this role. $n order to provide complete and proper testing the follo8ing areas need to be addressed in terms of training. The developers and tester"s% 8ill need to be trained on the basic operations of the 1D$ interface. Prior to final acceptance of the pro0ect the operations staff 8ill also reIuire complete training on the 1D$ communications process.

10

The sales administration staff 8ill reIuire training on the ne8 screens and reports. 2t least one developer and operations staff member needs to be trained on the installation and control of the P# based distributors 1D$ pacCage. The distributors personnel 8ill also have to be trained on the P# based pacCage and its operational characteristics. >17P5?7$+$/$T$17

2ctivitJ
2cceptance test Documentation W 1 ecution 7Jstem/$ntegration test Documentation W 1 ec. .nit test documentation W e ecution 7Jstem Design >evie8s Detail Design >evie8s Test procedures and rules 7creen W >eport prototJpe revie8s #hange #ontrol and regression testing

TB
K

PB
K

Dev Team

Test Team
K

#lient
K

K K K K K K K

K K K K K

K K K K K K K K K

The development team leader 8ill be responsible for the verification and acceptance of all unit test plans and documentation. The pro0ect manager/test manager is responsible for all test plans and documentation. The entire pro0ect team 8ill participate in the revie8 of the sJstem and detail designs as 8ell as revie8 of anJ change reIuests that are generated bJ the user or as a result of defects discovered during development and testing. The sales administration staff is also reIuired to participate in the initial high'level sJstem revie8. The sales administration staff 8ill provide a person, as reIuired, throughout the pro0ect to verifJ test results and ans8er Iuestions as theJ arise. This person 8ill also be responsible for participating in the e ecution of the acceptance test plan. 7#Q1D./1 Time has been allocated 8ithin the pro0ect plan for the follo8ing testing activities. The specific dates and times for each activitJ are defined in the pro0ect plan time line. The persons reIuired for each process are detailed in the pro0ect time line and plan as 8ell. #oordination of the personnel reIuired for each tasC, test team, development team, management and customer 8ill be handled bJ the pro0ect manager in con0unction 8ith the development and test team leaders. >evie8 of >eIuirements document bJ test team personnel "8ith other team members% and initial creation of $nventorJ classes, sub'classes and ob0ectives.

11

Development of Baster test plan bJ test manager and test 8ith time allocated for at least t8o revie8s of the plan. >evie8 of the 7Jstem design document bJ test team personnel. This 8ill provide the team 8ith a clearer understanding of the application structure and 8ill further define the $nventorJ classes, sub'classes and ob0ectives. Development of 7Jstem/$ntegration and 2cceptance test plans bJ test manager and other essential personnel 8ith time allocated for at least t8o revie8s of the plans. >evie8 of the Detail design document"s% bJ test team personnel as reIuired. This 8ill provide the team 8ith a clearer understanding of the individual program structure and 8ill further define the $nventorJ classes, sub'classes and ob0ectives. .nit test time 8ithin the development process. Time allocated for both 7Jstem/$ntegration and 2cceptance test processes. P/2??$?- >$7R7 2?D #5?T$?-1?#$17 /imited >eassigned 7ales staff The >eassigned 7ales administration staff currentlJ has t8o positions unfilled. 2s a result of this staff shortage there maJ be delaJs in getting staff to revie8 appropriate documents and to participate in the 2cceptance test process. 7hould client staff become a problem, the appropriate dates for revie8s and acceptance testing 8ill slip accordinglJ. ?o attempt 8ill be made to bJpass anJ part of the revie8 and testing processes. Qo8ever, if acceptable to the >eassigned 7ales staff administrator, a member if the test team mJ be available to act as the clientVs representative for part of the 2cceptance test itself. The revie8s of the screens and reports must have #lient participation and approval. 2PP>5L2/7 Pro0ect 7ponsor ' 7teve 7ponsor Development Banagement ' >on Banager 1D$ Pro0ect Banager ' PeggJ Pro0ect >7 Test Banager ' Dale Tester >7 Development Team Banager ' Dale Tester >eassigned 7ales ' #athJ 7ales 5rder 1ntrJ 1D$ Team Banager ' Xulie 5rder

4.4. Un model pra#ti# de STP (n practic se folosesc variante ale modelului de 7TP $111 9:;. Prezentm n cele ce urmeaz un model care mbin practica n domeniu cu cerinele 7tandardului $111 9:;. 7eciunile avute n vedre sunt urmtoarele! 1. Generaliti

12

2. Li itarea adresa!ilitii a. 7copuri ' Domeniul de aplicare b. Definiii c. Parametrizri ' /ocalizare ". #iscuri $ri%ind calitatea &. Pr'$uneri de $uncte c(eie ). Tran*iii a. #riterii de intrare b. #riterii de oprire c. #riterii de ieire +. C'nfiguraii ,i edii de testare -. .e*%'ltarea de teste 8. Efectuarea testel'r a. Participani cheie b. .rmrirea procedurilor de testare i a erorilor c. $zolarea i clasificarea erorilor d. Banagementul noilor ediii e. #icluri de testare f. 5re de testare 9. #iscuri ,i e%eni ente ne$re%*ute 1/. Ist'ricul sc(i !ril'r 11. #eferine la d'cu ente 12. 0ntre!ri frec%ente 6eneralit)(i 7eciunea de generaliti a planului de testare permite s se prezinte cititorilor planului proiectul de testare, inclusiv ce se va testa i abordarea general de testare folosit. (n aceast seciune se pot descrie pe scurt i beneficiile testrii, pentru a clarifica cititorului anumite semne de ntrebare ulterioare. Tot n aceast seciune se e plic pe scurt scopurile, metodologiile i obiectivele. 7e recomand includerea de imagini i diagrame simple i chiar arhitectura sistemului de testat. Limitarea adre+a!ilit)(ii (n aceast seciune, sunt stabilite limitele de adresabilitate a planului de testare, e plic6nd ce se va testa i ce nu, definind termenii i acronimele importante legate de testele care se vor efectua, cu precizarea clar a conte tului c6nd vor aprea i a oricror altor limite, de la caz la caz. a. Domeni%l de apli#are Dicionarul Webster definete domeniul de aplicare, n cazul unui proiect sau a unei operaii, ca fiind ,sfera de tratare, activitate, influen, funcionare,. Descriind domeniul de aplicare a proiectului, se realizeaz de fapt o delimitare a subiectelor pe care le vom aborda pe durata proiectului. 2desea se poate apela la un tabel cu ,1ste, i *?u este,

13

pentru a defini domeniul testrii, coloana *1ste, conine elementele incluse ntr'o anumit faz de testare, iar coloana *?u este, se precizeaz elementele care nu sunt acoperite de respectivul efort de testare. (n tabelul urmtor se prezint un e emplu de astfel de tabel utilizat pentru a descrie domeniul testrii sistemului 7peedJ Oriter n baza analizei de risc efectuate anterior. Ta!el%l. 7.,. Tabelul cu *17T1, i *?. 17T1, de prezentare a domeniului proiectului de testare ESTE NU ESTE @uncionalitate #onversie de fiiere Depistarea erorilor "doar spaniol, francez Depistarea erorilor "altele dec6t spaniol, i german% francez i german% #apacitate i volum #ompatibilitatea reelei 2cces comun la fiiere de baz 5piuni de acces comun la fiiere n reea 5piuni de configurare 7ecuritate sau confidenialitate $nstalare, configurare iniial, actualizare i 2plicabilitate, inclusiv studii de timp i dezinstalare micare Performane Banagementul datelor calendaristice #ompatibilitate i funcionalitate Oindo8s, 57/:, .ni "n afar de 7olaris i /inu % .ni "7olaris, /inu % i Bac sau alte platforme #onformitate la standarde Testare structural Banagementul i restabilirea dup corectarea erorilor $nterfa utilizator "funcional% #ompatibilitate bro8ser 8eb Testare comportamental Testare beta de clieni 2ceast form compact de prezentare permite precizarea e act a domeniului de aplicare. De regul, la acest moment al desfurrii proiectului, nu este necesar definirea fiecrui punct din lista de mai susA detaliile fiecrui aspect de testare sunt incluse n procedurile de testare propriu'zise. !. De ini(ii #a i celelalte discipline informatice, testarea are proprii termeni i e presii. Din acest motiv, planurile de testare pot conine un tabel cu definiii, pentru a clarifica terminologia pentru cei care nu sunt familiarizai cu testarea i de asemenea pentru a avea sigurana c toat echipa de testare folosete acelai set de definiii. #. Lo#ali"are 2ceast seciune a planului de testare se refer la locul unde se vor derula activitile de testare, precum i relaiile dintre organizaiile care o efectueaz i restul organizaiei. 1 ist i cazuri n care testarea se desfoar n mai multe locuri.
14

Ri+#%ri pri&ind #alitatea 7e recomand a se realiza un rezumat al documentelor privind riscurile de calitate delimitate din activitile de documetare sau procurate, pentru a face referire la acestea n planul de testare. 1ste de preferat s se realizeze i o sintez a acestor riscuri pentru acei participani care nu vor citi. Tot n aceast seciune se pot prezenta aspecte legate de strategia de testare i mediile de testare, n funcie de diversele categorii de riscuri. 7pre e emplu, dac se cunoate c se va utiliza o anumit configuraie de server pentru a realiza n principal teste comportamentale manuale, pentru a descoperi eventuale erori de funcionare "pentru a atenua riscurile de calitate n privina funcionalitii%, atunci unul din r6ndurile tabelului cu riscuri de calitate se va completa astfel. Ta!el%l 7.5 1 tras dintr'un tabel de riscuri de calitate #ategoria riscului de calitate #onfiguraia serverului @uncionalitate 7olaris/5racle/2pache 7trategia de testare Banual #omportamental $nde at primar .nele de e plorare

Prop%neri de p%n#te #0eie .n plan de testare trebuie s cuprind un $r'gra cu punctele cheie cele mai importante ale proiectului de testare, precum i termenele limit vizibile din punctul de vedere al conducerii. (n Tabelul de mai 0os se prezint un e emplu de program. Ta!el%l 7.4. 1 emplu de program dintr'un plan de testare Punct cheie Data .e*%'ltarea ,i c'nfigurarea testel'r Plan de testare ncheiat ;/9/:H== /aborator de testare definit =:/9/:H== 2naliza efectelor i a modului de eec =F/9/:H== /aborator de testare configurat :F/9/:H== 7uit de teste ncheiat </;/:H== E1ecutarea testului $ntrare testare sistem :/;/:H== #iclul = ncheiat =F/;/:H== #iclul : ncheiat D/=H/:H== #iclul D ncheiat =D/=H/:H== $eire testare sistem =D/=H/:H== Tran"i(ii

15

Pentru ca fiecare faz de testare s fie eficient, sistemul testat trebuie s ndeplineasc o serie minim de condiii. 2ceast seciune a planului de testare trebuie s specifice criteriile eseniale ce trebuie ndeplinite la nceperea i ncheierea diverselor faze ale testrii "i n vederea pstrrii eficienei procesului de testare%. 2cestea se regsesc n practic cu denumirea de criterii de intrare, ieire i continuare, ns ali profesioniti din domeniul testrii prefer termenii de criterii de intrare, oprire i ntrerupere/reluare. #6nd scriei criteriile fazelor de testare i tranziie, avei gri0 cum v e primai! *Dac cineva din afara echipei de testare nu respect aceste reguli, vom solicita nenceperea acestei faze de testare, oprirea acestei faze de testare sau vom sugera ntreruperea proiectului,. Dei acestea sunt criterii tehnice, invocarea lor poate conduce la un adevrat rzboi. 7e recomand s se includ numai criterii pentru care avem convingerea c pot afecta n mod serios capacitatea echipei de a furniza servicii utile proiectului. 1ficiena echipei de testare este mai important pentru proiect dec6t prote0area orgoliilor echipei de testare, de aceea se evit cu gri0 criteriile care ar putea fi interpretate ca fiind o modalitate de a pasa munca altor departamente. (n fine, c6nd au loc punctele cheie ale fazei de testare & n special edinele de intrare i ieire n/din faza respectiv & se vor msura e plicit performanele proiectului n funcie de criteriile stabilite i se realizeaz o dare de seam n felul de mai sus. 7e pot folosi i culor pentru evidenierea gradului de ndeplinire a criteriilor, astfe criteriile *verzi, "complet ndeplinite%, *galbene, "ndeplinite parial, dar poate nu problematice% sau *roii, "nendeplinite i care pun o problem ma0or%, invoc6nd informaiile de care am nevoie pentru a 0ustifica criteriile *galbene, sau *roii,. $nformaiile ce dovedesc nesatisfacerea unui criteriu sunt eseniale i trebuie s fac referire la o realitate economic important. 7e poate uor observa c la criteriile de intrare, continuare i ieire c orice criteriu rezonabil este de regul acceptabil i acceptat la edina de revizuire a planului de testare, dar dac criteriul respectiv nu este ancorat ntr'un motiv economic solid de nt6rziere a proiectului, acesta va crea tot felul de controverse atunci c6nd este invocat. .nele persoane se folosesc de criterii de ieire dur i rapid legat de erori, precum *gravitate zero = eroare,, *gravitate =H sau mai mic : erori, i aa mai departe. 5nsiderm c aceste abordri pot conduce la argumente contraproductive legate de clasificarea corect a unei erori din punctul de vedere al gravitii, ignor6ndu'se chestiuni mai importante precum calitatea i felul n care calitatea i gsete locul n r6ndul celorlalte componente economice precum programul, bugetul sau caracteristicile. #u toate acestea, utilizarea de criterii de ieire cuantificabile ar putea fi necesar n unele conte te & de pild, sistemele critice, sisteme de aprare, dezvoltarea e ternalizrii etc. a. Criterii de intrare #riteriile de intrare menioneaz evenimentele ce trebuie s aib loc pentru a permite unui sistem s treac la o anumit faz de testare. 2ceste criterii trebuie s rspund la ntrebri de genul!

16

7unt disponibile informaiile necesare privind documentaia, proiectarea i cerinele de ndeplinit, care s le permit membrilor echipei de testare s utilizeze sistemul i s testeze corectitudinea comportamentului acestuia) 7istemul este pregtit pentru livrare n forma adecvat fazei de testare n desfurare)= 7unt disponibile subprogramele destinate s simplifice operaiile e ecutate i accesoriile indispensabile n forme n care pot fi utilizate de echipa de testare) 7istemul are nivelul de calitate necesar) 2ceast ntrebare implic de regul c o parte din sau toate fazele de testare precedente au fost efectuate cu succes, dei se poate referi i la felul n care au fost gestionate problemele de revizuire a codului. 5 alt metod frecvent de msurare a nivelului de calitate ce permite trecerea la o alt faz de testare este efectuarea unui prim test general. Bediul de testare & laboratorul, echipamentele, programele informatice, asistena administratorilor de sistem & este pregtit)

@igura = prezint un e emplu de criterii de intrare ce s'ar putea aplica unei aplicaii. Criterii de #ontin%are #riteriile de continuare descriu condiiile i situaiile preponderente din procesul de testare care permit continuarea eficient a testrii. (n opinia mea, mediul de testare trebuie s rm6n stabil, lista cu erori uor de gestionat, ma0oritatea testelor neblocate "de e emplu de erori ma0ore%, trebuie s e iste rapoarte regulate i e acte privind testele instalabile i stabile, iar modificrile sistemului testat trebuie s fie cunoscute i controlate. @igura = prezint un e emplu de criterii de continuare ce s'ar putea aplica 7peedJOriter. Criterii de ie'ire #riteriile de ieire se refer la determinarea momentului n care testarea s'a ncheiat. De e emplu, un criteriu de ieire ar putea fi faptul c s'au derulat toate procedurile de testare i toate testele de regresie planificate. .n altul ar fi faptul c managerul de proiect consider rezultatele testelor *5R, , oricare ar fi felul n care e prim acest lucru. "(n $ig%ra 1 #riterii de intrare n 7peedJOriter Testarea sistemului poate ncepe dac! a.7istemele de eviden a erorilor i a testelor sunt funcionale. b.Toate componentele se gsesc sub control formal, de configurare automat i management al noilor ediii.
1

(n faza de testare a componentelor "presupun6nd c organizaia de testare este implicat la acel moment%, accept de regul orice fel de ansamblu pregtit, at6t timp c6t are suficient eafoda0 care s'mi permit derularea testelor. Totui, odat a0uns la faza de testare a sistemului, solicit prelucrarea clienilor, mai ales n cazul programelor informatice, ale cror instalare are un impact semnificativ asupra funcionrii sau nu a sistemului.

17

c.1chipa de operaii a configurat mediul serverului de testare de sisteme, inclusiv toate componentele i subsistemele int. 1chipa de testare are acces corespunztor la aceste sisteme. d. 1chipele de dezvoltare au realizat toate caracteristicile i reparaiile de erori programate pentru difuzare. e. 1chipele de dezvoltare au fcut teste de unitate la toate caracteristicile i toate reparaiile de erori programate pentru difuzare. f. Bai puin de <H de erori obligatoriu de reparat "la departamentele de v6nzri, marCeting i service clieni% sunt deschise conform primei ediii a testului. "<H fiind numrul de rapoarte de erori ce pot fi eficient revizuite n cadrul unei ntruniri de o or de triere a erorilor.% g. 1chipele de dezvoltare furnizeaz programele informatice echipei de testare cu trei zile lucrtoare nainte de nceperea testrii sistemului. h. 1chipa de testare realizeaz un test general de trei zile i prezint rezultatele n cadrul ntrunirii de intrare n faza de testare a sistemului. i. 1chipa de management al proiectului decide continuarea operaiunilor, n cadrul unei ntruniri de intrare n faza de testare a sistemului. .rmtoarele subiecte trebuie dezbtute n cadrul aceste ntruniri! ' Dac s'a ncheiat codul. ' Dac s'a ncheiat testarea de uniti. ' 7e stabilete un termen limit de reparare a tuturor erorilor obligatoriu de reparat cunoscute "fr a depi o sptm6n de la intrarea n faza de testare a sistemului%. $ig%ra , #riterii de continuare a 7peedJOriter Testarea sistemului poate continua dac! a. Toate programele informatice puse la dispoziia echipei de testare sunt nsoite de note de nsoire. b. ?u se fac nici un fel de modificri la sistem, fie c este vorba de codul surs, de fiierele de configurare sau de alte instruciuni sau procese de monta0, fr o dare de seam nsoitoare privind eroarea. Dac totui o astfel de modificare se efectueaz i nu este nsoit de o astfel de dare de seam, managerul de testare va iniia urgent o astfel de dare de seam n care va cere informaii i o va trimite superiorului su. c. 1videnele deschise de erori ",diferena calitativ,% rm6n mai puine de <H. Durata medie rmas de nchidere a unei erori este mai mic de =E zile. d. 2u loc ntruniri bisptm6nale de revizuire a erorilor "n cadrul comisiei de control al schimbrilor% p6n la ieirea din faza de testare a sistemului, n vederea gestionrii evidenelor deschise de erori i a timpilor de nchidere a erorilor. $ig%ra 5 #riterii de ieire din testarea sistemului 7peedJOriter Testarea sistemului ia sf6rit c6nd! a.?u s'au efectuat nici un fel de modificri "proiectare/cod/caracteristici%, cu e cepia rezolvrii defectelor testrii sistemului, n cele trei sptm6ni anterioare. b.?u s'au petrecut nici un fel de evenimente de cderi, opriri, pene, terminri brute ale proceselor sau alte tipuri de ntreruperi ale procesului de prelucrare, pe nici un server, program informatic sau echipament, n cele trei sptm6ni anterioare.
18

c.?ici un sistem de clieni nu a devenit inoperabil din cauza vreunei actualizri euate n timpul testrii sistemului. d.1chipa de testare a efectuate toate testele planificate pe programele informatice candidate -2. e.1chipele de dezvoltare au rezolvat toate erorile obligatoriu de reparat de la departamentele de v6nzri, marCeting i service clieni. f.1chipa de testare a verificat dac toate problemele din sistemul de urmrire a erorilor sunt nchise sau am6nate i, dac este cazul, verificate prin teste de regresie i teste de confirmare. g.7istemele de msur a testelor atest c produsele sunt stabile i fiabile, c s'au ncheiat toate testele planificate, iar testele planificate acoper n mod corespunztor riscurile eseniale de calitate. h.1chipa de management al proiectului certific faptul c produsul, definit n timpul ciclului final al testrii sistemului, satisface ateptrile rezonabile de calitate ale clientului. i.1chipa de management al proiectului organizeaz o ntrunire de ieire din faza testrii sistemului. Con ig%ra(ii 'i medii de te+tare 2ceast seciune a planului de testare este rezervat documentrii echipamentelor, programelor informatice, reelelor i laboratoarelor pe care se vor utiliza pentru a efectua testele. 2ici sunt descrise de asemenea cele mai importante detalii privind configuraiile acestor diverse sisteme de testat. (n cazul unei aplicaii sau subprogram al unui computer personal, aceast sarcin poate consta n simpla menionare a celor apro imativ ase computere personale de testat, a celor dou sau trei reele de testat "dac este cazul%, precum i a imprimantelor, modemurilor, adaptoarelor de terminal i a altor accesorii de care utilizaorul ar putea avea nevoie. (n cazul programelor informatice sau a echipamentelor comerciale, este util s dispunem de sistemele similare cu cele ale concurenei ca platforme de referin. De e emplu, la testarea unui dispozitiv de $nternet "doar cu caracteristici de 8eb i e'mail%, configurm computerele personale cu diferite bro8sere i e'mail'uri de clieni pentru a putea rspunde la ntrebarea *#e se nt6mpl c6nd rulm acelai test cu a0utorul K "bro8ser sau e'mail client%), n cazul apariiei unor eventuale erori la dispozitiv. Totui, s presupunem c testai un sistem cu multe echipamente personalizate "precum un nou computer portabil sau un server%, unul cu multe echipamente "ca de e emplu un sistem de operare n reea sau o aplicaie n reea%, sau unul cu echipamente scumpe "precum un sistem mainframe, un server cu disponibilitate mare sau un fascicul de severe%. (n aceste situaii comple e, un simplu tabel sau o simpl foaie de calcul s'ar putea s nu fie suficient. 1ste necesat s se e tind aceast baz de date pentru a include laboratorul i uneltele de gestionare. 2ceast baz de date schieaz de asemenea nevoie de resurse umane i de reea. 1 trase din aceast baz de date pot fi incluse n aceast seciune a planului de testare.

19

#6nd este vorba de echipamente personalizate, se poate prezenta o schem de alocare a echipamentelor fie n aceast parte a planului de testare, fie ntr'un document separat. Planul de alocare este e trem de important. 2 nu elabora un plan detaliat de alocare a echipamentelor echivaleaz cu a presupune c toate echipamentele de care avem nevoie vor fi la dispoziia echipei de testare, n configuraia dorit i pregtite de testare, e act n momentul n care am nevoie de ele. (n ce const un plan de alocare a echipamentelor de testare) De obicei este o list cu scopul sau utilitatea testului, sistemele necesare "inclusiv cantitile i nivelurile de revizuire%, infrastructura, durata, locul i orice alte echipamente necesare pentru un anumit test. Tabelul <.< prezint un plan de alocare de prototip pentru testul de integrare a componentelor unei aplicaii i fazele testrii sistemului. Ta!el%l 7.7 Plan de alocare a echipamentelor
.tilizare test 7istem "cant.% $a"a te+t%l%i de integrare $nterfee Prototip componente/ tehnic ":% calitate semnal >eea 5re /oc /ab. engr. 2ltele "cant.% B7 mouse, B7 Cbd, L-2 mon, .7+ mouse, .7+ mon, .7+ Cbd, D#5B /2?, .7> mdm, 1pson prn, Nuantum QD, osciloscop ?ici una B7 mouse, L-2 mon B7 mouse, B7 Cbd, L-2 mon, Nuantum QD, $+B QD B7 mouse, B7 Cbd, L-2 mon, B.K B7 mouse, B7 Cbd, L-2 mon, .7+ mouse, .7+ mon, .7+ Cbd, .7> mdm, 1pson prn, $7D? T. adptr B7 mouse, L-2 mon B7 mouse, B7 Cbd, L-2 mon, Nuantum QD, $+B QD B7 mouse "D%, B7 Cbd "D%, L-2 mon ?ovell ;/=<'=H/=< ?etOare ?et8orC @ile 7Jstem Bicrosoft Oindo8s ?T ?ici una 9/='=H/=

Lia mecanic $mportan, capacitate, volum Performane

Prototip tehnic ":% Prototip tehnic "=% Prototip tehnic "=%

/ab. engr. /ab. test. /ab. test.

?ovell, ?@7, ;/=<'=H/=< ?T ?ovell, ?@7, ;/=<'=H/=< ?T

$a"a te+t)rii +i+tem%l%i Demonstraia Prototip BT+@ validare "E% @uncionalitate Prototip validare ":%

?ovell

=H/=G'=/=G

/ab. engr. /ab. test.

?ovell, ?@7, =H/=G'=:/= ?T

$mportan, capacitate, volum Performane

Prototip validare "=% Prototip validare "=% Prototip validare "D%

?ovell, ?@7, =H/=G'=:/= ?T ?ovell, ?@7, =H/=G'=:/= ?T ?u este cazul =H/:E'=:/=

/ab. test. /ab. test.

#ompatibilitate

7Jstem #ooCers, $nc

20

Bediu

Prototip validare ":%

?u este cazul

=H/:E'=:/=

7Jstem #ooCers, $nc

"D% B7 mouse ":%, B7 Cbd ":%, L-2 mon ":%

De"&oltarea de te+te 7unt cazuri n care echipele de testare reutilizeaz teste create cu ocazii anterioare, cum de altfel situaii c6nd se creaz n mod special aceste teste pentru cazul concret. 2sfel, proiectele de testare cuprind o parte de proiectare i una de dezvoltare de obiecte de testare precum proceduri de testare, instrumente de testare, suite de teste, scripturi de testare automat i aa mai departe. 2ceste obiecte pot fi incluse sub denumirea generic de sisteme de testare. (n aceste situaii, aceast seciune va descrie modul n care echipa de testare trebuie s creeze aceste obiecte. (n cazul testrii manuale, cititorii vor fi informai dac se folosesc proceduri detaliate de testare sau carta de teste. Dac vom avea nevoie de date de testare, vom e plica cum s'au obinut aceste date i care sunt motivele pentru care au fost alese anumite abordri. Dac vom utiliza instrumente de testare automat e istente pe pia "gratuite sau nu%, vom specifica de ce am ales acele instrumente i nu altele i cum vom elabora scripturi de testare. Dac vom realiza instrumente de testare i subprograme de simplificare personalizate, atunci vom descrie aceste subprograme i felul n care intenionm s le utilizm. De la un anumit punct, elaborarea de sisteme de testare sau produse de testare poate deveni un adevrat proiect de elaborare de programe informatice. Personal am participat la proiecte de dezvoltare de instrumente personalizate, n cadrul crora am creat instrumente de automatizare i management ale testrii complet autonome. .nele dintre proiectele de testare pot consta din eforturi de elaborare de testare care au necesitat zeci de zile de munc. (n astfel de cazuri, prefer s am un plan separat care descrie eforturile de elaborare. 1 ist mai multe modele bune de planuri de dezvoltare de programe informatice:. E e#t%area te+telor 2ceast parte a planului de testare cuprinde factori importani care influeneaz efectuarea testelor. De pild, pentru realizarea testelor, este adesea nevoie de elemente din e terior, n special de resurse "sau fonduri pentru respectivele resurse% i de sisteme de testat. (n timpul realizrii testelor, se adun date care trebuie prezentate n mod adecvat echipei de testare, colegilor i conducerii. (n plus, se efectueaz cicluri distincte de teste n fiecare faz de testare.
2

De e emplu, vezi 888.constru .com, unde e ist modele din Software Project Survival Guide de 7teve Bc#onnell.

21

7e recomand ca nivelul de detaliere necesar n acest stadiu difer de la o echip la alta i de la un proiect la altul. #6nd echipa de testare este e perimentat n proiecte similare, o parte insemnat din aceast seciune revine echipei de specialiti n testare de prim m6n. (n schimb, c6nd este vorba de un proiect pentru care specialiti n testare nu sunt familiarizai, chiar i n cazul proiectelor haotice, se recomand s se anticipeze n plan c6t mai multe cazuri de testare, pentru a se evita situaii de confuzii viitoare. Parti#ipan(i #0eie (n aceast faz, se identific participanii cheie la efortul de testare i rolul pe care acetia l vor avea. 1ste deosebit de important identificarea participanilor e terni, a punctelor asupra crora nu se intervine i a informaiilor de contact ale fiecrui participant. 5 alt parte util din aceast subseciune poate fi semnalizarea progresivA cu alte cuvinte, ce se nt6mpl dac o parte dintre participanii cheie nu pot s'i ndeplineasc sau pur i simplu nu'i ndeplinesc rolul stabilit) Dac este vorba de participani e terni, mai nt6i sevor defini rolurile i punctele asupra crora nu se va interveni, i abia se vor trece aceste informaii n planul de testare. Urm)rirea pro#ed%rilor de te+tare 'i a erorilor 2ceast seciune este dedicat sistemelor utilizate pentru gestionarea i urmrirea procedurilor de testare i a erorilor. .rmrirea procedurilor de testare reprezint foaia de calcul sau baza de date folosit pentru gestionarea tuturor procedurilor de testare din suitele de teste i pentru urmrirea desfurrii lor. .rmrirea erorilor se refer la procesul utilizat de echip pentru a gestiona erorile gsite n cursul testrii. Deoarece aceste sisteme constituie principalele canele de comunicare n interiorul echipei i spre e terior, spre departamentele de dezvoltare i spre conducere, acestea trebuie definite foarte bine. I"olarea 'i #la+i i#area erorilor $zolarea unei erori nseamn realizarea de e perimente pe sistemul testat pentru a gsi variabile conectate, relaii cauzale sau de alt natur. 1ste deosebit de important e plicarea detaliat a izolrii erorilorA n caz contrar, echipa de testare se poate gsi blocat n rezolvarea erorilor, o sarcin ce i revine de regul programatorilor i este mare consumatoare de timp, av6nd rezultate foarte slabe n privina acoperirii testelor. #lasificarea erorilor const n includerea erorii ntr'o anumit categorie, care indic felul n care eroarea trebuie comunicat i rezolvat. 7pre e emplu, se poate folosi urmtoarea clasificare practic! De e#(i%ne legat) de #erin(ele +i+tem%l%i. 1roarea const n imposibilitatea sistemului de a'i ndeplini cerinele, problem rezolvat de persoanele responsabile.

22

De e#(i%ne legat) de neapartenen(a la #erin(ele +i+tem%l%i. 1roarea depistat nu este acoperit de cerinele sistemului, dar afecteaz n mod semnificativ i inacceptabil calitatea sistemului. Problema trebuie rezolvat de persoanele responsabile. Ren%n(are +oli#itat). 1roarea semnalat const ntr'o defeciune, dar programatorii solicit o renunare pentru c au convingerea c aceasta nu va afecta n mod semnificativ calitatea oferit clienilor i utilizatorilor. De e#(i%ne e8tern). 1roarea se refer la o defeciune cauzat de un factor sau de factori e terni sau care sunt dincolo de controlul sistemului testat. De e#(i%ne de te+tare. Programatorii sunt convini c testul a relevat o eroare greit sau nevalabil. (n locul clasificrii erorilor, unele echipe de proiect se folosesc de un singur proces de management al erorilor. -anagement%l noilor edi(ii re&i"%ite .na dintre interfeele ma0ore dintre proiectul global i testare const n prezentarea echipei de testare de noi ediii revizuite, de noi versiuni i componente, care trebuie testate. (n practic se pot nt6lni situaii scpate de sub control dac aceast gestiune nu se organizeaz nc din etapa de planificare. (n aceast seciune a planului de testare putem defini elementele cheie ale procesului difuzrii de noi ediii revizuite, proces care poate influena efortul de testare. .nul dintre elementele acestui proces l reprezint sincronizarea regulat, previzibil, adic la c6t timp trebuie acceptat difuzarea de noi ediii n cadrul procesului de testare) @iecare nou trimitere de program informatic sau echipament n laboratorul de testare trebuie s aib un numr de revizie, care este esenial pentru a stabili care versiune a sistemului conine o eroare, care versiune a reparat aceast eroare, care piese sunt compatibile cu alte piese i care sunt versiunile testate. 2r trebui de asemenea ca la difuzarea noilor ediii acestea s fie nsoite de note care s specifice care sunt erorile reparate, schimbrile fcute i felul n care aceste schimbri afecteaz comportamentul sistemului etc. 2cest lucru este valabil mai ales pentru sistemele comple e care au interfee cu alte sisteme. De pild, dac o aplicaie acceseaz o baz de date, s'ar putea s fie nevoie de schimbarea schemei bazei de date pentru a accepta schimbrile din program, ceea ce poate fi o adevrat provocare dac la aceast baz de date au acces mai multe sisteme. (n plus, noile ediii trebuie difuzate ntr'un anumit format. Pentru fiecare faz de testare & deci n fiecare plan de testare & se va specifica felul i formatul procesului de difuzare de noi ediii.

23

De pild, n cazul programelor informatice livrate n cadrul fazelor de testare a componentelor i integrrii acestora, acest format poate fi o simpl arhiv tar sau zip trimis prin e'mail sau postat n reea.

Ci#l%ri de te+tare .n ciclu de testare nseamn derularea uneia, a mai multor sau a tuturor suitelor de teste planificate pentru a anumit faz de testare. #iclurile de testare sunt de regul nsoite de o singur ediie a sistemului testat, ca de pild o versiune de program informatic sau o plac de baz. (n general, noi ediii sunt difuzate n timpul unei faze de testare, ce declaneaz un nou ciclu de testare. De e emplu, dac suitele de teste D.= p6n la D.< sunt planificate pentru o faz de testare a sistemului n trei cicluri, primul ciclu ar putea necesita e ecutarea suitelor D.= i D.:, al doilea ciclu, D.D, D.E i D.<, iar al treilea ciclu, D.=, D.:, D.D, D.E i D.<. 5rice faz de testare cuprinde cel puin un ciclu al suitelor de teste planificate pentru faza respectiv. @iecare ciclu ulterior implic de regul difuzarea unei noi ediii a unuia sau a mai multor componente ale sistemului. 2ceast seciune a planului de testare ar trebui s conin ipotezele i estimrile dumneavoastr privind numrul, sincronizarea i dispunerea ciclurilor de testare. Ore de te+tare (n unele cazuri trebuie stabilite orele de testare. (n plus, la unele proiecte se pot folosi mai multe schimburi, dac resursele disponibile sunt insuficiente, pentru a accelera viteza testrii. Dac este cazul, deci, aceast seciune trebuie s fie rezervat stabilirii orelor i a schimburilor necesare. Ri+#%ri 'i e&enimente nepre&)"%te 2ceast seciune este rezervat ,Problemelor deschise,, pentru c se refer la evenimente poteniale sau posibile care ar putea ngreuna sau chiar mpiedica efectuarea planificrii testelor. 7ubiectele abordate pot fi nevoile de specializare, disponibilitatea asistenei suplimentare pentru rezolvarea erorilor n cazul unui numr e cepional de erori gsite i aa mai departe. 2ceste informaii pot fi cuprinse i n discuia despre criteriile de continuare. Ba0oritatea fanilor proceselor de dezvoltare prefer o abordare global a managementului riscurilorD. Dac se lucreaz la un proiect n care ntreaga echip are un singur plan de management al riscurilor, se poate omite aceast seciune, incluz6nd informaiile n acel plan.
3

Lezi Software Project Survival Guide de Bc#onnell.

24

I+tori#%l +#0im!)rilor 2ceast parte a documentului cuprinde schimbrile i reviziile suferite de planul de testare p6n n acest moment. #u alte cuvinte, se poate atribui un numr de revizuire, cu menionarea numelui persoanei care a realizat schimbrile, n ce constau schimbrile i data la care a fost difuzat ediia revizuit. Re erin(e la do#%mente .n plan de testare face de regul referire la alte documente precum specificaii de proiectare, cerine, suitele de teste i documentele de analiz a riscurilor de calitate, precum i orice alte informaii pertinente. Prin prezentarea acestor documente n aceast seciune se evit repetarea coninutului lor "ceea ce poate duce la complicaii, dac aceste documente se modific%. 9ntre!)ri re#&ente 5 astfel de seciune este util atunci c6nd se desfoar proiecte la care lucreaz ingineri i tehnicieni de testare.

25