Unit 01 Basics of Software Testing and Testing Methods 14 Marks Course Outcome: Apply various software testing methods (C 22518.1) Content: > Software Testing, Objectives of Testing > Failure, Error, Fault, Defect, Bug Terminology > Test Case, When to Start and Stop Testing of Software (Entry and Exit Criteria) > Verification and Validation (V Model) , Quality Assurance, Quality Control > Methods of Testing: Static and Dynamic Testing > Box Approach : Static Testing- Inspections, Structured walkthroughs, Technical Review Structural Testing- Code Functional Testing, Code Coverage Testing, Code Complexity Testing > Black Box Testing: Requirement Based Testing, Boundary Value Analysis (BVA), Equivalence Partitioning (EP) ‘Scanned with CamScanner11 Software Testing, Objectives of Testing, Goals of Testing 1.1.1 Introduction ‘The success of any software product or application is greatly dependent on its {UalityToday, testing is seen as the best way to ensure the quality of any product. Quality testing can greatly reduce the cascading impact of rework of projects, which have the capability of increasing the budgets and delaying the schedule. The need for testing is increasing, as businesses face pressure to develop sophisticated applications in shorter timeframes. Testing is a method of investigation conducted to assess the quality of the software product or service. It is also the process of checking the correctness of a product and assessing how well it works. Introduction The process of testing identifies the defects in a product by following a method of comparison, where the behavior and the state of a particular product is compared against a set of standards which include specifications, contracts, and past versions of the product. Software testing is an incremental and iterative process to detect a mismatch, a defect or an error. As pointed by Myers, “Testing is a process of executing a program with the intent of finding errors”. According to IEEE 83a, “Software testing is the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements.” L1.2 Software Testing Testing is defined as “execution of @ Work product with intent to find a defect”. OR Software Testing is defined as “a process of executing a program or software with the intend of finding errors, verifying against requirements.” OR “Software testing is the process of exercising or evaluating a system or sofiware by ‘manual or automated means to verify that they satisfies requirements or to identify difference beoween expected and actual results” The primary role of software testing is HGtt6 UEORStTate flthelCorTECtTESS Or) Software product, but to expose hidden defects so that they can be fixed. The purpose of software testing is ASSUFARGE OF quality) Software testing can be stated as the process of validating and verifying that a computer _ program / application/product / services to meet the requirement / expectations of user / customer. Software testing process must be planned, specified, designed, implemented and quantified, Testing must be governed by the quality attributes of the software product. ‘Thus, testing is a dual-purpose process, as it is used to detect bugs as well as to establish confidence in the quality of software. ‘Scanned with CamScanner1.1.3 Objectives of Testing Software testing not only ensures that the product functions properly under all conditions but also ensures that the product does not function properly under specific conditions. Objectives of testing are listed below: 1 FindingError: Testing is a process of executing a program with the intent of finding an error. A successful test is one that uncovers an undiscovered error. 2. Creating lGeoa Test CAs: A good test case is one that has a high probability of finding undiscovered error. 3. Quality Improvement: Testing should systematically. uncover different @hsses of errors in a minimum amount of time and with a minimum amount of effort. 4. Satistyingy"| Customer Requirements: A secondary benefit of testing is that it demonstrates that’ the software appears to be working as stated in the specifications. S. R@iability|/aNa QUAM;EY: The data collected through testing can also provide an indication of the software's reliability and quality. But, testing cannot show the absence of defect it can only show that software defects are present 1.1.4 Goals of Software Testing The main goal of software testing is to fiii@/BUGSaS|/EMYAS|POSSIBIE and to fix bug and to make sure that the software is bug free. SLAMS to three major categories as below. Immediate Goals = Bug discovery = Bug prevention Long-term Goals = Reliability = Quality Software testing = Customer satisfaction = Risk management Post-implementation Goals = Reduced maintenance cost m= Improved testing process Fig. 1.1 Goals of testing ‘Scanned with CamScannerShort-term or immediate goals of software testing: These goals are tie\iniinediate FESUlIS/aNGr perforin TESHIAG. These goals even may be seit thelindividual phases ofSDEC. Some of them are completely discussed below: © Bug discovery: The immediate goal about software testing is to find errors at any stage of software development. More the bugs discovered at early stage, better will be the success rate about software testing. © Bug prevention It is the({@onsequEE|aetiON of bug discovery. From the behaviour and analysis of bugs discovered, everyone in the software development team gets to learn how to code so that bugs discovered should not be repeated in later stages or future projects, ‘Though errors always cannot be prevented to zero, they can be minimized. In this sense prevention of a bug is a superior goal of testing. Long-term goals of software testing: - These goals affeet{thelprouuct qualitylinlth®WeSpRIR, when one cycle of the SDLC is over. Some of them are completely discussed below + Quality: Since software is also a product, so its quality is primary from the user's point of view Thorough testing ensures superior quality Quality depends on. various factors, suChl/ais) CoRecthiessy iitesrityy) So to achieve quality you have to achieve all the above mentioned factors Of Quilty, Customer satisfaction: From the user's perspective, the prime goal of software testing is customer satisfaction only. If we want the client and customer to be satisfied with the software product, then testing should be complete and thorough. A complete testing process achieves reliability, reliability enhances the quality, and quality in turn, increases the customer satisfaction Post-implementation goals of software testing: - These goals are becomeessential /after the /product/is\released. Some of them are completely discussed below: © Reduced maintenance cost The maintenance cost about any software product is not its physical cost, as effective software does not wear out. The only maintenance cost in a software product is its failure due to errors. Post- release etrors are always costlier to fix, as they are difficult to detect. Thus. if testing has been done rigorously and effectively, then the chances about failure are minimized and as a result of this maintenance cost is reduced. + Improved software testing process A testing process for one project may not be blooming successful and there may be area for improvement. Therefore, the bug history and post- implementation results can be analyzed to find out snags in the present testing process, which can be determine in future projects. ‘Thus, the long-term post-implementation goal is to improve the testing process for future projects. ‘Scanned with CamScanner1.1.5 Software Testing Life Cycle (STLC) Fig, 1.2 Software Testing Life Cycle Below are the phases of STLC: Requirement Analysis: During this phase of STLC, AialySe\akid (study que requIFEMIEntsy| Have brainstorming sessions with other teams and ty to find out whether the requirements are testable or not. Til PRESE!HEISItO identify the Cope TOF HENLESHING! If any feature is not testable, communicate it during this phase so that the mitigation strategy can be planned. Test Planning: In this phase, we identify the activities and resources which would help to meet the testing objectives. Test Planning is the most important phase of Software testing life cycle where all testing strategy is defined. ‘This phase is also called as Test Strategy phase. In this phase, the Test Manager is involved to determine the effort and cost estimates for the entire project. It defines the objective & scope of the project. Test Case Development: The Test case development begins once the test planning phase is completed. This isithe phase of STLC where testing team notes the’ detailed test cases! Along with test cases, testing team also prepares the test data for testing. Test cases need to be simple and transparent. Test Environment Setup: Test Environment consists of elements that support test execution with software, hardware and network configured. Test environment configuration must mimic the ‘Scanned with CamScannerproduction environment in order to uncover any environment/configuration related issues. 5. Test Execution: Test execution isthe process of €XGCULNg Une eee an Comparing Ne EXPEC and actual results. Following factors need to be considered for a test execution process 6. Test Cycle Closure: Testing team will meet, discuss and analyse testing artifacts to identify strategies that have to be implemented in the future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in the future. 1.15 Role of Tester wees or Methodology Specialist 1.2 Failure, Error, Fault, Defect, Bug Terminology 1.2.1 Failure, Error, Fault, Defect 7 is E j z Failure can be defined as, "that TAEERTSASGRWATERCERNUCHGES Failure is the inability of a system or component to perform — required function according to its specification. In other words, a failure is the state or condition of not meeting a desirable or intended objective/ goal. Failure occurs when fault executes. If under certain environment and_ situation defects in the application or product get executed then the system will produce the wrong results causing a failure Failures can be caused because of the following reasons: 1. Environmental conditions, which might cause hardware failures or change in any of the environmental variables. Human Error while interacting with the software by keying in wrong inputs. Failures may occur if the user tries to perform some operation with intention of breaking the s ‘stem, ‘Scanned with CamScanner2. Erro Error refers to Aiffer@nics| Between VACtual| OutpaiidEXPECIEU OUEpE An error is a mistake, misconception, or misunderstanding on the part of a software developer. In the category of developer we include software engineers, programmers, analysts, and testers. For example, a developer may misunderstand a design notation, or a programmer might type a variable name incorrectly — leads to an Error. It is the one which is generated because of wrong login, loop or due to syntax. Error normally arises in software; it leads to change the functionality of the program. Error can be caused because of the following reasons: 1. Because of some confusion in understanding the functionality of the software. 2. Because of some miscalculation of the value, 3. Missing commands, wrong syntaxes, 3. Fault: Itis a condition that causes the software to LAiINGIPCHORA SSH UAEORORCHON An incorrect step, process or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. A fault is introduced into the software as the result of an error. It is an anomaly in the software that may cause it to behave incorrectly, and not according to its specification. It is the result of the error. The software industry can still not agree on the definitions for all the above. 4. Defect : It commonly refers to several troubles withsithe software productsi™Wwith its external behaviour or with its intemalifeatures. A defect is an error in coding or YogiSAhat causes a program to fail or to produce incorrecVunexpected results. Defect can be interface defects, documents defects, initialization defects or any general coding defects inclu Various effects of a defect are listed below: 1. Performance of a system may not be acceptable and the system does not perform as. per expectations/specification of customer and it may result in rejection of the project/system. 2. Security may be a problem, as the system may be open to external attacks ‘There may be loss of data, information, hacking or any other problem in the system which makes it vulnerable. 3. Functionality required but not available in the product delivered to the customer. Something which customer needs but it is not available in the product. 1.22 Bug Terminology A Software bug Ogeurs When one oF more ofthe following five rues is true: 1. The software @oe8” Rot" do Something that the product specificaion Saysit should do, 2. The software does’ Something) that the” product” specification Says Should notdo 3. The software doesINOMeUIg tau produetspeCifieation’ "doesnot mention. 4. The software doesnot dor something that the'product specification "does ‘not mention” but should ‘The software is difficult to understand, hard to use, slow. ‘Scanned with CamScannerTo better under calculator. ‘and each rule, try the following example of applying them to a The specification for a calculator probably states that it will perform correct addition, subtraction, multiplication, and division. If you, as the tester, receive the calculator, press the + key, and nothing happens, that's a bug because of Rule #1. If you get the wrong answer, that’s also a bug because of Rule #1 The product specification might state that the calculator should never crash, lock up, or freeze. If you pound on the keys and get the calculator to stop responding to your input, that’s a bug because of Rule #2. Suppose that you receive the calculator for testing and find that besides addition, subtraction, multiplication, and division, it also performs square roots. Nowhere was this ever specified. An ambitious programmer just threw it in because he felt it would be a great feature. This isn't a feature—it's really a bug because of Rule #3. ‘The software is doing something that the product specification didn’t mention. This unintended operation, although maybe nice to have, will add to the test effort and will likely introduce even more bugs. The fourth rule may read a bit strange with its double negatives, but its purpose is to catch things that were forgotten in the specification. You start testing the calculator and discover when the battery gets weak that you no longer receive correct answers to your calculations. No one ever considered how the calculator should react in this mode. A bad assumption was made that the batteries would always be fully charged. You expected it to keep working until the batteries were completely dead, or at least notify you in some way that they were weak. Correct calculations didn't happen with weak batteries, and it wasn't specified what should happen. Rule #4 makes this a bug. Rule #5 is the catch-all, As a tester you are the first person to really use the software. If you weren't there, it would be the customer using the product for the first time. If you find something that you don't feel is right, for whatever reason, it's a bug. In the case of the calculator, maybe you found that the buttons were too small. Maybe the placement of the = key made it hard to use. Maybe the display was difficult to read under bright lights. All of these are bugs because of Rule #5. ‘Scanned with CamScanner1.3 Test Case, When to Start and Stop Testing of Software (Entry and Exit Criteria) 1.3.1 Test Case: A TEST CASE is a fet of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. The process of developing test cases can also help find problems in the requirements or design of an application How to write a good test case? ‘Test case is an important document from validation of system perspective. These must be written at each stage of validation from unit test till acceptance testing. Basic principles of writing a good test case are: 1. Test case must be testable. Tester should know what is to be done when to wait for system to do it. played’ replied by the system on screen at each step. And Inform tester each transaction dis wait for user response. 4, Use Simiple conversational language) for writing test case, Whighlimproves’ Clarity anid) avoid communication losses. 5. Use Consistent nanies( oF fields) iust{be USeUPin/pIaeS(OFEHEHCTNAMES. Any change in field name must be incorporated in test cases. 6. Tester should aWare Windows BASICS! ‘TMOrder of the test cases must follow BUSES SCCHAFONAVOIM time wastage, Common Mistakes in writing test cases: 1, Making test cases too long and combining {S¥OTGH INOS KGStGHSeS in Single TeSt'SHOUIA|b) avoided 2. Incomplete, incorrect, and incoherent test cases can create confusion and frustrate testers. 3. Steps should be made very clear in test ease steps. 4, Test case changes must be updated in software user interface. 5. Define pass/fail criteria correctly, ice. test are successful or not, there is a defect or not? The sample test case template is as follow. Test Case ID: ‘Test Designed By: ‘Test Priority (Low/Medium/High): ‘Test Designed Date: Module Name: Test Executed By: Test Title: Test Executed Date: Description: | | test | Test Data (/P | Expected | Actual _ Status Step BPreconditin eceneli | Dela) Result Result | (Pass/Fail) Where 1. Test Case ID: Unique ID for each test case 2. Test Priority (Low/Medium/High): This is useful while test execution. Test ss rules and functional test cases can be medium or higher. Test priority for busin priority should be set by reviewer. 3. Module Name: Mention name of main module or sub module. 9 ‘Scanned with CamScanner% 10. i. 12. 13. 14. 15. Test Designed By: Name of tester. Test Designed Date: Date when wrote. Test Executed By: Name of tester who executed this test. Tobe filled after test execution, Test Execution Date: Date when test executed Test Title/Name: Test case title. For example, verify login page with valid username and password. Test Summary/Description: Describe the test objective in brief. Pre-condition: Any prerequisite that must be fulfilled before execution of this test case. List all pre-conditions-in order to successfully execute this test case. Test Steps: List all test execution steps in detail, Write test steps in the order in which these should be executed. Make sure to provide as much details as you can. Tip - to efficiently manage test case, with lesser number of fields use this field to describe test conditions, test data and user roles for running test. Test Data: Use of test data as all input for this test case. You can provide different data sets with exact values to be used as an input. Expected Result: What should be the system output after test execution? Describe the expected result in detail including message/error that should be displayed on screen. Actual Result: Actual test result should be filled afier test execution. Status Pass/Fail: If actual result is not as per the expected result mark this test_as failed, Otherwise update as passed; 1.3.2 When to Start and Stop Testing of Software (Entry and Exit Criteria) It is not possible to test the software at any time during its cycle. The next two steps state when tes ing should be started and when to end (stop) it during the SDLC. 1, When to Start Testing: Testing sirts right from the requirements phase and continues. til the end of SDLC. An early start to testing reduces the cost, time to rework and error free software that is delivered tothe client. | However in Software Development Life Cycle (SDLCyesting : from the Requirements be started Gathering phase and lasts till the deployment of the software However, it also depends on the development — model that is being used. For example in Water fall model formal testing is conducted in the Testing phase, but in incremental model, testing is performed at the end of every incremenviteration and at the end the whole application is tested. ‘Testing is done in different forms at every phase of SDLC like during Requirement gathering phase, the analysis and verifications of requirements are also considered testing. Reviewing the design in the design phase with intent to improve the design isalso considered as testing. Testing performed by a developer on completion of the code is also categorized as Unit type of testing. 10 ‘Scanned with CamScanner2. When to Stop Testing: © Unlike when to start testing it is difficult to determine _ when * To stop testing, as testing is a never ending process and no one can say that, any software is 100% tested. Following are the aspects which should be considered to stop the testing: Exit Criteria: Entry Criter + Complete taceabiity A Steps: betwen sgn and ss to art programming 1, Evolve an architecture 2. Perform high level design 3. Perform detailed/ low level design 4, Write program spaces Output: ‘Approved SRS yndocuments Program specications Fig. 1.4 Entry and Exit Criteria ‘Scanned with CamScanner1.4 Verification and Validation, V Model 1.4.1 Verification and Validation 1 1 Verification ‘This PROCESS|[OF [EVAlUALINgSOAWAFE) 10 determine whether the products of a given development phase Satisfy the Conditions imposed atthe start of that phase: Verification is a staticypractice of Verifying documents//desien, cOde|and programy It includes all the activities associated witlproducing high quality softwares inspection, design! LYS SPELATCALION BHAVSS, isa relatively objective process. Verification will help fo determine Whether the SOnware iO high’ qualiybut ie Wil Not, Advantages of Verification: 1. Verification helps in TOW@HIRGUASWA IHECOUNEGNINEYAREst in the later stages of development. 2. Verifying the product at the starting phase of the development will help in 3. TEFSUCES'the" ChancesOf failures in the software application or product. 4. Ithelps in building the product as per the customer specifications and needs. 5. It can confirm that the work product has followed the processes correctly as, defined by an organization or customer (as the case may be). 6. Verification can reduce _ the cost of finding and fixing defects as each work product is reviewed and corrected faster. Sometimes, defects are fixed as and when they are found. 7. Verification can locate ‘the defect easily as the work product under review is yet to the integrated with other work products. Cost Of fixing defect is less as there is no/minimum impact on other parts of software. Disadvantages of Verification 1. Actual working software may not be accessed by verification, as it does not cover any kind of execution of a work product. ‘fit for use’ cannot be asses seq in verification. 2. Verification cannot show whether the developed software is corrector not. Rather, it shows whether the processes have been followed or not If Processes are not capable, then the outcome may not be good 12 ‘Scanned with CamScanner1.4.1.2 Validation ion can be defined as the prOCeSSTOReValiating asiSySteMiOreOMponeMt during or at the end of the development process to determine whether it satisfied requirements, Validation is discipline approach to evaluate whether the final built software product fulfil its specific intended use. It is meant to validate the requirement as defined in requirement specification, ensure that the application as developed matches with the requirements defined and is fit for the intended or future use, Advantages of validation: mis If during verification some specification inderstood and development had happened then during. validation process while executing that functionality the difference between the actual result and expected result can be understood, 3 4, It is generally independent of the platform of development, database or any technical aspect related to software development. Disadvantages of validation: 1, Sometimes, it may result into redundant testing as the tester is not aware of internal structure and same part of the code gets executed again and again. 2. No amount of testing can prove that software does not have defects. If defects are not found by conducting the defined test cases, we can only conclude that there is no defect in the set of” transactions actually executed. There can be many more defects not captured b y these test cases. 13 ‘Scanned with CamScanner14, 3 Difference between Verification and Validation Sr. Verification Validation No. The ing process includes : e It is a dynamic mechanism of testing 1 checking documents, design, code, and ‘ 8 8 and validating the actual product program 2 | Itdoes not involve executing the code | It always involves executing the code Verification uses methods Tike reviews, | It uses methods like Black Box Testing, 3. | walkthroughs, inspections, and desk-| White Box Testing, and non-functional checking ete. testing Whether the software conforms to It checks whether the software meets the requirements and expectations of a customer Tt finds bugs early in the development It can find bugs that the verification 5 cycle process cannot catch Target is application and software architecture, specification, complete Target is an actual product © | design, high level, and database design | 1" » etc (A team does verification and make & With the involvement of testing team 7 | sure that the software is as per the validation is executed on software code. requirement in the SRS document. 8 | tcomes before validation i comes after verification 14 ‘Scanned with CamScanner1.4.2 V Model ‘The V-model is a type of SDECIHGAE! where process executes in a SUE HANNE Sipe. It is also known as eifiation an Validation’miodel It is based on the association of a testing phase for each corresponding development stage Development of each step directly associated with the testing phase. The next phase starts only after completion of the previous phase ie, for each development activity, there is a testing activity corresponding to it. Requrement Preparation of aceplance est case vat Ananss rene Sysemstest cases System Testing arcorecurl | pegratontetcases wodaesenen || UE |_Cunatestne Coane Fig. 1.5 V Model So V-Model contains side. Verification and Validation phases are joined by coding phase in V-shape. Thus it is called Verification Phase (Design Phase): It involves static analysis technique (review) done without executing code. It is the of evaluation of the product development phase to find whether specified requirements proce: meet. 1. Requirement Analysis: This phase contains detailed communication with the customer to Gera Heir requirements and expectations. This stage is known as Requirement Gathering 2, System"DEsigh: This phase contains the system design and the GomipleteThardware and) conimunication setup for developing product, 3. Afehitectural Design: System design is broken down further into modules taking up different functionalities. The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood. 4, Module Designs In this phase the system breaks dowm into small modules. The detailed design of modules is specified, also known as Low-Level Design (LLD). 15 ‘Scanned with CamScanner‘Validation (Testing Phases): It involveS/@yiiaini@anlYSISMEChiigile (functional, non-functional), testing done by executing code, Validation is the process to evaluate the software after the completion of the development phase to determine whether software meets the customer expectations and requirements. 1. Unit Testing: Unit Test PIaiis/ate(Ue Veloped airing MOUUIE WEIGH PHASE. These Unit Test Plans are executed to eliminate bugs at code or unit level. 2, Integration testing: After completion of unit testing Integration testing is performed. In integration testing, the modules are integrated and the system is tested. Integration testing is performed on the Architecture design phase. This test verifies the communication of modules among themselves. 3. System Testing: System testing test the complete application with its functionality, inter dependency, and communication. It tests the functional and non-functional requirements of the developed application. 4. User Acceptance Testing (UAT): UAT is performed in a user environment that resembles the production environment. UAT verifies that the delivered system meets user's requirement and system is ready for use in real world. Advantages of V model: 1. Thisisalhighly disciplined model and Phases are completed one at atime 2. V-Model is used for S#al/)PfOJECE|where project QuIREMEHIS are Clear 3. Simple and easy to understand and use 4. This model focuses on verification and Validation activities early inthe ie cycle thereby enhancing the probability of building anerror-free and good quality product 5. Itenables project management to track progress accurately. Disadvantages of V model: 1, High risk and uncertainty, 2. This nota 260d for complex aid object-oriented projects. 3. It is not suitable for projects where requirements are not clear and contains high risk of hanging. 4, This model doesnot Support iteration of phases. 5, Ttdoes not easily handle concurrent events. ‘Scanned with CamScanner1.4.3 Quality Assurance Quality Assurance (QA) is defined as ani/Wetivity to ensure that an organization is) Quality Assurance Function There are 5 primary Quality Assurance Functions: 1, Teehniology/tramsfer: This function involves getting a product design document as well as trial and error data and its evaluation, The documents are distributed, checked and approved 2. Walidaition: Here validation master plan for the entire system is prepared. Approval of test criteria for validating product and process is set. Resource planning for execution of a validation plan is done. 3. Deeuinmentation: This function controls the distribution and archiving of documents. Any change in a document is made by adopting the proper change control procedure. Approval of all types of documents, 4. Assuring Quality of products 5. Quality improvement plans 1.44. Quality Control Software quality control is the S6tlOPPROCEUUETEsed by organizations to ensure that a software product will meet its quality goals at the best value to the customer, and to continually improve the organization's ability to produce software products in the future Software quality control refers to specified functional requirements as well as non- functional requirements such as supportability, performance and usability. It also refers to the ability for software to perform well in unforeseeable scenarios and to keep a relatively low defect rate. ‘These specified procedures and outlined requirements lead to the idea of Verification and Validation and software testing Difference between Quality Assurance and Quality Control Sr. Ne Quality Assurance (QA) Quality Control (QC) 4 [doesnot involv @ieRceutingMeprogTam | 1 always finvOlVeTENeeuTNg a prORTaM 17 ‘Scanned with CamScanner5 _ [va Preventive ecinigue 1a Conectve tesnique 6 | isin prosedure wo createthe deliverables |‘1 "yn, Me "© Mem al detiverables In order to meet the customer requirements, ]QC_ confirms that the standards are 7 | qavdefinesistanaarastandimethedologies | followed while working on the product & its performed before Quaty Comsat [, PHfomed only ater QA seiviy i) QA ensures that everything is executed inl] QC ensures that whatever we have done is | 9 | HhelghEWay, and Ua iS WhYlitfAlISuNder | as per the requirement, and that is why it | verification activity falls under validation activity It requires the| 10 1.5. Methods of Testing: The three main methods of testing are the following: 1. Structural or functional testing 2. Static or dynamic testing 3. Manual or automated testing 1.5.1 Structural or functional testing If the test cases are developed to check the actual structure of the program code, then it is called'Structural testing. Structural testing is also known as White/bOX testing, where the tester checks'the actual Cole" OF the|SORWAFE. However, in functional testing, the tester checks only the behavior of the software and will not check the actual code. The tester only checks the response of the software for predefined inputs and tests whether the software produces the desired output. Therefore, this is called black box testing. If the test cases/are developed to check how the entire system works, then it is called functional testing. During functional testing, the tester uses test eases to check how the software works, i.c., whether it produces the desired outputs for a set of given inputs. Functional testing for a calculator could check whether the software does the addition operation correctly. 1.5.1 Static Testing or Dynamic Testing Static testing refers to the SiilYSiSTOf Hie! pFOWAAN] which is carried out without executing the program. This is « typical white box testing technique, where the developer checks the code to find errors im it. It is preventive in nature and is completed in the verification phase! The common ‘methods include feasibility review and code review. €. g. Software developers perform syntax check to test syntactical correctness. Dynamic testing refers to the analysis of the program in its executable form. This is performed by supplying valid entries and is validated against the expected results, It is a curative method and is performed during the validation phase. €. g. Software developers perform unit test to check for correctness in a module. Thu: and logic of the code whereas, dynamic testing is performed to check the response of the system for predefined inputs. static testing is done to check mainly the correctnes 18 ‘Scanned with CamScanner‘Some of the important differences between static testing that makes it more effective and efficient are: 1. Since static testing is carried out during the initial stage, it is cost effective compared to dynamic testing, which is carried out once the entire software, a module, or unit is complete. Static testing detects bugs at the earliest and hence the time required to fix them is less. 1.5.3 Manual or automated testing Static Testing ‘When the software is tested by people to find the bugs, it is called manual testing process, During this test, the tester acts as an end user and uses all the features of the software, and checks to ensure that they behave correctly. Eg Performing a manual test for a login screen involves some of the following: 1. Checking whether username and password can be entered, 2. Implementing masking of password character. 3. Verifying whether the screen navigates to next page if valid login details are provided. 4, Checking the error message displayed when incorrect login details are entered. 5. Checking the maximum number of characters that can be entered in the logi and password fields. In automated testing, a sofiware program, commonly referred to as ‘a testing tool”, runs the test software, provides proper inputs, and checks the output against the expected output. A tester writes the test case, and the automated testing tools run the test software according to the test case without any human intervention. At the end of the test, a detailed report is generated to indicate the result of any condition which is defined in the test case. Manual testing requires human intervention at every stage of the testing process right from writing test cases, providing the inputs, recording the output and analyzing the actual and expected output. There is always a chance for error in manual testing. It also requires more time to perform the test. Automated testing uses testing tools to perform the test. These tools need initial human intervention for supplying test cases. These tools are very powerful and reduce the time required for testing and are very efficient in finding out bugs in software. However, huge investment is required for using automated testing tools, since the tool has to be purchased from the vendor and some investment is also required for training. For example HP’s Quality center is a popular automation tool used for testing and quality assurance 1.6. The Box Approach: White Box Testing White box testing is testing of a software solution's internal structure, design, and coding. In this type of testing, the code is visible to the tester. It focuses primarily on verifying the flow of inputs and Youtputs"xhrough Mer application, improving design and usability, strengthening security. White box testing is also known as clear box teStingh/open Box esting StrUCtUral Testing) {FGRSPUFEHELBOx testing, code-based testing, and glass box testing. It is usually performed by developers. It is one of two parts of the box testing approach to software testing, Its counterpart, black box testing, involves testing from an external or end-user type perspective. On the other hand, 19 ‘Scanned with CamScannerwhite box testing is based on the inner workings of an application and revolves around internal testing. The term "white box” was used because of the see-through box concept. The clear box or white box name symbolizes the ability to see through the software's outer shell (or "box") into its inner workings. Likewise, the "black box" in "black box testing" symbolizes not being able to see the inner workings of the software so that only the end-user experience can be tested. White box testing involves the testing of the software code for the following: 1 Ses ‘The flow of specific inputs through the code aweun ‘The testing can be done at system, integration and unit levels of software development. One of the basic goals of white box testing is to verify a working flow for an application. It involves testing a series of predefined inputs against expected or desired outputs so that when a specific input does not result in the expected output, you have encountered a bug. Advantages of White Box Testing 1 Rep Disadvantages of White Box Testing 1 2 Classification of white box testing 1. Static White Box Testing 2. Structural Testing 1. Static White Box Testing Static white box testing methodology involves testing the internal Togic/and structure"of the) code Wwithout’compiling\and running the!program. The main advantage of performing static white box testing is that bugs are found early and those that cannot be uncovered by dynamic white box are also identified. To perform this type of testing, a software tester needs to have the knowledge of software coding and the internal logic, This enables a software tester to differentiate between the statement or the path which works from those which do not work. Static white box testing involves a procedure of analyzing data flow, control flow, information flow, and also testing the intended and unintended software behaviors. There are different aspects that are examined which include codes, branches, paths, and internal logic. Let us now discuss the various methods by which static white box testing is performed. 20 ‘Scanned with CamScannera. Formal Reviews A formal review is the process under which static white-box testing is performed. ‘A formal review can range from a simple meeting between two programmers to a detailed, rigorous inspection of the software's design or its code. There are four essential elements to a formal review: What makes formal reviews work is following an established proc “getting together to go over some code" isn't sul © dehtifY—PFOBIEMS- The goal of the review is to find problems with the software not just items that are wrong, but missing items as well. All criticism should be directed at the desi created it ign or code, not the person who Participants shouldn't take any criticism personally. Leave your egos, emotions, and sensitive feelings at the door. + FOIGWIRUIES A fixed set of rules should be followed. They may set the amount of code to be reviewed (usually a couple hundred lines), how much time will be spent (a couple hours), what can be commented on, and so on This is important so that the participants know what their roles are and what they should expect. It helps the review run more smoothly. ‘SqUPFepAFE: Each participant is expected to prepare for and contribute to the review. Depending on the type of review, participants may have different roles. They need to know what their duties and responsibilities are and be ready to actively fulfill them at the review. Most of the problems found through the review process are found during preparation, not at the actual review. + WEiIENANREPOH- The review group must produce a written report summarizing the results of the review and make that report available to the rest of the product development team, It's imperative that others are told the results of the meeting—how many problems were found, where they were found, and so on, Haphazardly jent and may actually be detrimental. If a process is run in an ad-hoc fashion, bugs will be missed and the participants will likely feel that the effort was a waste of time. If the reviews are run properly, they can prove to be a great way to find bugs early. Think of them as one of the initial nets (see Figure 1.6) that catches the big bugs at the beginning of the process. Sure, smaller bugs will still get through, but they'll be caught in the next testing phases with the smaller nets with the tighter weave. In addition to finding problems, holding formal reviews has a few indirect results: ComiMnUIRIeatiONS- Information not contained in the formal report is communicated. For example, the black-box testers can get insight into where problems may lie. Inexperienced programmers may learn new techniques from more experienced programmers. Management may get a better feel for how the project is tracking its schedule. (Quality A programmer's code that is being gone over in detail, function by function, line by line, ofien results in the programmer being more careful. That's not to say that he would otherwise be sloppy—just that if he knows that his work is being carefully reviewed by his p. to triple-check it to make sure that it's right. ers, he might make an extra effort 21 ‘Scanned with CamScanner© TRAiELCARAAFAMEHE- If a review is run properly, it can be a good place for testers and programmers to build respect for each other's skills and to better ‘understand each other's jobs and job needs. SP|SolutiOAE|Solutions may be found for tough problems, although whether they are discussed depends on the rules for the review. It may be more effective to discuss solutions outside the review. Fig. 1.6 Formal reviews are the first nets used in catching bugs b. Peer Reviews: The easiest way to get team members together and doing their of the software is through peer reviews, the least formal method. Someti reviews, this method is really more of a discussion. Peer reviews are often held with just the programmer who wrote the code and one or two other programmers or testers acting as reviewers. Small group simply reviews the code together and looks for problems and oversights. To assure that the review is highly effective all the participants need to make sure that the four key elements of a formal review are in place: Look for problems, follow rules, prepare for the review, and write a st formal reviews ies called buddy report. As peer reviews are informal, these elements are often scaled back. Still, just getting together to discuss the code can find bugs. cc. Walkthroughs Walkthroughs are the next step up in formality from peer reviews. In a walkthrough, the programmer who wrote the code formally presents (walks through) it to a small group of five or so other programmers and testers. The reviewers should receive copies of the software in advance of the review so they can examine it and write comments and questions that they ‘want to ask at the review, Having at least one senior programmer as a reviewer is very important. ‘The presenter reads through the code line by line, or function by function, explaining ‘what the code does and why. The reviewers listen and question anything that looks suspicious. Because of the larger number of participants involved in a walk-through compared to a peer review, it's much more important for them to prepare for the review and to follow the rules. It’s also very important that after the review the presenter write a report telling what was found and how he plans to address any bugs discovered. 2 ‘Scanned with CamScanner. Inspections Inspections are the most formal type of reviews.{i0HEY are highly structured and require training for each participant, Inspections are different from peer reviews and walkthroughs in that the person who presents the code, the presenter or reader, isn’t the original programmer. This forces someone else to learn and understand the material being presented, potentially giving a different slant and interpretation at the inspection meeting. The other participants are called inspectors. Each is tasked with reviewing the code from a different perspective, such as a user, a tester, or a product support person. This helps bring different views of the product under review and very often identifies different bugs. ‘One inspector is even tasked with reviewing the code backward—that is, from the end to the beginning—to make sure that the material is covered evenly and completely. ‘Some inspectors are also assigned tasks such as moderator and recorder to assure that the rules are followed and that the review is run effectively. After the inspection meeting is held, the inspectors might meet again to discuss the defects they found and to work with the moderator to prepare a written report that identifies the rework necessary to address the problems. The programmer then makes the changes and the moderator verifies that they ‘were properly made. Depending on the scope and magnitude of the changes and on how critical the software is, a re-inspection may be needed to locate any remaining bugs. Inspections have proven to be very effective in finding bugs in any software deliver- able, especially design documents and code, and are gaining popularity as companies and product development teams discover their benefits. 2. Structural Testing / Dynamic White Box Testing Dynamic white-box testing, in a nutshell, is using information you gain from seeing what the code does and how it works to determine what to test, what not to test, and how to approach the testing. Another name commonly used for dynamic white-box testing is structural testing because you can see and use the underlying structure of the code to design and run your tests. Dynamic white-box testing isn't limited just to seeing what the code does. It also can involve directly testing and controlling the software, The four areas that dynamic white-box testing encompasses are ‘+ Directly testing low-level functions, procedures, subroutines, or libraries. In Microsoft Windows, these are called Application Programming Interfaces (APIs). ‘+ Testing the sofware at the top level, as a completed program, but adjusting your test cases based on what you know about the software's operation. ‘+ Gaining access to read variables and state information from the sofiware to help you determine whether your tests are doing what you thought. And, being able to force the software to do things that would be difficult if you tested it normally. ‘+ Measuring how much of the code and specifically what code you “hit” when you run your tests and then adjusting your tests to remove redundant test cases and add missing ones. Classification of Structural Testing 1. Code Functional Testing 2. Code Coverage Testing 3. Code Complexity Testing 23 ‘Scanned with CamScanner1 2 Code Functional Testing ‘This initial part of structural testing corresponds to some quick checks that a developer performs before subjecting the code to more extensive code coverage testing or code complexity testing, Thiscan happen by several methods. These are: 1, Initially, the developer can perform certain obvious tests; knowing the input variables and the corresponding expected output variables. This can be quick test that checks out any obvious mistakes. By repeating these tests for multiple values of input variables, the confidence level of the developer to go to the next level increases, This can even be done prior to formal reviews of static testing so that the review mechanism does not waste time catching obvious errors. 2. Debug version of the product by putting intermediate print statements and making sure the program is passing through the right loops and iterations the right number of times. 3. Todo the initial test is to run the product under a debugger or an IDE (Integrated Development Environment). These tools allow single stepping of instructions. Code Coverage Testing For comprehensive coverage you must also test the program's states and the program's flow among them. You must attempt to enter and exit every module, execute every line of code, and follow every logic and decision path through the software. This type of testing is known as code coverage testing. Code coverage is dynamic white-box testing because it requires you to have full access to the code to view what parts of the software you pass through when you run your test eases. The simplest form of code coverage testing is using your compiler's debugger to view the lines of code you visit as you single-step through the program. Figure 1.7. shows an example of the Visual Basic debugger in operation. he Debug toolbar The line of code being run dialog box Fig. 1.7 The debugger allows you to single-step through the software to see what lines of code and modules you execute while running your test cases. 24 ‘Scanned with CamScannerFor very small programs or individual modules, using a debugger is often sufficient. However, performing code coverage on most software requires a specialized tool known as a code coverage analyzer. Code coverage analyzers hook into the software you're testing and run transparently in the background while you run your test cases. Each time a function, a line of code, or a logic decision is executed, the analyzer records the information, You can then obtain statistics that identify which portions of the software were executed and which portions weren't, With this data you'll know + What parts of the software your test cases don't cover. If a specific module is never executed, you know that you need to write additional test cases for testing that module's function. + Which test cases are redundant. If you run a series of test cases and they don't increase the percentage of code covered, they are likely in the same equivalence pattition, + What new test cases need to be created for better coverage. You can look at the code that has low coverage, see how it works and what it does, and create new test cases that will exercise it more thoroughly. You will also have a general feel for the quality of the software. If your test cases cover 90 percent of the software and don't find any bugs, the sofiware is in pretty good shape. If, on the other hand, your tests cover only 50 percent of the software and you're still finding bugs, you know you still have work to do. Program Statement and Line Coverage- The most straightforward form of code coverage is called statement coverage or line coverage. If you're monitoring statement coverage while you test your software, your goal is to make sure that you execute every statement in the program at least once. In the case of the short program shown in Listing 1.1, 100 percent statement cover-age would be the execution of lines 1 through 4, Listing 1.1 1: PRINT “HELLO WORLD” 2: PRINT “The date is: “; Date$ 3: PRINT “The time is: *; TimeS 4: END You might think this would be the perfect way to make sure that you tested your program completely. You could run your tests and add test cases until every Statement in the program is touched. Unfortunately, statement coverage is misleading. It can tell you if every statement is executed, but it can’t tell you if you've taken all the paths through the software. b, Branch Coverage Attempting to cover all the paths in the software is called path testing, The simplest form of path testing is called branch coverage testing. Consider the program shown in Listing 1.2. LISTING 7.2 1: PRINT ‘Hello World” 2: IF Dates = ‘01-01-2021’ THEN 3: PRINT ‘Happy New Year” 25, ‘Scanned with CamScanner4: END IF 5: PRINT "The date is: 6: PRINT "The time 7: END If you test this program with the goal of 100 percent statement coverage, you ; DateS TimeS would need to run only a single test case with the Dates variable set to January 1, 2000. The program would then execute the following path: Lines 1, 2. 3. 4,5.6,7 ‘Your code coverage analyzer would state that you tested every statement and achieved 100 percent coverage. You could quit testing, right? Wrong! You may have tested every statement, but you didn’t test every branch, Your gut may be telling you that you still need to try a test ease for a date that’s not January 1, 2000. If you did, the program would execute the other path through the program: Lines 1, 2 5, 6,7 Most code coverage analyzers will account for code branches and report both statement coverage and branch coverage results separately, giving you a much better idea of your test's effectiveness. Condition Coverage Just when you thought you had it all figured out, there's yet another complication to path testing. Listing 1.3 shows a slight variation to Listing 1.2. An extra condition is added to the IF statement in line 2 that checks the time as well as the date. Condition coverage testing takes the extra conditions on the branch statements into account. LISTING 1.3 1: PRINT ‘Hello World” IF Dates = "01.01-2021" AND PRINT "Happy New Ye : END IF PRINT The date is: PRINT The time 7: END In this sample program, to have full condition coverage testing, you need to have the four sets of test cases shown in Table 1.2. These cases assure that each possibility in the IF statement are covered. TABLE 1.2 Test Cases to Achieve Full Condition Coverage ime$ = 00:00:00" THEN we 2 Dates TimeS Line # Execution (01-01-2020 TET 1.2.5.6.7 (01-01-2020 00:00:00 125.67 01-01-2021 Th 1.2.5.6.7 01-01-2021 (00:00:00 6.7 If you were concerned only with branch coverage, the first three conditions, would be redundant and could be equivalence partitioned into a single test case. But, 26 ‘Scanned with CamScannerwith condition coverage testing, all four are important because they exercise the different conditions of the IF statement in line 2—False-False, False-True, True. False, and True-True. ‘As with branch coverage, code coverage analyzers can be configured to consider conditions when reporting their results. If you test for condition coverage, you will achieve branch coverage and therefore achieve statement coverage. Code Complexity Testing Cyclomatic complexity term comes into picture which is the measurement of a source code complexity. It is calculated through a control flow graph which is developed on the basis of source code which measures the number of linearly-independent paths through a program module. ‘The target here is to have Cyclomat complexity as low as possible for the best to modify code is lower and the code will be easier to understand and maintain. Given below is the formula through which Cyclomatic complexity is evaluated. source code. If it is low then the Cyclomatic complexity = E-N + 2*P where, represents a number of edges in the control flow graph. N = represents a number of nodes in the control flow graph, represents a number of nodes that have exit points in the control flow graph. Example Let’s understand Cyclomatic complexity with the help of the below example. Here is the source code to display the values of different variables based on the comparison. I have taken 4 variables with different values. 27 ‘Scanned with CamScannerpublic static void main(Stringl] args) { int varl = 10; int var2 =9; int var3 int vard = 7; if (varl == 10) { ifvar2 > var3) { var2 = var3; } else { if (var3 > vars) { var3 = vara } else { vara = varl; } } } else { varl=vard; } System.outprintin("Printing value for varl, var2, var3, and vars" +varl+" "+var2+" "+var3+" "+vard); } Below is the representation of control flow graph based on the demo source code ibove, We will calculate the number of edges, nodes and the exit points and we have written a to calculate Cyclomatic complexity using the formula, I have marked edge as nodes as “N” in the below diagram for better understanding. 28 ‘Scanned with CamScannerControl Flow Graph: After noticing the above control flow graph, we can evaluate the following values of Cyclomatic complexity parameters. E = represents number of edges in the control flow graph = 11 edges ‘N= represents number of nodes in the control flow graph = 1 nodes. P = represents number of nodes that have exit points in the control flow graph = 1 exit point By using the formula, Cyclomatic complexity => E—N + 2*P SPL +241 =>2 Therefore, Cyclomatic complexity for the above control flow graph is 2 which is an acceptable number. In a similar way, using the same formula we can calculate the Cyclomatic complexity for any source code and based on the result, we can determine the risks and associated maintenance cost. It can be really useful for overall project budgeting. 29 ‘Scanned with CamScannerAdvantages of Cyclomatic Complexity: It can be used as a quality metric, gives relative complexity of various designs Itis able to compute faster than the Halstead’s metrics Itis used to measure the minimum effort and best areas of concentration for testing, It is able to guide the testing process Its easy to apply. Disadvantages of Cyclomatic Complexity: I 2 3 It is the measure of the program's control complexity and not the data the data complexity In this, nested conditional structures are harder to understand than non-nested structures In case of simple comparisons and decision structures, it may ive a misleading figure. 1.7 Black Box Testing Black-box (or functional) testing checks the functional requirements input and output data of these requirements. Once the specified function for which the software has been designed is known, tests are performed to ensure that each function is working properly. This is referred to as black-box test Black-box testing, also known as Behavioral Testing, is a software testi nethod in which the intemal structure/ design/ implementation of the item being tested is not known to the tester. In black-box testing, the tester only knows what the software is supposed to do he/she cannot look in the box to see how it operates. If he types in a certain input, he gets a certain output, He doesn't know how or why it happens, just that it does. It is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester. This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot Black Box Testing, also known as Behavioral Testing, is a software testing method in which the intemal structure/design/implementation of the item being tested is not known to the t ‘ster. These tests can be functional or non-functional, though usually functional, BLACK BOX TESTING Fig. 1.8 Black Box Testing 30 ‘Scanned with CamScannerAdvantages of Black Box Testing: 1 2, yee Black-box testing is efficient when used on large systems. The tester and developer in black-box testing are independent of each other so testi balanced and unprejudiced. Tester can be non-technical. There is no need for the tester to have detailed functional knowledge of system. Tests will be done from an end users point of view, hecause the end user should accept the system Disadvantages of Black Box Testing: In black-box testing cases in black-box testing are challenging to design without having clear functional specifications. It is difficult to identify tricky inputs if the test cases are not developed based on specifications. It is difficult to identify all possible inputs in limited testing time. Asa result, writing test cases may be slow and difficult. ‘There are chances of having unidentified paths during the testing process. There is a high probability of repeating tests already performed by the programmer. 1.7.1 Requirement Based Testing The requirements-based testing (RBT)§pROCESS /HUAESSES||WO aOR ESSE) ‘first, validating that the requirements are correct, complete, unambiguous, and logically consistent; and second, designing al necessary aiid” Sufficient (from a black box perspective) set of test cases from those requirements to ensure that the design and code Fully nHWEH HOSE TeGUIFEMENIS. In designing tests two issues need to be overcome: reducing the immensely large number of potential tests down a reasonable size set and ensuring that the tests got the right answer for the right reason. The RBT process does not assume, going in, that we will see good Requirements Specifications. That is very rarely the case, The RBT process will drive out ambiguity and drive down the level of detail. The overall RBT strategy is to integrate testing throughout the development life cycle and focus on the quality of the Requirements Specification, This leads to early defect detection which has been shown to be much less expensive than finding defects during integration testing or later. The RBT process also has a focus on defect prevention, not just defect detection. To put the RBT process into perspective, testing can be divided into the following eight activities: 1. Define Test Completion Criteria. The test effort has specific, quantitative and qualitative goals. Testing is completed only when the goals have been reached (e.g., testing is complete when all functional variations, fully sensitized for the detection of defects, and 100% of all statements and branch vectors have executed successfully in single run or set of runs with no code changes in between). Design Test Cases. Logical test cases are defined by five characteristics: the initial state of the system prior to executing the test, the data in the data base, the inputs, the expected outputs, and the final system state. 31 ‘Scanned with CamScanner3. Build Test Cases. ‘There are two parts needed to build test cases from logical test cases: creating the necessary data, and building the components to support testing (e.g., build the navigation to get to the portion of the program being tested), 4. Execute Tests. Execute the test-case steps against the system being tested and document the results. Verify Test Results. Verify that the test results are as expected. 6. Verify Test Coverage. Track the amount of functional coverage and code coverage achieved by the successful execution of the set of tests, Manage and Track Defects. Any defects detected during the testing process are tracked to resolution. Statistics are maintained concerning the overall defect trends and status. Manage the Test Library. ‘The test manager maintains the relationships between the test cases and the programs being tested. The test manager keeps track of what tests have or have not been executed, and whether the executed tests have passed or failed. 1.7.2. Boundary Value Analysi Boundary value analysis is a tcSt\Gas@/deSi@A{tCchiniqUe to test boundary value between partitions (both valid boundary. partion and invalid boundary partition). A. BOUALAFYVAIUENIS an input or output value on the border of an equivalence partition, includes minimum and maximum values at inside and outside boundaries. Normally Boundary value analysis is part of stress and negative testing. Using Boundary Value Analysis technique tester creates test cases for required input field. For example; an Address text box which allows maximum 500 characters. So, writing test cases for each character once will be very difficult so that will choose boundary value analysis. Example for Boundary Value Analysis: Example 1 ‘Suppose you have very important tool at office, accepts valid User Name and Password field to work on that tool, and accepts minimum 8 characters and maximum 12 characters. Valid range 8-12, Invalid range 7 or less than 7 and Invalid range 13 or more than 13. Invalid Partition Invalid Partition Valid Partition More than 12 Less thans 8-12 Write Test Cases for Valid partition value, Invalid partition value and exact boundary value. ‘© Test Cases I: Consider password length less than 8 32 ‘Scanned with CamScanner‘© Test Cases 2: Consider password of length exactly 8. ‘+ Test Cases 3: Consider password of length between 9 and 11. Test Cases 4: Consider password of length exactly 12. ‘© Test Cases 5: Consider password of length more than 12. Example 2 Test cases for the application whose input box accepts numbers between 1- 1000. Valid range 1-1000, Invalid range 0 and Invalid range 1001 or more. Invalid Valid Invalid Partition Partition Partition ° 1-1000 31001 ormore Write Test Cases for Valid partition value, Invalid partition value and exact boundary value. ‘* Test Cases 1: Consider test data exactly as the input boundaries of input domain i.e. values 1 and 1000. ‘© Test Cases 2: Consider test data with values just below the extreme edges of input domains i.e. values 0 and 999. * Test Cases 3: Consider test data with values just above the extreme edges of input domain i.e, values 2 and 1001. 1.7.3 Equivalence Partitioning Tn this method, the input domain data is divided into different equivalence data classes. This method is typically used to f€diiGe[the| total numberof testeases toa finite) SCOT STABIE TESTES. still covering maximum requirements In shor, itis the pFOCGSs OF taking) all possible test cases and placing them into classes. One test value is picked from each class while testing. For example, if you are testing for an input box accepting numbers from 1 to 1000 then there is:no tise in Writing thousands of test cases for all 1000 valid input numbers plus other test eases for invalid data, 1g the Equivalence Partitioning method above, (S{Gas@STean|BETUHVIGEd into three sets of input data called classes. Each test case is a representative of the respective class: So in the above example, we can divide our test cases into three equivalence classes of some valid and invalid inputs, 33, ‘Scanned with CamScanner