BCA123 CU-BCA-SEM-II-Software Engineering-26.10.2020-converted

Path 3: 1-2-3-6-8-9-10-1-11 Path 4: 1-2-3-6-7-9-10-1-11 BLACK BOX TESTING Black-box testing or behavioral testing, mainly focuses on the functional requirements of the software. It enables the software engineer to develop a set of inputs that can fully involve all the functional requirements for a program. It is not an alternative approach to white-box testing. Rather, it completes the testing by uncovering different types of errors than the white-box approach Fig 10.7 Black box testing This approach attempts to find errors in the following categories: 1. Incorrect or missing functions, 2. Interface related errors, 3. Errors in data structures or database accesses, 4. Performance related errors and 5. Initialization and termination errors. Black box testing is a software testing techniques in which functionality of the software under test (SUT) is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software. Black-box Testing Techniques Black-box testing, also called behavioral testing, focuses on the functional requirements of the software. That is, black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Black-box 199 CU IDOL SELF LEARNING MATERIAL (SLM)

testing is not an alternative to white-box techniques. Rather, it is a complementary approach that is likely to uncover a different class of errors than white-box methods. Unlike white-box testing, which is performed early in the testing process, black box testing tends to be applied during later stages of testing. Because black-box testing purposely disregards control structure, attention is focused on the information domain. Tests are designed to answer the following questions: • How is functional validity tested? • How is system behavior and performance tested? • What classes of input will make good test cases? • Is the system particularly sensitive to certain input values? • How are the boundaries of a data class isolated? What data rates and data volume can the system tolerate? • What effect will specific combinations of data have on system operation? There are various techniques in developing test cases for black box testing. I will be explaining two of the most common techniques, Equivalence Partitioning and BVA (Boundary Value Analysis). Equivalence Partitioning -Equivalence partitioning is a black-box testing method that divides the input domain of a program into classes of data from which test cases can be derived. Test case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition. An equivalence class represents a set of valid or invalid states for input conditions. Typically, an input condition is either a specific numeric value, a range of values, a set of related values, or a boolean condition. Equivalence classes may be defined according to the following guidelines: 1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined. 200 CU IDOL SELF LEARNING MATERIAL (SLM)

2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined. 3. If an input condition specifies a member of a set, one valid and one invalid equivalence class are defined. 4. If an input condition is boolean, one valid and one invalid class are defined Boundary Value Analysis- BVA extends equivalence partitioning by focusing on data at the “edges” of an equivalence class. For reasons that are not completely clear, a greater number of errors tends to occur at the boundaries of the input domain rather than in the “center”. It is for this reason that boundary value analysis (BVA) has been developed as a testing technique. Boundary value analysis leads to a selection of test cases that exercise bounding values. Boundary value analysis is a test case design technique that complements equivalence partitioning. Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the “edges” of the class. Rather than focusing solely on input conditions, BVA derives test cases from the output domain as well. Guidelines for BVA are similar in many respects to those provided for equivalence partitioning: 1. If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b and values just above and just below a and b. 2. If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested. 3. Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature vs. pressure table is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries. 4. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary. Most software engineers intuitively perform BVA to some degree. By applying 201 CU IDOL SELF LEARNING MATERIAL (SLM)

these guidelines, boundary testing will be more complete, thereby having a higher likelihood for error detection. It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. More application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in center of input domain Advantages of Black-box Testing 1. Tester can be non-technical. 2. Used to verify contradictions in actual system and the specifications. 3. Test cases can be designed as soon as the functional specifications are complete Disadvantages of Black-box Testing 1. The test inputs needs to be from large sample space. 2. It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult. 3. Chances of having unidentified paths during this testing Table 10.1 Tabular comparison of BBT vs WBT BBT WBT Used to test software without knowing the Performed after knowing the internal internal structure of the software structure of the software Carried out by testers Performed by developers Does not require programming knowledge Requires programming knowledge 202 CU IDOL SELF LEARNING MATERIAL (SLM)

