sumer cove: C8366 Stricly as per Revised Syllabus of ANNA UNIVERSITY Choice Based Credit System (CBCS) Vertical - 2 (Full Stack Development) (CSE) ‘Vertical - 2 (Full Stack Development for IT) (IT/Al&DS) SOFTWARE TESTING AND AUTOMATION Dr. Monika D. Rokade Ph.D. (CSE).ME. (Computer Engg, BE. (Computer Engg), Assistont Professor, Shorodchandra Pawar College of Engineering, Otur Dr. T. Grace Shalini ME-MBA, Ph.D, Assistant Professor, Velammal College af Enginee'ing ond Technology, . Modurai.SOFTWARE TESTING AND AUTOMATION Subject Code : CCS366 ‘Vertical - 2 (Full Stack Development) (CSE) ‘Vertical - 2 (Full tack Development for IT) (IT/AI&DS) © Copyright with Authors [A pblshiog hts ined and ebook vein) reseed wth TcricalPubcatons. No part his back thou be reproduced in on orm, Elec, Machoricl, Photocopy any infrmofionsoroge end teil srs hou ror peison in wing, om Technical bheaions, Ane. Published by = Pomeroy Printer os Pits 8 Bode SiNo. 10/14, hale hail Este, Nadel Vie Rs Ta Hol Di,- ine 411041 ISBN 978-91-5515.09-1 il 976995585430900) @ PREFACE The importance of Software Testing and Automation is-well known in various engineering fields. Overwhelming response to our books on various subjects inspired us to ‘write this book. The book is structured to cover the key aspects of the subject Software ‘Testing and Automation. The book uses plain, lucid language to explain fundamentals of this subject. The book provides logical method of explaining varlous complicated concepts and stepwise methods to explain the important topics. Each chapter is well supported with necessary illustrations, practical exemples and solved problems. All chapters in this book are arranged in a proper‘sequence that permits each topic to build upon earlier studies. All care has been taken to make students comfortable in understanding the basic concepts of this subject. Representative questions have. been added at the end of each chapter to help the students ia picking importent points from that chapter. ‘The book not only covers the entire scope of the subject but explains the philosophy of the subject. This makes the undersianding of this subject more clear ané makes it more Interesting, The book will be very useful not only to the students bur also to the subject teachers. The students have to omit nothing and possibly have to cover nothing more. \We wish to express our profound thanks to all those who helped in making this book 4@ reality. Much needed moral support and encouragement is provided on numerous ‘occasions by our whole family. We wish to thank the Publisher and the entire team of ‘Technical Publications who have taken immense pain to get this book in time with quality printing 1 ‘Any suggestion for the Improvement of the book will be acknowledged and well appreciated, Authers Dx Mentha D. Rokade De. L. Grace Shalini Dedicated te Readers ®SYLLABUS Software Testing and Automation - [CCS366] UNITI FOUNDATIONS OF SOFTWARE TESTING Why do we test Software 2, Black-Box Testing and White-Box Testing, Software Testing Life Cycle, V-model of Software Testing, Program Comrettness and Verification, Relsblity versus Safety, Failures, Errors and Faults (Defects), Software Testing Principles, Program Inspections, Stages of Testing : Unit Testing, Integration Testing, System Testing. (Chapter 1) UNITIT | TEST PLANNING ‘The Goal of Test Planning, High Level Expectations, Intergroup Responsibilities, Test Phases, Test Strategy, Resource Requirements, Tester Assignments, Test Schedule, Test Cases, Bug Reporting, Metrics and Statistics. (Chapter -2) UNITI TEST DESIGN AND EXECUTION ‘Test Objective Identification, Test Design Factors, Requirement identification, Testable Réquirements, Modeling a Test Design Process, Modeling Test Results, Boundary Value Testing, Equivalence Class Testing; Path Testing, Data Flow Testing, Test Design Preparedness Metrics, Test Case Design Effectiveness, Model - Driven Test Design, Test Procedures, Test Case Organization and Tracking, Bug Reporting, Bug Life Cycle (Chapter-3) UNITIV ADVANCED TESTING CONCEPTS, Performance Testing : Load Testing, Stress Testing, Volume Testing, Fail - Over Testing, Recovery Testing, Configuration Testing, Compatibility Testing, Usability Testing, Testing the Documentation, Security testing, Testing in the Agile Environment, Testing Web and ‘Mobile Applications. (Chapter~4) UNITY TEST AUTOMATION AND TOOLS. Automated Software Testing, Automate Testing of Web Applications, Selenium : Introducing Web Driver and Web Elements, Locating Web Elements, Actions on Web Elements, Different Web Drivers, Understanding Web Driver Events, Testing ‘Testing xml, Adding Classes, Packages, Methods to Test, Test Reports. (Chapter ~5) Understanding w TABLE OF CONTENTS Ba ee Thapter-1 Foundations of Software Testing (1-1 to -30) 1.1 Introduetion 1-2 1.1.1 What is Software Testing. wl? 112 What is Testing ton a 4-2 1.1.3. Why Software Testing Is Important? 4-3 1.14 What is the Need of Testing 2. nin 1-3 4.15 What are the Benefits of Software Testing . 1-4 1.1.6. Type of Software Testing, amen sin“ 1.2. Black-Box Testing and White-Box Testing, seasons 125; 1.2.1 What is White-Box Testing tenn ene 12.11 Typesof White Box Testing in Software Testing 1-6 12.1.2 Techniques of White 80 Testing essen 1-6 12,3 Advantages of White Box Testing ao 1-7 12.24 Dsadvantages of White Box Testing a7 1.2.2. What is Black Box Testing nse nnn B 41.2.2 BlackBox Testing Pos an Cons 1-8 12.2.2 _Typesof Black Box Testing oe 1-8 12.23 Black ox Testing Techniques 1-3 13. Decision Table Testing. 1-10 1.3.1 Differences betiveen Black Box Testing Vs White Box TeStingmuonunne 10 14 Software Testing life Cycle. a smsseanse VM 14.1 What s the STLC (Software Testing Life Cycle)? a 15 V-Model of Software Testing 16 Program Correctriess and Verification . 17 Relibilty Versus Safety ..nisnsinsnnnnnnnnnnnnnss 1 AT 1.8 Failures, Errors and Faults (Defects) 1-18 o1.9. Software Testing Principles ru 7 1-19 2.17 Components of Test Strategy Document.. eee 2-20 1.30 Prowéin sgectons eat 2.27.1 Types of Test Strategies et 7 2-2 iif Sages offi=tine 218 Resource Requirements reruns os sesnannn 223 1.22.1 Unit Testing, 1-23 2.19 Test Schedule. 2-24 1.11.2 Integration Testing 1-74 2.20 Test Casos _ : 227 1.11.3 System Testing. . . 4-26 2.21. Bug Reporting 2-33 Review Questions... 1-27 2:22 Metries and Statistics... 2-38 1.42 Two Marks Questions with Answers. vo =27 Review Questions. 5 2-39 2.23 Two Marks Questions with ANSWEPS wcsnenn 2-39 Chapter-2 Test Planning (2-1) to (2-42) sete 24. Introduction, “ 2-2 Chapter-3 Test Design and Execution 22 Define a Test Plan 2-2 3.1 Test Objective Identification... - 3-2 23. Why are Test Plans important 2. : 22 3.2 Test Design Factors 3-3 2.4 Components ofa Test Plan. 2-2 3.3. Requirement Identification B - 3-6 25. Types of Test Plan. 2-3 3.4 Testable Requirements. . 3-8 2.6 Test Plan Components or attributes 24 35 Modeling a Test Design Process sen 27. Tester Roles and Responsibilities. 2-9 3.6 Modeling Test Results 3-13 28 Software Testing Life Cycle (STLC). 2-11 . 3.7 Boundary Value Testing.» mnsamnies 37 1S 2.9 STLC Characteristics. wns ws 2-12 3.8 Equivalence Class Testing... ‘ 3-19 2.0 Stages of STLC. = 2-12 39 Path Testing. 3-22 2.1 Test Phases 2-15 3.10 Data Flow Testing . jot 3-25 242 Test Strategy. 2-16 3.11 Test Design Preparedness Metrics cnceniend 3-27 2.12. Whats Test Strategy Document 2 = we te 3.12. Test Case Design EffectivenesS...surninsinnnnisnnn 3-30 2.13 How to Prepare a Good Test Stratagy Document eusnoun aw 3:13. Model - driven Test Design... 3 244 Test Plan Vs Test Strategy on. a sen 2-19 314) Tet reddcssare, ae 5.33 2.45 The Objective of Test Strategy orn : . + 3.15. Test Case Organization and Tracking venison 3-35 2.16. Features of Test Strategy Document. ns 2-20 3.16 Bug Reporting Tie ry3-43 ea Review Questions. 3.17 Two Marks Questions with Answers. Chapter-5 TestAutomation andTools ——=—=—=—«(- 1) to (5 - 38) hi aa ee] 51 Amt Sofware Testing 5-2 ‘Chapter-4 Advanced Testing Concepts =~ 1) t0. (4-38) 5.2 Automate Testing of Web AppIICAIONS anennsinonnn 5-4 4.1 Introduction. 42 5.3 Selenium : Introducing Web Driver and Web Elements 5-9 4.2 Performance Testing... 42 53. Locating Web Elements 13 ‘Aza. toad Testing. 2 5.32. Aetions on Web ElemeMt. orn 5-15 we ae aa 533. Different Web Devers. 50 423. Volume Testing a Soe 5.34 Understanding Web Driver Events. 5-19 424 Falhover Testing ans 54 Testing 5-2 425. Recovery Testing. au SA." Understanding Testing xml 5-24 426 Configuration Testing = _ seo 19 52 Adding Classes — 5-26 427. Compatibility Testing 4-20 543 POCKIGES enn bt 5-28 4.28. Usabilty Testing Sassen - sD 54 Methodsto Test. 43. Testing the Docurmentation.. 4-25 5AS Test Reports 43.1. Types of Test Docu nm oe 4-26 Review Questions 43.2. Benefits of using Documentation. 4-26 ‘5.5 Two Marks Questions with Answers 44 Security Testing aa 44A.A- Principe of Security Testing 477 442. Types of Security Testing... a a 28 45. Principles of agile Testing 4-29 ASA Rall TOL PlaR enn seve 3B 452 Asie Testing Stroteries, aot 453. Agile Testing lie fe... 7 sen 33 46 Testing Web and Mobile Applications 4-35 46:1. Difference between Mobile App Testing and Web App Testing 4-35 Review Questions. 4.7 Two Marks Ques Answers oi) ooNotes UNIT I Foundations of Software Testing i Syllabus Why do we test Software ?, lack-Box Testing and, Whie-Box Testing, Sofware Testing Life Cycle, Vemodel of Software Testing, Program Correcinss and Verification, Relibiliy versus Safer, Failures, Errors and Fauits Defects), Sofvare Testing Principles, Program Inspections, Stages of Testing : Unit Testing, Inegration Testing Sytem Testing Contents 14 Introduction 1.2. Black-Box Testing and White-Box Testing 1.3, Decision Table Testing 14 Software Testing Life Cycle 1.5 V-Model of Software Tasting 1.6 Program Correctness and Verification 4.7 Rolitilty Versus Safety ’ 1.8 Failures, Erors and Faults (Defects) 1.9 Software Testing Principles 1.10 "Program Inspections 141 Stages of Testing 1.12 Two Marks Questions with Answers wT_Softare Testing at tortion 2 Foundations of Sotware Tat EBM introduction + This chapter wil discuss the fundamental of testing, such as why testing is require, its Jimiations, sims and purposes, as well asthe guiding principles, step-by-step inethods and psychological concems that testers must‘ake into mind. You will be able to explain the fundamentals of testing after reading this copter. ‘Software testing i « method for figuring cut ifthe ral piece of software meets requirements and is eorfiee. It involves roaning software or system components manually of automatically in order to evaluat one or more intriguing characteris. Finding fos, gps ox unfulfiled regurements in comparison to the documented specifications i-th aim of software testing. ‘Some prefer to use the terms white box and black box testing to describe the concept of software esting. Toputit simpy, software esting i the process of validting an aplication thats being tested (AUT), In this course, software testing is explained to the audience and its importance is justified EEE] Mihat is Software Testing + Software testing is the process of determining if apiece of software is accurate by taking ito account all ofits characteristics (riabilty, scalability, portability, ‘reusability and usability) and analyzing how it various components operate in order to detect any bugs, fauls or flaws. + Software testing delivers assurance ofthe software's fitness and offers a detached viewpoint and purpose of the programmer. It ents testing each component that makes up the necessary services to see whether or nat it satisfies the set‘eriteria, Additionally, the proceré informs the customer about the software's caliber ‘Testing is required because failure of ‘would be harmful Sofware cannot be released to the end user without beng ested programmer at any point owing to a lack of testing Fy What is Testing + Testing is @ collection of methods to evaluate on spplication's suitability for use in accordance with a predetermined script, however testing is not able to detest eveiy application Naw. The basic gal of testing is to find spplication flaws so that they may be ientified and fixed. It merely shows that & product doesnt work in certain particular sireuinstances, not that it works correctly under al circumstances TECHNICAL PUBLICATIONS - an uprustorknowledge ‘Software Testing end Automation a3 Foundations of Sotware Testing + Testing offers comparisons between software behaviour and state and mechanisms since ‘mechenisms may identify problems in software. The method may inéorporate previous iterations of the same or similar items, comparable goods, expected-purpose interfaces, pertinent standards or other criteria, but is not restricted to these, + Testing includes both the analysis and execution of the code in different settings and environments, as well as the whole code analysis. A testing team may bé independent from the development team in the present software development scensrio so that information obtained ftom testing may be utilized to improve the software development process. +) The intended audience's adoption ofthe programed, its user-ftiendly graphical user interface, its robust functionality loed test, et, is all factors in its success. For instance, the target market for banking and a video game are very different. As a result, an organization can determine if a software product it produces will be useful to its customers and other audience members. FEE] Wty Software Testing is Important ? + Programed testing is eri because it allows any fouls or mistakes in the programme tobe found early and ied before the sftwae pros is delivers. Reb, security and high performance are ll ensured by well tested softare, which also leds to time savings, cost efficiene and cstomer pleasure. ERE What is the Need of Testing ? Software flaws may he costly or even hamf his testing is crocil History is replete with istances when sofware defects edt financial nd personal ois. + Over 300,000 traders inthe financial markets were impacted flr a sofware eror caused the London Bloomberg terminal to collapse in April 2015. I made the goverment delay a 3 billion ound debt auction, + Nissan recalled detectors’ software was Hawed. Due to tis software flaw, two accents nave been docimente arly 1 million vehicles fiom the market because the airbag sensory + Starbucks’ POS system malfunctioned, forcing them to shut nearly 60 % of its locations in the united states and Canada. cormplete the purchase shop once provided free coffee since they coulda't ‘© Due to a technical error, some of Amazon's third-party sellers had their product prices slashed to Ip. They suffered severe losses as a result TECHNICAL PUBLICATIONS®- an upttt for nowiege‘Software Testing and Automstion 15 Svan Tonge aoaton 14 pests ot Ser astrg Fount of Sot Tost +A weaknes in windows 10, Due toa defect inthe win2k yt, user ae abe bypass Tip aot an security sandbox thanks this sue —— . 8 stv Dre 3 Jt incapable of sccuely detecting In 2015, sofivare fl rendered the F-35 fisher jt inca iy deting = 7 ret oor +O Api 26, 194 an bus A300 operated by Chin sitines cashed det & sotware po 4 7 ee a “ » ‘White box testing | ‘Black box testing Gray box tesiing | eo, ling 264 nitions peopl + ‘Three potients died and three others were badly injured in 1985 when a software glitch ‘caused Canadk!s Therae-25 radiation treatment system to fil and delver-deadly radiation doses to patients In May 1996, a software eror led to the ccediting of 920 million US dollars to the bank sccounts of 823 clients of s large USS. bank. » ‘+ In April 1999, a software error resulted in the fuilure of a $1.2 billion military satelite Jaunch, making it the most expensive acident in istry. EEE What are the Benefits of Software Testing ? “The following are advantages of employing sofware esting One ofthe key benefits of software testing is that itis cost-effective. Timely testing of any IT projet enables you to make long-term financial savings. If fas are found sooner inthe software testing process, ning tiem is es expensive «Security : This perilous and deat advantage of sofware testing People ae serciog for reliable goods. esis in eradicating hazards and issues ary + Product quality: Any software prodict mist meet this enter, Testing gurances that buyers gta high quality produ + Customer satisfaction; Providing consumers with contentmentis the primary goal of every roduc. The optimum user experiences made guaranteed of through UVUX testing KEES type of Sottware Testing 1. Manual testing ‘+ The process of checkitg the functionality of an application as per the customer needs ‘without taking any help of automation tools is known as manual testing. While performing ‘the manual testing on any application, we do not need any specific knowledge of any testing tool, rather than have a proper understanding ofthe product so we can easily prepare the test document, TEGHWCAL PUBLICATIONS® an up tt for browne “Sas rae] revere [conta era wegen [-eetomanes eg Sym eng Cvs xing User acceptance tocing Fig. 11. Type of software testing ‘+ Manual testing canbe farther divided into thre types of testing, which areas follows © Whitebox testing 6 Black box-esting 6 Gray box testing, 2. Automation testing: + Aulomaton esting is pocess of covering any maui et aes ino the test seis with the hl of etomation tas or ny programing language is known as atomation testing. [With he sp of automaton ting we can enkance te speed of ou test encuton because ere, we do at eure any human fos. We need 10 wie aes sr and execute those sei BE back Box Testing and wi Blackbox esting all function esting i testing that goes he intel mechani of a sysem or component and focuses sly on the oupus generated in repose to Seeted inputs and execution condton. White box esting (so ald ctu sing and ls box esting is tesing th kes ino cunt te nie mechanismf system or component Box Testing What is White-Box Testing ‘+ Testing a system in a "black box” is doing so without knowing anything about how it ‘operates within, A tester inputs data and monitors the output produced by the system being tested. This allows for the identification of the system's reaction time, usability difficulties ‘and reliability concers as well as how the system reacts to anticipated and unexpected user activities TECHNICAL PUBLICATIONS® -an up: or noulege| Software Testngand Automation 16 Foundations of Software Testing, ‘+ Becaus¢ af the systems internal viewpoint, the phrase "white box" is employed. The term “clear box,” "white box" or "transparent box" refers to the capebilty of seeing the software's ‘nner workings through is exterior layer. + Developers carry it out before sending the programme to, the testing team, who then ‘conducts blazk-box testing, Testing the infrastructure of the applicatoa is the primary goal of white-box testing. As it covers unit testing and integration testing, itis performed at lower levels. Given that it primarily foouses on the code structure, pathways, conditions and i ‘branches of a programed o piece of softwar, it necessitates programming skills. Focusing. i on the inputs and outpuls via the prograrime and enhancing its security are the main I objectives of white-box testing + Tis also referred to as ansparent testing, code-based testing, structural testing and clear box igoriths, | testing. Iisa good ft and is recommended for test HERI pes ot ite Box Testing in Stare Testing White box testing sa ype of software testing that examines the internal state and design of «program or pplication. The flowing are some cimmon pes of white box esting 1. Uni testing: Tests individual unis or components ofthe softve to ensure ey function asintended. 2, Integration testing: Tessie interactions between diferent units or components ofthe softvae to ensue they work ogee correct 4. Functional testing + Tests the functionaliy'of the software to ensue it meets the requirements and spins 4. Performance testing : Tests the perfomance ofthe software under vais loads and conditions to ensue meets performance requirements Security texting: Texts the software for vulneabilies and weskneses to ensure iis 6 Code coverage testing : Measures the percentage of code tat is executed during test toensre that ll paris ofthe ade ae tested 1. Regresion testing: Tess the software afte changes have been made o ensine thatthe changes dd not iroduce new bugs ress. FERED rectnigues of wite Box Testing } ‘There are some techniques which is used for white box testing ~ ‘Statement coverage : This testing approach involves going over every statement in the code to make sure that each one has been run at least once. As a result, the code is checked i Tine by line. ‘Software Testing are Automation 17 Foundations of Setware Testing 2. Branch coverage: Is testing approach in which test cases are crested to ensure tht each branch is tested at last once. This method examines all potential configurations for the system. ath coverage is a Software testing approach that defines and covers all potential pathways. From system entrance to ext points, pathways are statements that may ‘be executed. It takes alot of ine. 4. ‘Loop testing : With the help ofthis telanique, loops and values in both independent and dependent code are examined. Errors often happen at the start and conclusion of loops. ‘This method included testing loops ~ 3. Path coverage + Concatenated loops ‘© Simple loops ‘© Nested loops 5, ‘Basis path testing : Using this methodology, control Now diagrams are ereted from cate and subsequently calculations are made for cyclomatic complenty. For the purpose of designing the fewest possible test cases, eyelomatie complexity specifies the quantity of separate routes, Advantages of White Box Testing 1. Complete coverage. 2, Better understanding of the system. 3. Improved code quality 4, nerease efficiency. 5, Barly detection of er, Disadvantages of White Box Testing “This testing is very expensive and time-consuming, Redesign of esde nocds test cases to be written again, Missing functionalities canno: be detected. ‘This technique can be very complex and at times not realistic White-box testing requires « programmer with a high level of knowledge due to the! complexity of the level of testing that needs to be done. | TECHNICAL PUBLICATIONS? -an uptrust or trode TECHNICAL PUBLICATIONS® - an up-hust fer noniedgeSofware Testing and Automaton 18 |What is Black Box Testing ‘Testing a system in a "back box” is doing so without knowing anything about bow it operates within. A Gster inputs dats. and monitors the output produced by the system being tested. This allows for the identification of the system's reaction time, usability ditficulties and reliability concems as well as how the system reacts to anticipated and unexpected user ative. + Because ittests.a system fom begining to finish, black box testing is a potent testing sethod. A fester may imitate user action to check if the system fll its promise, much as ‘end users "don't care" how a system is programmed or designed and expect to get suitable answer to their requests. A black box test assesses every important subsystem slong the including the UVUX, database, dependencies and integrated systems, as well asthe web sever or application server. ‘Testes donot require technical owed, péogammring oT sil PB Tests can be executed by crowdsourced or simply model common user behavior Types of Black Box Testing Black box testing can be applied to three main types of tests: Functional, nonfunctional and regression esting. 4. Functional testing ‘© Specific aspects or operations ofthe programme that is being tested may be tested via black box testing. For instance, make sure thatthe right user credentials may be used to fog in aid that the incorrect ones cannot, TECHNICAL PUBLICATIONS® a ups forkronfoige Feundatons of Sofware Testing (smoke testing/sanity testing), en how well the system works as a whole (system testing) or (nthe integration ofits essential components 2. Nonfunctional testing + Beyond features and fimetioning, black box testing allows for the inspection of extra software components. A non-functional test examines "how rather than "ifthe programme can carry out a certain task, + Black box testing may determine whether software is 4) Usable and simple for is uses to comprehend: ») Performant under prediced or peak loads; Compatible with relevant devices, sreen sizes, browsers or operating systems; ©) Exposed to security flaws or frequent security threats. 3. Regression testing ‘+ To determine if new software version displays @ regression or a deerease in capabilities, {rom one version tothe nex, black box testing may be employed. Regression testing may be sed to evaluate both functional and non-functional features ofthe programme, such as when «particular feature no longer functions as anticipated in the new version or when a formerly fast performing action becomes much slower in the new version, FEZ pice sox texing Teinigues 1. Equivalence partitioning : ‘Testing professionals may orgarize potential input into "partitions" and test just one sample input from each category. For instance, i is sufficient for testes to verify one birth date in ‘he "under 18" group and one date in the “over 18° group if a system asks for a users birth date and retums the same answer for users under the age of 18 and a different response for users over 18, 2. Boundary value analysis, ‘+ Testers can determine ifa system responds differently around a cettain boundary value. For instance, « particular field couid only support values in the range of 0 and 99. Testing personnel may concentrate on the boundary values (-1, 0, 99 and 100) to detenmine if the system is appropriately accepting and rejecting inputs TECHRICAL PUBLICATIONS® an opti for owed4-10 Foundations of Saftare Tasting ‘Numerous systems provide results depending on a set of parameters. Once "rules" that are combinations of criteria have been identified, each rule's eonehaston cas then be determined and test caes may then be created foreach rule. FI Differences between Black Box Testing Vs White Box Testing - White box testing Foundations of Sofware Testing Dats ow esting ‘+ Branch testing 1 Tapes of white tox tesing "s Puhtesing + Loop resting + Condon testing ‘or programme, | Wie bax tengo ae implemen, 7 Knowledge of implementation is required. GE isthe nner or the internal sofware testing. eis most time consuming: 7 Teale for algorithm eng. Se a ce Trias anche se 2 Example : By input to check and verify loops. 5) Is comparatively mor exhaustive than bac box > testa HEM software Testing Life Cycle A testing technique called the Softwae Testing Lie Cyele(STLC) may effectively help yo si sftwane quality egies, Systm esting mandates by STL and is cutout in stages, Allhogh STLC and Softvare Development Life Cyele (SDLC) are someimes misunerstood, STUC i more cocemed with teting and SDLC is conceeed with te whole developmen proces, Conta eng fora died analysis of STLC' six stages, Lifecycle : What is it? ‘Simply said, @ Tifeeyete is the progression of changes from one form to another. Any physial,or intangible object is susceptible to these alterations. Everything has a lifespan ‘rom creation through death or retirement ‘+ Software is @ comparable example of an entity, Testing includes actions that need to be carried out ina certain order, much a building software does. ‘© The testing ie eyee is phenomenon thet refers to the systematic and planned execution of testing operations. What is the STLC (Software Testing Life Cycle) 7 The term "Software Testing Life Cycle" refers toa sting procedure with particular phases that "must be carried out in a certain ofder to guarantee thatthe quality objectives have been reached. Exch stop,of the, STLC process is completed in a planned and orderly manner. Goals and ‘eliverabes are vary for each phase. The STLC stages vary depending onthe organization, but the fundamentals are the same. ‘ [Below are the phases of STLC 1, Reguizemens phase 2. Planning phase TEGHNIGAL PUBLICATIONS? “an upihrust forkroedge TEGIAICAL PUBLIGATIONS® -anop tit or krowiodge‘Software Tasingand Automaton 1-7 a 4 5. 6 1 8 4 Feundatons of Sowa Tati Analysis phase Design phase Implementation phase Execution phase Concson phase Closure phase |. Requirement phase : Anal¥ses and research the requirements throughout this phase ofthe ‘STLC. Participate in brainstorming discussions with other teams to see if the criteria can be tested. The scope of the testing is determined at this step. Inform the team during this phase if any feature cannot be tested so thatthe mitigation approach may be prepared. The planning phase : Is the initisl stage’ of the testing procedure" in real-world circumstances. Thé actions and resources that will help us achieve the testing’ goals are identified at this phase. We also stive to determine the metrics end the procedure for collecting and monitoring such indicators during planning. ‘What isthe foundation forthe planning ? only prerequisites? [NO isthe response. While requirements cetainly serve as @ foundation, there are also two ditional highly significant aspects that affect test preparation, Which are ~ Assess the organization's strategy. ~ Risk management and mitigation, as well a5 risk analysis. [Analysis step : The "WHAT" to be tested is determined inthis STLC step. Basically, the ‘requirements document, product hazards and other tet bases are used to determine the test ‘circumstances. The requirement should be able to be linked back to the test condition. ‘The determination of test conditions is influenced by a number of variables, including Testing levels and depth, = The product’ complexity, ~~ Project- and product-related risks ~The lifecycle of software development is included = ‘Test administration. ~The teams abilities and experts, ~The stakeholders! accessibility. ‘We need to make an effort to accurately capture the test circumstances in writing." You ‘may, for instance, include the test condition "User should be able to make a payment” for ‘an ecommerce web application, The user should be allowed to make payments through 1NEFT, debit eards and credit cards or you might specify it by specifying i Software Testing and Automaton a9 Foindatons of Sofware Testing Since the test cases will be produced based on the test condition, these details will prompt the production of more thorough test cases, which will ultimately enhance the coverage, \which is the most significant benefit of creating the detailed test condition. ‘Additionally, decide on the testing’s exit criteria or the circumstances under which you will halt the exam, I. Design phase In this step, "HOW" to testis defined, The duis inthis phase include : Describe the test condition, To enhance coverage, divide the est conditions into many smaller sub-conditons. + Locate and collect the test data, ~ Identify the test environment and setitup. ~ Develop the traceability metrics for requirements + Produce metrics for test coverage. Implementation phase : The construction of thorough test cases is the main undertaking inthis STLC phase. Determine the test cases! cxderof importance and which test cases will be included in the regression suite. It is crucial to do a review f confirm the accuracy of the test cases prior to finalizing them. Don't forget to sign off on the test cases before beginning the real execution as well I your project incorporates automation, choose the test cases tha should be automated and ‘begin scripting them, Remember to review them! Execution phase : As its name implies, this isthe stage ofthe software testing life cycle hen actusl exeetion oveurs. However, make sure thet your entrance requirement is satisfied before you begin your execution. Execute the test cases and in the event of any Aiscrepancy, report the faults. Fill up your tacebility metrics simultaneously to monitor your progres. CConclasion Phase : The ext esterie and reporting are the main ties f this STLC pase ‘You may choose whether to send outa daily eport or a weekly repon, et, depending on your projec andthe preferences of your stakeholders. ‘The main thing to remember is that the substance of the report varies and relies on ‘whoever you are sending your reports to. Tete ate many sort: of reports (DSR - Daly Stats Report, WSR - Weekly Status Reports that you may send. Include the technical aspects ofthe project in your report (numberof test cases succeeded, fle, defets reported, severity | problems, etc.) if your project managers have a testing background since they wil be more intrested in the technical side ofthe project. However, if you are reporting to higher stakeholders, its possible thst they won't be intersted in the technical details; instead, fcus on the risks tal the ttn has helped to reduce TECHNICAL PUBLICATIONS® -an up-to kromioge TTEOHNICAL PUBLICATIONS® an ophut r awadge‘Sefurite Testiog ond Automaton 114 Foundtons of Sotware Testing 8. Closue phase : The following tasks are part ofthe closure activites ‘Verify that the test hae been completed. Whether all test scenarias are run or intentionally mitigated, Verify that no faults of severity 1 have been opened Hold meetings 10 discuss lessons leamed and produce @ paper detailing them (lnclude what worked well, where changes are needed and what may be done better) HBB V.Model of Software Testing ‘+ Also known as the verification and validation model, the V-model. Ths requires that each stage of the SDLC be completed before moving on to the next. The waterfall model's ‘sequential design approach is also followed. The device's testing is schedaled concurrently With the relevant stage of development Devoiope' fe cycle ‘eaters ie cyte Fig. 1.54 V-model ‘+ Verification is a static analysis technique (revew) caried out without actually running any code, To determine'f certain criteria are met, the product development process is evaluated. Testing is done by inning code and valiation comprises dynamic analysis methods (functional and non-functional). After the development phase is complete, the software is ccelegorized through the validation step to sce whether it satisfies the needs and expectations client Seftware Testing se hutomation 1235 Foundations of Sonware Te restng + Therefore, the V - model festues validation stages on ene side and verification phases on the other. Coding phase joins the verification and validstion processes in a V-shape. As 2 result, itis known as V = model ‘Play video in backward skip 10 there are many stages in the V - model's verification phase 1. Business requirement analysis : This is the inital phase in which customer-side product needs are understood. To fully comprehend the expectations and precise needs ofthe consumer, tis step involves comprehensive discussion 2. System design : System engineers utilise the user requirements document to analyse and comprehend the business ofthe proposed system at this level, 13. Architecture design : The frst step in choosing an architecture is (o have u solid understanding of everything that wil be included, sich asthe lst of modules, ashoit