‘ ‘ob & Basics of Software “Testing and “Testing Methods. AF | # Software Testing i ~ Softwore testing is Process of executing : | rogram, with intent of finding errors. 7 Ist is defined a4 performing varification and Validation of softwore product_for Its ; | correctness and accuracy oF working . t Tasting can show the presence of bugs [n | S|: T Testing is 9 support function that helps developer 100k good by finding they mistake before any of C1se “doe! : Dp successful test 18 4 obe that discover an undiscovered exror. + | Objectives of Testing | Role. =Finding defects which may get created PY programmes _whil€ develaping SoPhware Fidance in_an providing inform qbout the level oF quality To _prevent defects. - 2 To make sure that end result me business and Usev requirement. i To ensure that it Sattsfes the Brs f SRS, To gain confidance of curtomer by providing. them a qualify products action thot {t so Qa ath ets_the Ltt ptt =P 7| Enrer_- An ewer is human ypduces the Incorrect res person makex an erry. j esY [fourt - error creates gq fault in Software ~\ Faure is_a_state of soffware caused Y th by an error - J —~ Foilure - Fault in a Software Cause failure ‘i oF software. Failure. o Shows worang i result from its expeched result. - Bug = tis the presence of error at the time of execuhon of the software. | Defect — A defect. js an error oF bug in | the application software. _Mistake - Mistake is an incorrect result Produk I because of human action Cunrong cod +t | Purpose of Testing = J | . 1 The Purpose of testing is fo findouwtH enor | ana defects that was made during [ devel opment phase. a : ; 1 ensure the quality of product. es O_provide quality. cissurance , Nari ficecHon and. validation, reliabili Of product Crust) L JO ensure thar thé software ¢ performs a intended Cexpected) to improve soFtusare quality relia bility and mM ainkaing bility, ’ i Jae ocumentation wshich Speci, i case is a 4 a values , expected ourput steps Fe NT econditions for FTest_Case [- f evecute » test data ¢ Pt me ating the test + Y 4 Test case helps fe find defects (slr padj [Tt verify whether she meets the SRS and BR txt impenye: the s)W quality 1 It avoids past deployment © risks i f ploy x [Eniry and ftxit Criateria of resting { oR [When te start and stop Testing oF sw i] tye | Entry Criaterja + Entry _cxiteria specifies When testing phage | can be started 1 it includes inputes required | For testing phase, Steps to be carried out |_ tn testing “along with measuremenH that | characterize sfeps / tasks. = FH_also includes Varification which sped Ae | the steps [task have been carried out currect)y - Entry criteriq ensures that testing phaye . } does not Start premafurely > It helps to prevent defects. + | iy" All test “hardware on Typica) eniry ¢rHerig_muyt Include Fotos} ust be insta tied configured and work} . ork jing P¥Pper|y K | | a a JNee elalie ven ie a> A the standard testing ‘tools j A aobriking repel 9 OIS INnstaljeg gy Al the Necesso ocumentad} ” and srs is eaicB\e to teste =a 7 4) AN qne testers involved tn testing myst be > trained on “the ‘trols Used in testing preas | s) Proper test data js available 6) ‘the test environment such as lab, hard- T Ware ¢ Soffware Should be ready. - Exit. Criterig. t T Exit Criteria defing the maximum eligibility or get of conditions under which one can considéy Festing: phase has been done. Typical exit criteria may indude Following > aly test plens have been run [ey pW requirements coverage har been achievel 3> pW Severay bug are resolved. 7 4> Al) the high risk areas have been Fully y EEE TEL tested - - S> The scheduie has-been achieved . 7 Verification and Validatton a validation aa Pe ght Are you builing product [vy Are You puiiding tight [right | preduet be rode wchould do | | Software must confirm [a> Softwar Ti equiey. what raf user really TEquyres : \__ Verification _| LE |_its specification - 7 a_i— F pore at]3y ENalUatIN gy SoftwWore 3 faluein sofiwe end of aersopment ie sta . VORA 4) || Tt is static practice of ay rt fs dynamic reckon” Verifying documents oF validating and testi, Vow design code 4 Program) | the actual product. N- S>'| Tt does not execute S> Tt always execute the code | Code | 6> || It fs human based 65 Lt fs Computed based checking checking: 7>|| Methods -— “Inspection , |7> Methods ~ tuhite box reviews, walkthrough, | disk checking testing , Black box testing] Gray box testing . | It checks whether th 87 Th checks “wheth ee | 3) | software confirms te | Sofware meet custome | specification: expectaHon ¢ requirement 9) | Veriticatin is done by | 9) validation is done by : QA team testing team . | % © *, —- i Joy || eg- Static testing Jos eg - dynamic testing _ ee verification = el It fs the Process of evaluatin wT software determine _whether_the prduct” Satichy the K r“Conditions given ak baginning = cation _is_static practise “of OF Ver} design and pro =~ methods Of Verif ods OF Veri ‘i EN vege Neri= cL N8tifying “document Heaton + st Seo ; oD + _sTatic_testin inspection ! ii) Walk trough ot Wi) review ee Nalidation " ' -1-| Tt is Process of evaluahhg Software during or at end of development phase to determine whethee- jt satisfies customers req ufrements . Validation evaluates Hina) product. Methods of Validation + dynamic testing 1) Black: box Testing. Jt =the} | N= model | Preparation of Acceptance Test Reg uirements| —aceeprans fese——]__ execution system te Globa) design Dnit | Tsusters requirement[™ test cals “1 —¢ —| \ “Integration Tniegratian test “Cc ases execution Le eT mer Jani — Fest cases = Detailed design [execu Uy}CLOC) bratty Verification and Validation makes the Vm : 7 : Tt is sequential path of execuHon oF proce In y-mode each phase must be Compal before the next phase is beg!) Ye In V-mode) verification ts one side of y~- and ValidaHon is onother side of V- + tat ly | = pt Verification phase Overal) business requirement In the first phase product requirement are understood from __customes. The acceptance test design planning _is done at this Stage. 3 System Requirements. : once the product requirement are known the system can be design. System test plan is design based on system design . 3B) Global | high level design | high level specifications are understand and designed in this phase _ system design iS broken dawn Inte modules I. Which shows different funcHonal ity , integration test plon for each module is ol designed -yn petolled ‘Tow Leve design. ~ In this phase the detail design of each ~ “Ff __module of system is speciffed. ~ 1 unit test case Plan fox each module is design ~ Sa Caating: T [ the actual coding of system module desigod 7 6 in this phase i T ‘ J 72. Zz g @ “dati J * pt 2) j 2 tk helps to eliminate defect in individual _ [- This is associ Unit Testing . . . . —™ unit testing designed incoding Are executed on the Code during this Vaidaton phat moaure. Integradion testing 7 a) component testing - ated with module design 7 helps te elimi nate defeck in invidual module —_3 “Inteqrahon testing I LI 3 LL Ure is associated with high | evel d tet the ee existance communi cafio) ’ 20d ese has far aceon oie SE Tk checks entire system Tune _ i(CELTIC) communicaton oF system with eternal SUR Acceptance Testing Tk involves testing the product _in user environment - Quality Assuarance J L iL { It js process oriented activities It js focused on providing confidence that quadity requirement Will be fullfilled. @A activities implements’ to provide | cankidance that! product or service wil] fulfill requirement for quality Tt js fundamenty focused on planning and (44+ AOE \ l | i] it i fatnto= | | documenting those process to assure quality such as quality plan, Inspection and test plans. It is system for evaluating performance service of the quali of product against St_is complete system” te assure the quality of the Product or services. ex- | Iso Jooo. jis an Internahona) standard used Py Many Companies to ensure their @A system is “in place and effective Quadrty cont) a n _Ttis product oriented activity ~ -p It is focused on fYllAllin ts ing gu ality regalo ieFat is physical Neviffeation thar product (7 confirms te these planned aa _activities 71 Tt ensure lab management Comptence and S performance during manufacturing of product | ox Service to ensure: jt meet the quality gl plan a3 designed. @¢ measures & determine | guaiity of product or Service. yl] ee : oe % | Methods of Testing ol StaHic Testing 2 Dynamic Testing . 3) White box Testing 4, Black box Testing. s]___Graphica} user Interface Testing. i ei], Static Testing It is resting of Sofhyare work products manual. Testing of program is done but not executed Static. testing is yerification activity: : Tt Starts early in_life cycle and is’ done during Neriffication process» Tester has checktist te check whether the Product is a5 per set Standards of organization ~—_t Static testing find errors and arabiguity in “4 t documents- | It test rogram without execatin program. dead code ~_ Pegi a vatiablé withour underlined volte, Ce%t Conk, red but not used, |_4 Variable. thak are leclaCLO) a. ; jon, Secur}: - a vito} ation, programming, stand | [7 Netmarabilities - [+ static Testing method i) Walkthrough ii) ‘Inspection UL, apt | + | iiiy Technica) Review | ] Is Advantages - aes 11) since static testing Start early’ tn LiFe cya early feedback On quality issues can be [established - : [i Due to early detection of defects, rework | cost are low : i iti) Since rework efforts is reduced developement | productivity figures are increased. Ui J Ss | |e Disadvantages |) Tt requires great amount _of time when I done manually. st Dynamic Testing. Dynamic Testing IsValid ation activity. Tester hos Software requirement specification — CsRs)_to check whether the product js an Per_requirement of user. ‘ | It_is used to test the dynamic behaviour of — code. rrr | rin dynamic testing software must usually be Compilied and ran te find: bugs or to confird TTT?AAAS hat its working wel). Tt_test Software by giving input Values and checking if the output ; qs ex by test cade, wp = pected + Dynamic Testing Methods [ Types: HtYy i) unit Testing _- focuses on Correctness of basic component of Soffware- ii) System Testing (- verify correctness and performance of Software as per SRs - ii) Acceptance Testing ~ This is final testing before Software js H put inte use. Livy Regression Testing T > Verify ¢ modify the acceptance test result in the Software maintenance phase. [\)_ Integration Testin [= Detect whether various units of sjw are working propeTly ov not. i Differance behween Static Testing ¥ Dynamic Tes ting:Se Static Testing Dynamis Testhg. ~V~ Software is Not used: 7) Software is used foy — compile f UN the code C Tt is used to check the ii) Tk executed the code | Suntax of code or to find the errors. | reading code to find eryors - fi) Code _veviews inspection iii) Unit_test_, integration and walkthvough are test, Acceptance test the methods. regressjon test re _methos It is verification activity iv) St is validahon activity : +3)) White Box Testing j t | r Tt Is_detailed investigation of internal logic: and structure of code. } The _teste@ Should have knowledge of internal Wor ing of the code. The testey looks inside the code and Find Out which unit of code is pot behaving properl t =< ~ >ANY Wihite Box Testing g | | [Static Testing | [Structyra) Testing | U py Lnspection code cde code |b Walkthrough Functional] |complexity Coverage | L, Technical revi ee __| Testing/| fi a — Ls Cconditiona) coverage t=» Branch Coverage Program statement 4 line coverage Walkthrough Tt is done by group of peers to review the Jocuments and discuss technica) aspect oF software development process. The main objective is to find defect te improve guality of Pr duct: In walkthrough author guides review team, vig document +? fulfill common understanding and __conecting feedback. Waal kth rough _is mot a forma) process J require In walkthrough review team does not wobile to do detailed study before meetin 7 ratio aubhors are already in scope of prepa Te is usefw) - for heighee evel document: he, Req uirement speciFicatia na we (___—aigthroagh [structured walks iciponts °. Author + the qurhoy of document undes | review - | presenky «develops the agenda for waolkthny 27 ugh __and present output. Facilitates walkthrough gessJon to 3>|_ Moderator + ensure _agend9 is Followed and encourage al] reviewers to qy | Participate. J Reviewers + Evaluate docurnent under test + determine if it js techniqually Qccurate- 1 S| scribe + Scribe is recorder of tne Shructurd, | walkthrough asukcomes who record the jssyé identified, Comments, suggestion unsolved question. Benifits ~ v ] Tt save time and money because defects 4 found very early in lifecycle. J ees It provides valué added “comments from to Veviewers- + Tt notifies abouk th oe ment process. <_progress of develee T | _— hn> yr - A Trained modesato . Tt is formed type of review. tf The reviewers are yr quider Inspection prepared and: eheck —T| documents before meeting. “i In inspection. product isi examined and ! caefect iS found 4 documented in /ssue fog - — 4 | Goals = | L Assists the Aauthor | document - = +o improve quality of EfficienHy and vapidiy yemove the defects . “Improve the quality of product, 2 Dt prohibits the -Cccuranée of similar defects by “learning previous defects founds. pot 4 | Differance . “between wallstough~ ¢ Inspection Walk Trough Inspection >” 1)| Informal Revier ‘|y Formal review 2)/ Initiated bY author 3)/ Zt is unplanned meeting ya) Initiated by Mmoderafor J b3) It is. planned meeting : 4 4)|| Author reads the : document #' Guide his 4) Reviewer “reads the document ‘+ find defech. jeam to find defects | eeee | ~ sy | Scxibe re records. The defects| 5) Mex (5) Moderator [records > oo ae ords the defects 9 jeg Ce | an ls al wt NT 3) Technica) review + =F i Te Jechnica, review js | discussion meehn thel i focuses on technical contents of docurn eng at is jess format veview Tt Tt js guided by trained moderator or 9 | edechnicel OnE _ J "Gaol ir Te evahuote the value oF echo concept Project. enyiranment.: = Build the. consistency fn we Tends represen. | xateq of technical concepts . = In early stages it ensures that the technical concept “are used correctly , : a Notify the pasticipates regerding fechnical coment . of the document— a) “Suda White Box Testing — — 1 sinatura] testing [ OF ssustem ‘s ine testing of Shucture | | iS ofte fe Cas. q It 1S often referre to Boy clear .B0% «Testing | z white Box: ais Boy oP Tt fs technique | __ Sar rng) cn t2hich ‘SaP hares inte rhoet a“Structure, design and. coding! are tested sto verify input ~ ‘output _ How, and improve destan , usability dod security . i qT to ve box Festing Code is visible to testeu © it tig called’ clear - 1 glass _b ‘ based ng ~box, glass ok} Code 7 AM a" i) Wihot do Yo verify in white Box Testing- i> Galamel Security cHSIESE |= Broken oy poorly structured paths Ip Coding . vit Tre: fow Ee aEeice open through the vill Code”. = Expected Super. ; | functionality of conditions: loops - ~ Testing of each statement, object and i function on indjviduaf basis. + « [Tester Should) requive the Kantedae of Le infernal implementation of code. | ti) Why we pelitorar White box: Testing. —_r AM Jogscat ——— | true an ~___|| - Ay loops executed — ak -_Alj the sraanendanes paths vathin qa modwe | have been exercised at « least once jea} de detisions “should verified on their venice g On true_and_ 4 false vuu eo boundries and __ v anithia their _ operational bounds values. | iii) Hee How) do ube © EE we * eperbot white jes Testing —WU -4 | | I | H ny 4 ' Stractural white box Testing Techniqug~\ \ . i 4) “code coverage Testing (ode coverage [7 : _ analysis Teli) A measure white box testing” technique is | Code coverage testing - + Code coverage jesting eliminodes g.9ps ing test case suit» It identifies areas of a Program thak ove mot exercised | tested + by a set of test am ia ese ee \ cases - So tester can verify untested parts oF the _codé which increases the quality. of SoFtwore L product . It is a measurement thal indicates what percentage of source Code would get. executed during yesting: If the exetdte. the entre peace of code including all branches, Conditions and loops then soy code coverage is 100 “fo example ~~ : Toput_ a,b uff eo 6 deb ie=d+b to fry { yt tt TF c< lo then ipel ! d vo print ¢ : ' | else the ‘ } | ‘ t ube Sovry" ' \- I ro above program test cases with the eke — [the values of @)b uch that the: sum! ‘ aluvaus less than so, then the else art 2 | code: never gets executed 19 th -fhis scenart® az | | we can say the code coverage is Incomplete» y rf the Valuer ofAandB such that the sum 4 A\\A\ NY is then than o and fer same Value greates? than Lo then both if and else part of Code } gets evectted ano we can say code coverage | is Look completed. | i) Prog ram statement and line Coverage. Tt isa white box testing technique fn _ushich ‘1 all the executable statement in Source Code _ are executed at least once The goal of fester is to make Sure that every Statement _in the program gets executed af least once. — ~ Tester tests the code line by line by giving the preper Input and checking the relevant owtper, . Tt is used to calculste the No-of Statement in the Source code which have been executed Using below formula statement coverage = No of executed Sm rae leenie | , a} j Total, no. of stmt nl iO Ty 1 ex- consider the below Source code: prints ( int a, int b ) "jot result = a+b } if Cresult 7 0) —_ print (° positive"! result )i e\se ‘ ue peint (« wegative"’; result)}GEG NY Eee __ if scenario Ms oul no: of Smt executed =X — ni tmts = 8° y Fora): Now of S = ; ~~ “eratement coverage = 15}. S— ¥ — a 23.6 be-9 | Mario 2: IF 2 Scenari a) ran ‘simats executed = ep Total no- of simts = 8 =z 88" Statement coverage | Overa)) jn above &xarn le, all the Statements are being covered b both SCe narioS.- So, we can Conclude that overal] statement | coverage is 1o0°/. li) Condition Coverage (Decision coverage) + Dedsion Coverage is a white box Testing |__which reports the true or false outcomes of each decision] boolean expressjon. of Source | code. + Tts goal is +o Cover and ensure that each | decision point outcome branch eae is | executed at Jeast once. T oor + decision ___Novof decision outcomes excergised > coverage total _no.of decision outcomel. ¢ eM Cinta) \ iF Cars) CEL ee Print (a)5 ~ a 1 | Tex. [ |4 Scenarfo 4: IF Value of ais 2 othen ' ! : No. of decision outcomes excersised | “Total_no-of ‘decision outtomes=2 t thense ; decision: coverage = 1 = 5D. | + | “Scenario 2: Value of a=G I ae \_decision Coverage= 1 = 50 te {| Vauei it i ae = It is very hard to acheive loos Coverage - ii Branch Coverage - Te fe aq white box testing in which every i “outtome .of 9 decision statement ov loo) Statement? is tested. sti = Tt ensures that each decision. condition fom "every branch is executed atleast once - T Branch Coverage will consider conditional as Well as unconditional branch Statements . I | Branch Coverage= No.of executed branches | Total no: of branches. | H | Am ST condition 7 demo Cinta) alk conditional | tna 2 yan Ee if Cars) Congr IE asa%s | | branch T unconditiong Q= O*3 5 le A [paint cay brane{x Scenario At iF “NO: of @ executed brar “Today no. of branches branch coverage = 4 ery ray | J [Scenarfo 2 = If value of org t No: of executed branches 2 Total no: of branches | branch coverage = aE V11\ | Feets Tools of Code coverage. » Pit fort | 1) Cobe Ttuxg- ey lovers! | 3). DevPartnes. 4) Erama. (SY Bullstye fox cH 6) Coview' and CoAnE. 7) kalistick. , &) Sonar. : ; , Cae Complexity. testing | syclomahe omplesiy— testing It is a type of {esting through whith _ "system desi —Neviffed.” vait-and Systerh coding isCyclomatic complexity Measures the amount of — decision logic in the program module Tk also measures ho of independent paths in the modwe. ' Cyclomatic complex Hy Is_used te indicate the complexity oF a program Complexity fs~ calculated using the contr} Fow 9 ph of the pro van The hodes in a graph indicates the Smallest qrp of < instuctions of a prgm.. {the directed edge of a graph connects foo | noder i ! : £ cyclomatic Complexity 1, Mis calculated as Js Ms €-Nt2 | where , E = No-of edges. {| N = No. of Nodes- sexample - Catart ) \ \ NON , | A=to | If B>C then ASLO | A=B k r else False “ IF\X Tue A=c | Bc | | _| | endif 5 Print Ay Bic AEcy [a=8 Print ABc kK ep »)oF Do ES | YZ ; testin L- code function aa _test1ng of _testing_done before i ) hase qt js easly P to coverage testing and submithng +ne code Com plexity Testing_- Tester perform this test by passing Segui inputs and checking ouFputs | Lay Tester should Fequise Code Knowledg & Vike “loop iterah’ ons, conditions » inputs and check its outputs: Tester: checks whether every {oop and decision statements gre functiona) or not Consider Mo Code module which is having more complex logic and conditions, dl In this cage tesier Checks the Correct soorking of loop and iteraHon by simply peoting print Statement at He intermediate points” jn_loop- If those statements gre executed and disprayed correcHy then jr.can be conclude that loops Gre orking fine. After 3! ‘testing paint Statem ents dre remove K_ EL LIED: Te P BlackBox. Testing [Behavioral Testing. + Black’ box testing alsd kno n oar 1g ion _as bear — ft re is —T @_ Software testin ~ method in which Bh eel Structure / dl estga | implementatfon | €\ | program being tested Is hot Knowh ‘tb the tester: Al rhput | Texecutabie |__ Joutput | Bop th Program | f T Blackbox testing atempts to find errors in | following _ Categories — l- incorrect or “missing Fanctions. |= Interface errors. j = Errors in data Stucture. or database access — behaviour of performance error. = Tnitialization and termination errors - (_ A testee without knowledge of internal |__ structure of website, tests the webpages by |_ providing inpuks and verifying output against [the expected ‘output. & Adyaniages OF blackbox testing - I Tests_are done from user point of view [Tester need hot know programming Janguages. oF SofFtusare implementation. Test can be done by 4 "ream __independ- | ant fom developers. _| =!| LH) | | —— | are, —~\ | fest_cases_can be design CON Us HA | specification are complete. — — % Disadvantages 7 WL {| _ ae T only small _No- of posible inputs can be tay and many pregram| code path remain unteng - Without knowing implementation _detatls tis | difficult te deign test cases - + Test can be fedandant (repeatedly) if He Y | software developer has “already wan atest i] case. T +F Black Box Testing Techniques. 41 Requirement based Testing - r It js testing : approach im _which test cases - conditions ‘Gnd: data are: derived fom i requirements -. i \ ‘4 Tt indudes functonal testiand also non- ~— _- functional atmbutes such as. ‘performance, ~ | reliabiity or “Gsabili tus! ; ~ x __Stoges in requirement! based Testing . - - 7 I r 7 7