Requires implementation knowledge Does not require implementation knowledge Higher level testing Lower level testing Consumes less time Consumes a lot of time Done in the trial and error method Data domains and boundaries can be tested Types of black box testing Types of white box testing 1. Functional testing 1. Path testing 2. Regression testing 2. Loop testing 3. Non-functional testing 3. Condition testing Not suitable for algorithm testing Suitable for algorithm testing SUMMARY • Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. • White-box testing or glass-box testing is a test case design method that uses the control structure of the procedural design to obtain test cases. • Using this methodology, a software engineer can come up with test cases that guarantee that all independent paths within a module have been exercised at least once; exercise all the logical decisions based on their true and false sides; executing all loops at their boundaries and within them; and exercise internal data structures to 203 CU IDOL SELF LEARNING MATERIAL (SLM)

ensure their validity • Black box testing is a software testing techniques in which functionality of the Software • Under Test (SUT) is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software.  The strategy for fault based testing is to hypothesize a set of plausible faults and then derive tests to prove each hypothesis.  The objective of fault based testing within an object oriented system is to design tests that have a higher possibility of uncovering plausible errors. • A test case is a document, which has a set of test data, preconditions, expected results and post conditions, developed for a particular test scenario in order to verify compliance against a specific requirement. Test Case acts as the starting point for the test execution, and after applying a set of input values, the application has a definitive outcome and leaves the system at some end point or also known as execution post condition. • A test case is a document, which has a set of test data, preconditions, expected results and post conditions, developed for a particular test scenario in order to verify compliance against a specific requirement. Test Case acts as the starting point for the test execution, and after applying a set of input values, the application has a definitive outcome and leaves the system at some end point or also known as execution post condition. • Debugging, or fault localization is the process of (1) Locating the fault or defect, (2) Repairing the code, and (3) Retesting the code. Software testing is not debugging. • Testing and debugging, or fault localization, are two very different activities. The debugging process begins after testing has been carried out and the tester has noted that the software is not behaving as specified. • Testing: To determine if a code contains errors. 204 CU IDOL SELF LEARNING MATERIAL (SLM)

• Debugging: To locate the error and fix it • It is the process of checking whether expected functionality of a product is achieved. of quality with respect to selected attributes • The software development process has been described as a series of phases, procedures, and steps that result in the production of a software product. • Software testing involves the execution of a software component or system component to evaluate one or more properties of interest. In general, these properties indicate the extent to which the component or system under test: • meets the requirements that guided its design and development, • responds correctly to all kinds of inputs, • performs its functions within an acceptable time, • is sufficiently usable, • Can be installed and run in its intended environments, and • Achieves the general result its stakeholders’ desire. KEY WORDS/ABBREVIATIONS • Qualification, process performance. (FDA) establishing confidence that the process is effective and reproducible. • Rapid prototyping: a structured software requirements discovery technique which emphasizes generating prototypes early in the development process to permit early feedback and analysis in support of the development process. • Specification, design: a specification that documents how a system is to be built. It typically includes system or component structure, algorithms, control logic, data structures, data set [file] use information, input/output formats, interface descriptions, 205 CU IDOL SELF LEARNING MATERIAL (SLM)

etc. Contrast with design standards, requirement. See: software design description. • Test: an activity in which a system or component is executed under specified conditions, the results are observed or recorded and an evaluation is made of some aspect of the system or component. • Testability: the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. • BVA: Boundary Value Analysis • SUT: Software Under Test LEARNING ACTIVITY 1. Write test case for check an input field that can accept maximum of 10 characters. 2 Write test cases for student login, pass, fail. UNIT END QUESTIONS (MCQ AND DESCRIPTIVE) A. Descriptive Types Questions 1. Identify testing which involves testing from an external or end-user type perspective. 2. Explain difference between white box testing & black box testing. 3. Let us consider the following code snippet .write test cases for it. INPUT A & B 206 CU IDOL SELF LEARNING MATERIAL (SLM)

C =A +B IFC>100 PRINT “ITS DONE” 4. We have one program where the developers have given about 50,000 loops. Write test case for it. 5. Illustrate with an example the tester’s Role in a Software Development Organization. B. Multiple Choice Questions 1. Which of the following term describes testing? (a) Finding broken code (b) Evaluating deliverable to find errors (c) A stage of all projects (d) None of the mentioned 2. Lower and upper limits are present in which chart? (a) Run chart (b) Bar chart (c) Control chart (d) None of the mentioned 3. White Box techniques are also classified as (a) Design based testing (b) Structural testing (c) Error guessing technique (d) None of the mentioned 4. Exhaustive testing is (a) always possible (b) practically possible (c) impractical but possible 207 CU IDOL SELF LEARNING MATERIAL (SLM)

(d) impractical and impossible 5. What are the various Testing Levels? (a) Unit Testing (b) System Testing (c) Integration Testing (d) All of the mentioned Answers 1. (a), 2. (b), 3. (b), 4. (c), 5. (d) REFERENCES • Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications. • Mall R. (2003). Fundamentals of Software Engineering. New Delhi: PHI • Jalote P. (2019). An Integrated Approach to Software Engineering. New Delhi: Narosa Publications. • Summerville I. (2013). Software Engineering. New Delhi: Pearson Education. • Software Engineering, Sixth Edition, 20~1, Ian Sommerville; Pearson Education. • Machado, P.; Vincenzi, A.; Maldonado, J.C. (2010). \"Chapter 1: Software Testing: An Overview\". In Borba, P.; Cavalcanti, A.; Sampaio, A. • Machado, P.; Vincenzi, A.; Maldonado, J.C. (2010). \"Chapter 1: Software Testing: An Overview\". In Borba, P.; Cavalcanti, A.; Sampaio, A. • Rajib Mall, Fundamentals of Software Engineering, Second Edition, PHI. Richard Fairpy, Software Engineering Concepts, Tata McGraw Hill, 1997. • Higher education. Sommerville, Software Engineering, Sixth edition, Pearson Education. 208 CU IDOL SELF LEARNING MATERIAL (SLM)

• http://en.wikipedia.org/wiki/White-box_testing http://en.wikipedia.org/wiki/Black- box_testing • Woodcook, J. (eds.). Testing Techniques in Software Engineering. Springer Science & Business Media. pp. 13–14. • Clapp, J.A.; Stanten, S.F.; Peng, W.W.; et al. (1995). Software Quality Control • Software Testing Techniques and Strategies Sawant A. A.Bari P. H. Chawan P.Journal of Engineering Research & Applications (2012) 209 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 11 TESTING STRATEGIES Structure Learning Objectives Introduction Verification and validation Unit testing Integration testing Validation testing System testing Summary Key Words/Abbreviations Learning Activity Unit End Questions (MCQ and Descriptive) References LEARNING OBJECTIVES After studying this unit, you will be able to: • State the basic concepts of testing. • Explain Verification and validation. • Explain Unit test, integration testing, validation testing, system testing. INTRODUCTION 210 CU IDOL SELF LEARNING MATERIAL (SLM)

Software Testing Definition according to ANSI/IEEE 1059 standard – A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item. In the IT industry, large companies have a team with responsibilities to evaluate the developed software in context of the given requirements. Moreover, developers also conduct testing which is called Unit Testing. In most cases, the following professionals are involved in testing a system within their respective capacities − • Software Tester • Software Developer • Project Lead/Manager • End User Different companies have different designations for people who test the software on the basis of their experience and knowledge such as Software Tester, Software Quality Assurance Engineer, QA Analyst, etc. Applications of Software Testing • Cost Effective Development - Early testing saves both time and cost in many aspects, however reducing the cost without testing may result in improper design of a software application rendering the product useless. • Product Improvement - During the SDLC phases, testing is never a time-consuming process. However diagnosing and fixing the errors identified during proper testing is a time-consuming but productive activity. • Test Automation - Test Automation reduces the testing time, but it is not possible to start test automation at any time during software development. Test automaton should be started when the software has been manually tested and is stable to some extent. Moreover, test automation can never be used if requirements keep changing. • Quality Check - Software testing helps in determining following set of properties of 211 CU IDOL SELF LEARNING MATERIAL (SLM)

any software such as • Functionality • Reliability • Usability • Efficiency • Maintainability • Portability VERIFICATION AND VALIDATION Are we building the product right? Validation: Are we building the right product? Verification: Verification is the process of checking that a software achieves its goal without any bugs. It is the process to ensure whether the product that is developed is right or not. It verifies whether the developed product fulfills the requirements that we have. Verification is Static Testing. • Activities involved in verification: • Inspections • Reviews • Walkthroughs • Desk-checking Validation: Validation is the process of checking whether the software product is up to the mark or in other words product has high level requirements. It is the process of checking the validation 212 CU IDOL SELF LEARNING MATERIAL (SLM)

of product i.e. it checks what we are developing is the right product. It is validation of actual and expected product. Validation is the Dynamic Testing. Activities involved in validation: • Black box testing • White box testing • Unit testing • Integration testing Fig 11.1 Validation 213 Note: Verification is followed by Validation. Activities involved in validation: • Black box testing • White box testing • Unit testing • Integration testing Note: Verification is followed by Validation. CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 11.2 Verification is followed by Validation. Table 11.1. Verification vs. Validation: Key Difference Verification Validation The verifying process includes checking It is a dynamic mechanism of testing documents, design, code, and program and validating the actual product It does not involve executing the code It always involves executing the code Verification uses methods like reviews, It uses methods like Black Box walkthroughs, inspections, and desk- checking Testing, White Box Testing, and non- etc. functional testing Whether the software conforms to specification is It checks whether the software meets checked the requirements and expectations of a customer It finds bugs early in the development cycle It can find bugs that the verification process cannot catch 214 CU IDOL SELF LEARNING MATERIAL (SLM)

Target is application and software architecture, Target is an actual product specification, complete design, high level, and database design etc. QA team does verification and make sure that the With the involvement of testing team software is as per the requirement in the SRS validation is executed on software document. code. It comes before validation It comes after verification UNIT TESTING Unit Testing-also known as component testing, is a level of software testing where individual units / components of software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output. In procedural programming, a unit may be an individual program, function, procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong to a base/ super class, abstract class or derived / child class. (Some treat a module of an application as a unit. This is to be discouraged as there will probably be many individual units within that module.) Unit testing frameworks, drivers, stubs, and mock/ fake objects are used to assist in unit testing. Method It is performed by using the White Box Testing method and is normally automated. Tasks Unit Test Plan [Prepare >> Review >> Rework >> Baseline] Unit Test Cases/ Test Scripts/ Test Data [Prepare >> Review >> Rework >> Baseline] Unit Test [Execute >> Re-execute] 215 CU IDOL SELF LEARNING MATERIAL (SLM)

When is it performed? Unit Testing is the first level of software testing and is performed prior to Integration Testing. Who performs it? It is normally performed by software developers themselves or their peers. In rare cases, it may also be performed by independent software testers. Benefits Unit testing increases confidence in changing/ maintaining code. If good unit tests are written and if they are run every time any code is changed, we will be able to promptly catch any defects introduced due to the change. Also, if codes are already made less interdependent to make unit testing possible, the unintended impact of changes to any code is less. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) But, if you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is in production. Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes 216 CU IDOL SELF LEARNING MATERIAL (SLM)

made over the span of several days/weeks/months need to be scanned INTEGRATION TESTING Integration testing is the process of testing the interface between two software units or module. It’s focus on determining the correctness of the interface. The purpose of the integration testing is to expose faults in the interaction between integrated units. Once all the modules have been unit tested, integration testing is performed. Integration testing is the second level of the software testing process comes after unit testing. In this testing, units or individual components of the software are tested in a group. The focus of the integration testing level is to expose defects at the time of interaction between integrated components or units. Unit uses modules for testing purpose, and these modules are combined and tested in integration testing. The Software is developed with a number of software modules that are coded by different coders or programmers. The goal of integration testing is to check the correctness of communication among all the modules. Fig 11.3 Under unit testing Integration test approaches –There are four types of integration testing approaches. Those 217 CU IDOL SELF LEARNING MATERIAL (SLM)

approaches are the following: 1. Big-Bang Integration Testing –It is the simplest integration testing approach, where all the modules are combining and verifying the functionality after the completion of individual module testing. In simple words, all the modules of the system are simply put together and tested. This approach is practicable only for very small systems. If once an error is found during the integration testing, it is very difficult to localize the error as the error may potentially belong to any of the modules being integrated. So, debugging errors reported during big bang integration testing are very expensive to fix. Fig 11.4 Bing bang integration testing Let us see examples for our better understanding of the non-incremental integrating testing or big bang method: Example1 218 CU IDOL SELF LEARNING MATERIAL (SLM)

In the below example, the development team develops the application and sends it to the CEO of the testing team. Then the CEO will log in to the application and generate the username and password and send a mail to the manager. After that, the CEO will tell them to start testing the application. Then the manager manages the username and the password and produces a username and password and sends it to the test leads. And the test leads will send it to the test engineers for further testing purposes. This order from the CEO to the test engineer is top-down incremental integrating testing. In the same way, when the test engineers are done with testing, they send a report to the test leads, who then submit a report to the manager, and the manager will send a report to the CEO. This process is known as Bottom-up incremental integration testing as we can see in the below image: Fig 11.5 Example Once all the components or modules are working independently, then we need to check the data flow between the dependent modules is known as integration testing. 219 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 11.6 Illustrate example First, we will login as a user P to amount transfer and send Rs200 amount, the confirmation message should be displayed on the screen as amount transfer successfully. Now logout as P and login as user Q and go to amount balance page and check for a balance in that account = Present balance + Received Balance. Therefore, the integration test is successful. Also, we check if the amount of balance has reduced by Rs200 in P user account. Click on the transaction, in P and Q, the message should be displayed regarding the data and time of the amount transfer. • Although all modules of software application already tested in unit testing, errors still exist due to the following reasons: • Each module is designed by individual software developer whose programming logic may differ from developers of other modules so; integration testing becomes essential to determine the working of software modules. • To check the interaction of software modules with the database whether it is an 220 CU IDOL SELF LEARNING MATERIAL (SLM)

erroneous or not. • Requirements can be changed or enhanced at the time of module development. These new requirements may not be tested at the level of unit testing hence integration testing becomes mandatory. • Incompatibility between modules of software could create errors. • To test hardware's compatibility with software. • If exception handling is inadequate between modules, it can create bugs. Advantages: • It is convenient for small systems. Disadvantages: • There will be quite a lot of delay because you would have to wait for all the modules to be integrated. • High risk critical modules are not isolated and tested on priority since all modules are tested at once. Types of Integration Testing Integration testing can be classified into two parts: • Incremental integration testing • Non-incremental integration testing 221 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 11.7 Types of Integration testing 2. Bottom-Up Integration Testing –In bottom-up testing, each module at lower levels is tested with higher modules until all modules are tested. The primary purpose of this integration testing is, each subsystem is to test the interfaces among various modules making up the subsystem. This integration testing uses test drivers to drive and pass appropriate data to the lower level modules. Advantages: • In bottom-up testing, no stubs are required. • A principle advantage of this integration testing is that several disjoint subsystems can be tested simultaneously. Disadvantages: • Driver modules must be produced. • In this testing, the complexity that occurs when the system is made up of a large number of small subsystem. 3. Top-Down Integration Testing –Top-down integration testing technique used in order to simulate the behavior of the lower-level modules that are not yet integrated. In this 222 CU IDOL SELF LEARNING MATERIAL (SLM)

integration testing, testing takes place from top to bottom. First high-level modules are tested and then low-level modules and finally integrating the low-level modules to a high level to ensure the system is working as intended. Advantages: • Separately debugged module. • Few or no drivers needed. • It is more stable and accurate at the aggregate level. Disadvantages: • Needs many Stubs. • Modules at lower level are tested inadequately. 4. Mixed Integration Testing –A mixed integration testing is also called sandwiched integration testing. A mixed integration testing follows a combination of top down and bottom-up testing approaches. In top-down approach, testing can start only after the top- level module has been coded and unit tested. In bottom-up approach, testing can start only after the bottom level modules are ready. This sandwich or mixed approach overcomes this shortcoming of the top-down and bottom-up approaches. A mixed integration testing is also called sandwiched integration testing. Advantages: • Mixed approach is useful for very large projects having several sub projects. • This Sandwich approach overcomes this shortcoming of the top-down and bottom-up approaches. Disadvantages: • For mixed integration testing, require very high cost because one part has Top-down approach while another part has bottom-up approach. 223 CU IDOL SELF LEARNING MATERIAL (SLM)

• This integration testing cannot be used for smaller system with huge interdependence between different modules. VALIDATION TESTING The process of evaluating software during the development process or at the end of the development process to determine whether it satisfies specified business requirements. Validation Testing ensures that the product actually meets the client's needs. It can also be defined as to demonstrate that the product fulfills its intended use when deployed on appropriate environment. It answers to the question, Are we building the right product? Validation Testing - Workflow: Validation testing can be best demonstrated using V-Model. The Software/product under test is evaluated during this type of testing. Activities: • Unit Testing • Integration Testing • System Testing • User Acceptance Testing SYSTEM TESTING System Testing (ST) is a black box testing technique performed to evaluate the complete system the system's compliance against specified requirements. In System testing, the functionalities of the system are tested from an end-to-end perspective. System Testing is usually carried out by a team that is independent of the development team in order to measure the quality of the system unbiased. It includes both functional and Non- 224 CU IDOL SELF LEARNING MATERIAL (SLM)

Functional testing. Types of System Tests: Fig 11.8 System Test System under test (SUT) refers to a system that is being validated by the testers. The terminology is also known as application under test. The System under Test (SUT) also corresponds to software that is matured and has gone through unit and integration testing. SUMMARY Software Testing has different goals and objectives. The major objectives of Software testing are as follows: • Finding defects which may get created by the programmer while developing the software. • Gaining confidence in and providing information about the level of quality. • To prevent defects. • To make sure that the end result meets the business and user requirements. 225 CU IDOL SELF LEARNING MATERIAL (SLM)

• To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is System Requirement Specifications. • To gain the confidence of the customers by providing them a quality product. • Black Box Testing is a software testing method in which the functionalities of software applications are tested without having knowledge of internal code structure, implementation details and internal paths. Black Box Testing mainly focuses on input and output of software applications and it is entirely based on software requirements and specifications. It is also known as Behavioral Testing. • Condition testing is a test cased design method, which ensures that the logical condition and decision statements are free from errors. The errors present in logical conditions can be incorrect Boolean operators, missing parenthesis in a Booleans expression, error in relational operators, arithmetic expressions, and so on. • Unit Testing: It is often the first type of testing done on an application. Unit Testing is performed on each unit or block of code as it is developed. Unit Testing is essentially done by the programmer. As a software developer, you develop a few lines of code, a single function or an object and test it to make sure it works before continuing Unit Testing helps identify a majority of bugs, early in the software development lifecycle. Bugs identified in this stage are cheaper and easy to fix. • White Box Testing is software testing technique in which internal structure, design and coding of software are tested to verify flow of input-output and to improve design, usability and security. In white box testing, code is visible to testers so it is also called Clear box testing, Open box testing, Transparent box testing, Code-based testing and Glass box testing. It is one of two parts of the Box Testing approach to software testing. Its counterpart, Blackbox testing, involves testing from an external or end-user type perspective. On the other hand, Whitebox testing is based on the inner workings of an application and revolves around internal testing. The term \"Whitebox\" was used because of the see-through box concept. The clear box or Whitebox name symbolizes the ability to see through the software's outer shell (or 226 CU IDOL SELF LEARNING MATERIAL (SLM)

\"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. • In Black Box, testing is done without the knowledge of the internal structure of program or application whereas in White Box, testing is done with knowledge of the internal structure of program. • Black Box test doesn’t require programming knowledge whereas the White Box test requires programming knowledge. • Black Box testing has the main goal to test the behavior of the software whereas White Box testing has the main goal to test the internal operation of the system. • Black Box testing is focused on external or end-user perspective whereas White Box testing is focused on code structure, conditions, paths and branches. • Black Box test provides low granularity reports whereas the White Box test provides high granularity reports. • Black Box testing is a not time-consuming process whereas White Box testing is a time-consuming process. • Verification process includes checking of documents, design, code and program whereas Validation process includes testing and validation of the actual product. • Verification does not involve code execution while Validation involves code execution. • Verification uses methods like reviews, walkthroughs, inspections and desk-checking whereas Validation uses methods like black box testing, white box testing and non- functional testing. • Verification checks whether the software confirms a specification whereas Validation checks whether the software meets the requirements and expectations. 227 CU IDOL SELF LEARNING MATERIAL (SLM)

• Verification finds the bugs early in the development cycle whereas Validation finds the bugs that verification cannot catch. • Verification process targets on software architecture, design, database, etc. while Validation process targets the actual software product. • Verification is done by the QA team while Validation is done by the involvement of testing team with QA team. • Verification process comes before validation whereas Validation process comes after verification. KEY WORDS/ABBREVIATIONS • Test case: (IEEE) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item. Syn: test case specification • Test case generator: (IEEE) A software tool that accepts as input source code, test criteria, specifications, or data structure definitions; uses these inputs to generate test input data; and, sometimes, determines expected results. Syn: test data generator, test generator. • Test design: (IEEE) Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests. See: testing functional; cause effect graphing; boundary value analysis; equivalence class partitioning; error guessing; testing, structural; branch analysis; path analysis; statement coverage; condition coverage; decision coverage; multiple- condition coverage • Test documentation: (IEEE) Documentation describing plans for, or results of, the testing of a system or component, Types include test case specification, test incident report, test log, test plan, test procedure, test report. • Test driver: (IEEE) A software module used to invoke a module under test and, often, provide test inputs, control and monitor execution, and report test results. 228 CU IDOL SELF LEARNING MATERIAL (SLM)

LEARNING ACTIVITY 1. Creating and executing tests for all possible paths results in 100% statement coverage and 100% branch coverage. 2. Write difference between white box and black box testing. UNIT END QUESTIONS (MCQ AND DESCRIPTIVE) A. Descriptive Types Questions 1. Identify the first level of software testing performed prior to Integration Testing? Explain it with its benefits. 2. Identify with its types of testing performed to evaluate the complete system the system's compliance against specified requirement? 3. Identify the testing where all the modules of the system are simply put together and tested? Explain with its diagram and example 4. Given below is a java statement code in the correct and incorrect code. Write test cases that bring out the mistakes of the code: 229 CU IDOL SELF LEARNING MATERIAL (SLM)

5. Identify the process of checking whether the software product is up to the mark? Explain it with activities involved in it. 230 CU IDOL SELF LEARNING MATERIAL (SLM)

B. Multiple Choice Questions 231 1. Which of the following term describes testing? (a) Finding broken code (b) Evaluating deliverable to find errors (c) A stage of all projects (d) None of the mentioned 2. Which of the following is/are White box technique? (a) Statement Testing (b) Decision Testing (c) Condition Coverage (d) All of the mentioned 3. Alpha testing is done at (a) Developer’s end (b) User’s end (c) Developer’s & User’s end (d) None of the mentioned 4. The testing in which code is checked (a) Black box testing (b) White box testing (c) Red box testing (d) Green box testing 5. Testing done without planning and Documentation is called (a) Unit testing (b) Regression testing (c) Adhoc testing (d) None of the mentioned Answers CU IDOL SELF LEARNING MATERIAL (SLM)

1. (b), 2. (d), 3. (a), 4. (b), 5. (c) REFERENCES • Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications. • Mall R. (2003). Fundamentals of Software Engineering. New Delhi: PHI • Jalote P. (2019). An Integrated Approach to Software Engineering. New Delhi: Narosa Publications. • Summerville I. (2013). Software Engineering. New Delhi: Pearson Education. • Software Engineering, Sixth Edition, 20~1, Ian Sommerville; Pearson Education. • Lessons Learned in Software Testing: A Context-Driven Approach (Paperback) by Cem Kaner • Wiley Publishing Kassem. A. (2009), Software Engineering. USA, J. Ross Publishing • Srinivasan D & Gopala swamy R (2006), Software Testing: Principles and Practice USA, Dorling Kindersley. • http://www.testinggeek.com/index.php/testing-types/system-knowledge/50- whitebox-testing • http://www.buzzle.com/editorials/4-10-2005-68350.asp • https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/white-box/259-BSI • .html http://puneetkalra.sulekha.com/blog/post/2007/08/dynamic-white-box-testing. • http://www.informatica.uniroma2.it/upload/2007/LSS/03%20- • %20blackBoxwhiteBox--%20static%20white%20box%20testing.pdf 232 CU IDOL SELF LEARNING MATERIAL (SLM)

• http://www.astqb.org/educational-resources/syllabi-static3.php • http://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx • http://www.securityninja.co.uk/application-security/a-checklist-approach-to- securitycode-reviews-part-2 • http://www.mindfiresolutions.com/Code-Review-Checklist-238.php • How Google Tests Software (Paperback)by James A. Whittaker • The Art of Software Testing (Hardcover)by Glenford J. Myers • Software testing: The generation tools Rajamanickam L.Saat N. A. B. M.Daud S. N. B. • Comprehensive study of software testing: Categories, levels, techniques, and types Umar M. A. • Ron P (2006), Software Testing-Second Edition, USA, SAMS Publishing. 233 CU IDOL SELF LEARNING MATERIAL (SLM)