Test Strategy

Test Strategy

1.0 Introduction This document details the way a testing strategy has to be prepared suggesting the various levels of testing, types of testing and testing methodologies / techniques.{mosgoogle} 1.1 What is a Test Strategy? A Test Strategy document details the way testing is going to be carried out in the project. In other words, it describes the scope and general direction for testing in the project. A Test Strategy must answer the following questions: 1. What kind of testing will occur? 2. What are the risks? 3. What are the critical success factors? 4. What are the testing objectives? 5. What are the trade–offs? 2.0 Definitions and Acronyms Acronym Definition Test Stubs A stub is a dummy procedure, module, or unit that stands in for an unfinished portion of a system. (Stubs stand-in for finished sub routines or sub-systems and often consists of nothing more than a function header with no body. If a stub needs to return values for testing purposes, it may read and return test data from a file, return hard-coded values, or obtain data from a user (the tester) and return it.) Test Drivers / Harness A test driver is software which executes software in order to test it, providing a framework for setting input parameters, executing the unit, and reading the output parameters 3.0 Choosing the right Test Strategy It is very important to decide and define upfront the testing techniques to be followed in the project in order to have a clear goal / objective for testing. Following sections describe the various levels of testing that could be performed and the testing techniques that could be chosen for functional testing {mosgoogle} The various levels of testing have been described below. The strategies for Unit, Integration and System would have been explained in detail and a brief overview of the other types of testing has been given below Each level of testing described here is considered as Black – Box or White Box testing Black – Box Testing: Testing done not based on any knowledge of internal design or code. Tests are based on requirements and functionality White – Box Testing: Testing based on the knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths and conditions 4.0 Types of Testing 4.1 Unit Testing and Strategies The Unit Test is the lowest level of testing performed during software development, where individual units of software are tested in isolation from other parts of the program Unit level testing is not just intended for one-off development use, to aid bug free coding. Unit Tests have to be modified whenever software is modified or used in a new environment. Some of the popular misconceptions about Unit Testing: It consumes too much time I‘ am too good a programmer to write unit tests Integration tests will catch all the bugs anyway It is not cost effective Remember that unit testing alone is about testing units and integration testing is about testing the interaction between tested units When developing a strategy for unit testing, there are three basic approaches that can be taken. They are top down testing, bottom up testing and isolationtesting. 4.1.1 Top – Down Testing In top down unit testing, individual units are tested by using them from the units that call them, but in isolation from the units called. The unit at the top of a hierarchy is tested first, with all called units replaced by stubs. Testing continues by replacing the stubs with the actual called units, with lower level units being stubbed. This process is repeated until the lowest level units have been tested. Top down testing requires test stubs, but not test drivers. Figure 1.0 illustrates the test stubs and tested units needed to test unit D, assuming that units A, B and C have already been tested in a top down approach. A unit test plan for the program shown in figure 1.0, using a strategy based on the top down organizational approach, could read as follows: Step (1) Test unit A, using stubs for units B, C and D. Step (2) Test unit B, by calling it from tested unit A, using stubs for units C and D. Step (3) Test unit C, by calling it from tested unit A, using tested units B and a stub for unit D. Step (4) Test unit D, by calling it from tested unit A, using tested unit B and C, and stubs for units E, F and G. (Shown in figure 1.0). Step (5) Test unit E, by calling it from tested unit D, which is called from tested unit A, using tested units B and C, and stubs for units F, G, H, I and J. Step (6) Test unit F, by calling it from tested unit D, which is called from tested unit A, using tested units B, C and E, and stubs for units G, H, I and J. Step (7) Test unit G, by calling it from tested unit D, which is called from tested unit A, using tested units B, C, E and F, and stubs for units H, I and J. Step (8) Test unit H, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F and G, and stubs for units I and J. Step (9) Test unit I, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G and H, and a stub for units J. Step (10) Test unit J, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G, H and I. Figure 1.0 - Top Down Testing Tested Under Test Tested Tested B C D Stub Stub Stub E F G H I J 4.1.1.1. Advantages Top down unit testing provides an early integration of units before the software integration phase. In fact, top down unit testing is really a combined unit test and software integration strategy. The detailed design of units is top down, and top down unit testing implements tests in the sequence units are designed, so development time can be shortened by overlapping unit testing with the detailed design and code phases of the software lifecycle. In a conventionally structured design, where units at the top of the hierarchy provide high level functions, with units at the bottom of the hierarchy implementing details, top down unit testing will provide an early integration of 'visible' functionality. This gives a very requirements oriented approach to unit testing. Redundant functionality in lower level units will be identified by top down unit testing, because there will be no route to test it. (However, there can be some difficulty in distinguishing between redundant functionality and untested functionality). 4.1.1.2. Disadvantages Top down unit testing is controlled by stubs, with test cases often spread across many stubs. With each unit tested, testing becomes more complicated, and consequently more expensive to develop and maintain. As testing progresses down the unit hierarchy, it also becomes more difficult to achieve the good structural coverage which is essential for high integrity and safety critical applications, and which is required by many standards. Difficulty in achieving structural coverage can also lead to a confusion between genuinely redundant functionality and untested functionality. Testing some low level functionality, especially error handling code, can be totally impractical. Changes to a unit often impact the testing of sibling units and units below it in the hierarchy. For example, consider a change to unit D. Obviously, the unit test for unit D would have to change and be repeated. In addition, unit tests for units E, F, G, H, I and J, which use the tested unit D, would also have to be repeated. These tests may also have to change themselves, as a consequence of the change to unit D, even though units E, F, G, H, I and J had not actually changed. This leads to a high cost associated with retesting when changes are made, and a high maintenance and overall lifecycle cost. The design of test cases for top down unit testing requires structural knowledge of when the unit under test calls other units. The sequence in which units can be tested is constrained by the hierarchy of units, with lower units having to wait for higher units to be tested, forcing a 'long and thin' unit test phase. (However, this can overlap substantially with the detailed design and code phases of the software lifecycle). The relationships between units in the example program in figure 1.0 is much simpler than would be encountered in a real program, where units could be referenced from more than one other unit in the hierarchy. All of the disadvantages of a top down approach to unit testing are compounded by a unit being referenced from more than one other unit. 4.1.1.3. Overall A top down strategy will cost more than an isolation-based strategy, due to complexity of testing units below the top of the unit hierarchy, and the high impact of changes. The top down organizational approach is not a good choice for unit testing. However, a top down approach to the integration of units, where the units have already been tested in isolation, can be viable 4.1.2 Bottom – Up Testing In bottom up unit testing, units are tested in isolation from the units that call them, but using the actual units called as part of the test. The lowest level units are tested first, and then used to facilitate the testing of higher-level units. Other units are then tested, using previously tested called units. The process is repeated until the unit at the top of the hierarchy has been tested. Bottom up testing requires test drivers, but does not require test stubs. Figure 1.1 illustrates the test driver and tested units needed to test unit D, assuming that units E, F, G, H, I and J have already been tested in a bottom up approach. A unit test plan for the program shown in figure 3.1, using a strategy based on the bottom up organizational approach, could read as follows: Step (1) (Note that the sequence of tests within this step is unimportant, all tests within step 1 could be executed in parallel.) Test unit H, using a driver to call it in place of unit E; Test unit I, using a driver to call it in place of unit E; Test unit J, using a driver to call it in place of unit E; Test unit F, using a driver to call it in place of unit D; Test unit G, using a driver to call it in place of unit D; Test unit B, using a driver to call it in place of unit A; Test unit C, using a driver to call it in place of unit A. Step (2) Test unit E, using a driver to call it in place of unit D and tested units H, I and J. Step (3) Test unit D, using a driver to call it in place of unit A and tested units E, F, G, H, I and J. Step (4) Test unit A, using tested units B, C, D, E, F, G, H, I and J. Figure 1.1 - Bottom Up Testing A Under Test B C D Tested Tested Tested E F G Tested Tested Tested H I J 4.1.2.1. Advantages Like top down unit testing, bottom up unit testing provides an early integration of units before the software integration phase. Bottom up unit testing is also really a combined unit test and software integration strategy. All test cases are controlled solely by the test driver, with no stubs required. This can make unit tests near the bottom of the unit hierarchy relatively simple. (However, higher-level unit tests can be very complicated). Test cases for bottom up testing may be designed solely from functional design information, requiring no structural design information (although structural design information may be useful in achieving full coverage). This makes the bottom up approach to unit testing useful when the detailed design documentation lacks structural detail. Bottom up unit testing provides an early integration of low-level functionality, with higher-level functionality being added in layers as unit testing progresses up the unit hierarchy. This makes bottom up unit testing readily compatible with the testing of objects. 4.1.2.2. Disadvantages As testing progresses up the unit hierarchy, bottom up unit testing becomes more complicated, and consequently more expensive to develop and maintain. As testing progresses up the unit hierarchy, it also becomes more difficult to achieve good structural coverage. Changes to a unit often impact the testing of units above it in the hierarchy. For example, consider a change to unit H. Obviously, the unit test for unit H would have to change and be repeated. In addition, unit tests for units A, D and E, which uses the tested unit H, would also have to be repeated. These tests may also have to change themselves, as a consequence of the change to unit H, even though units A, D and E had not actually changed. This leads to a high cost associated with retesting when changes are made, and a high maintenance and overall lifecycle cost. The sequence in which units can be tested is constrained by the hierarchy of units, with higher units having to wait for lower units to be tested, forcing a 'long and thin' unit test phase. The first units to be tested are the last units to be designed, so unit testing cannot overlap with the detailed design phase of the software lifecycle. The relationships between units in the example program in figure 2.2 is much simpler than would be encountered in a real program, where units could be referenced from more than one other unit in the hierarchy. As for top down unit testing, the disadvantages of a bottom up approach to unit testing are compounded by a unit being referenced from more than one other unit. 4.1.2.3. Overall The bottom up organizational approach can be a reasonable choice for unit testing, particularly when objects and reuse are considered. However, the bottom up approach is biased towards functional testing, rather than structural testing. This can present difficulties in achieving the high levels of structural coverage essential for high integrity and safety critical applications, and which are required by many standards. The bottom up approach to unit testing conflicts with the tight timescales required of many software developments. Overall, a bottom up strategy will cost more than an isolation-based strategy, due to complexity of testing units above the bottom level in the unit hierarchy and the high impact of changes. 4.1.3 Isolation Testing Isolation testing tests each unit in isolation from the units that call it and the units it calls. Units can be tested in any sequence, because no unit test requires any other unit to have been tested. Each unit test requires a test driver and all called units are replaced by stubs. Figure 1.2 illustrates the test driver and tested stubs needed to test unit D. A B C D Stub Stub Stub Under Test Driver E F G H I J Figure 1.2 - Isolation Testing A unit test plan for the program shown in figure 1.2, using a strategy based on the isolation organizational approach, need contain only one step, as follows: Step (1) (Note that there is only one step to the test plan. The sequence of tests is unimportant, all tests could be executed in parallel.) Test unit A, using a driver to start the test and stubs in place of units B, C and D; Test unit B, using a driver to call it in place of unit A; Test unit C, using a driver to call it in place of unit A; Test unit D, using a driver to call it in place of unit A and stubs in place of units E, F and G, (Shown in figure 1.2); Test unit E, using a driver to call it in place of unit D and stubs in place of units H, I and J; Test unit F, using a driver to call it in place of unit D; Test unit G, using a driver to call it in place of unit D; Test unit H, using a driver to call it in place of unit E; Test unit I, using a driver to call it in place of unit E; Test unit J, using a driver to call it in place of unit E. 4.1.3.1. Advantages It is easier to test an isolated unit thoroughly, where the unit test is removed from the complexity of other units. Isolation testing is the easiest way to achieve good structural coverage, and the difficulty of achieving good structural coverage does not vary with the position of a unit in the unit hierarchy. Because only one unit is being tested at a time, the test drivers tend to be simpler than for bottom up testing, while the stubs tend to be simpler than for top down testing. With an isolation approach to unit testing, there are no dependencies between the unit tests, so the unit test phase can overlap the detailed design and code phases of the software lifecycle. Any number of units can be tested in parallel, to give a 'short and fat' unit test phase. This is a useful way of using an increase in team size to shorten the overall time of a software development. {mosgoogle} A further advantage of the removal of interdependency between unit tests is that changes to a unit only require changes to the unit test for that unit, with no impact on other unit tests. This results in a lower cost than the bottom up or top down organizational approaches, especially when changes are made. An isolation approach provides a distinct separation of unit testing from integration testing, allowing developers to focus on unit testing during the unit test phase of the software lifecycle, and on integration testing during the integration phase of the software lifecycle. Isolation testing is the only pure approach to unit testing, both top down testing and bottom up testing result in a hybrid of the unit test and integration phases. Unlike the top down and bottom up approaches, the isolation approach to unit testing is not affected by a unit being referenced from more than one other unit. 4.1.3.2. Dis - Advantages The main disadvantage of an isolation approach to unit testing is that it does not provide any early integration of units. Integration has to wait for the integration phase of the software lifecycle. (Is this really a disadvantage?). An isolation approach to unit testing requires structural design information and the use of both stubs and drivers. This can lead to higher costs than bottom up testing for units near the bottom of the unit hierarchy. However, this will be compensated by simplified testing for units higher in the unit hierarchy, together with lower costs each time a unit is changed. An isolation approach to unit testing is the best overall choice. When supplemented with an appropriate integration strategy, it enables shorter development timescales and provides the lowest cost, both during development and for the overall lifecycle. Following unit testing in isolation, tested units can be integrated in a top down or bottom up sequence, or any convenient groupings and combinations of groupings. However, a bottom up integration is the most compatible strategy with current trends in object oriented and object biased designs. An isolation approach to unit testing is the best way of achieving the high levels of structural coverage essential for high integrity and safety critical applications, and which are required by many standards. With all the difficult work of achieving good structural coverage achieved by unit testing, integration testing can concentrate on overall functionality and the interactions between units. 4.2 Integration Testing and Strategies Integration testing verifies that all parts of an application “Integrate” together or work together as expected. This is important because after all the units are tested individually we need to ensure that they are tested progressively. Some of the Integration problems often faced are: · Configuration / Version control · I/O format, protocol mismatches · Conflicting data views / usage · Data integrity violated · Wrong call order / wrong parameters · Missing / Overlapping functions · Resource problems (memory etc.) Many different approaches have been suggested for performing Integration Testing all of which have merit based on the Type of Application, Level of Complexity contained within the Application and the time that has been allocated for testing the Application prior to release. If the emphasis is on uncovering the most defects in the shortest period of time then performing Integration Testing becomes essential. There are three basic Integration Testing methods: They are Top-Down, Bottom-Up and Sandwich methods of testing 4.2.1 Top – Down Testing In Top Down integration testing the top-level control routines are combined and tested first, possibly with the middle level control structures present only as stubs. Subprogram stubs are only present to allow the higher-level control routines to be tested. Thus a menu driven program may have the major menu options initially only present as stubs, which merely announce that they have been successfully called, in order to allow the high level menu driver to be tested. Top down testing can proceed in a depth-first or a breadth-first manner. For depth-first integration each module is tested in increasing detail, replacing more and more levels of detail with actual code rather than stubs. Alternatively breadth-first would proceed by refining all the modules at the same level of control throughout the application. In practice a combination of the two techniques would be used. At the initial stages all the modules might be only partly functional, possibly being implemented only to deal with non-erroneous data. These would be tested in breadth-first manner, but over a period of time each would be replaced with successive refinements that were closer to the full functionality. This allows depth-first testing of a module to be performed simultaneously with breadth-first testing of all the modules. C Fig 1.0 – Top – Down Integration testing C A D A B D E B E F C Fig 1.0 - Test C, D, E are first run on a system composed of module A and module B. Module C is integrated and test C and D are repeated to ensure that there have not been unexpected interactions with A and B. Test F is also run on the system. Top-Down testing process detailed above could be depicted simply in a series of steps as follows: Steps: 1. Main control module used as the test driver, with stubs for all subordinate modules. 2. Replace stubs either depth first or breadth first. 3. Replace stubs one at a time. 4. Test after each module integrated. 5. Use regression testing (conducting all or some of the previous tests) to ensure new errors is not introduced. 4.2.1.1. Advantages · Verifies major control and decision points early in design process. · Top-level structure tested the most. · Tends to make bug location easier · A working version of the system is available early · Minimizes test harness creation · Depth first implementation allows a complete function to be implemented, tested and demonstrated. · Can do depth first implementation of critical functions early. · Top down integration forced (to some extent) by some development tools in programs with graphical user interfaces. 4.2.1.2. Dis-Advantages · Maximizes stub creation; it may not even be possible to write good stubs in some cases · May be impractical (too time-consuming) to use an entire large system as a test harness 4.2.2 Bottom – Up Testing The other major category of integration testing is bottom up integration testing where an individual module is tested from a test harness. Once a set of individual modules has been tested they are then combined into a collection of modules, known as builds, which are then tested by a second test harness. This process can continue until the build consists of the entire application. In practice a combination of top-down and bottom-up testing would be used. In a large software project being developed by a number of sub-teams, or a smaller project where different individuals were building modules. The sub-teams or individuals would conduct bottom-up testing of the modules, which they were constructing before releasing them to an integration team that would assemble them together for top-down testing. Fig 1.1 – Bottom – Up Integration Testing Level N-1 Level N-1 Level N Level N Test Drivers Level N Test Drivers Test Drivers Test Drivers Test Drivers Bottom-up testing process could be depicted simply in a series of steps as follows: Steps: 1. Low-level modules combined in clusters (builds) that perform specific software sub-functions. 2. Driver program developed to test. 3. Cluster is tested. 4. Driver programs removed and clusters combined, moving upwards in program structure. 4.2.2.1. Advantages · Works well early in the integration process: thorough testing is possible, and bugs are easy to find 4.2.2.2. Dis-Advantages · Breaks down when large sub-systems are combined: thorough testing is difficult and bugs are hard to find · Design errors tend to show up late · Much test harness is needed at each step of integration 4.2.3 Sandwich Testing Sandwich testing is both top-down and bottom-up testing approaches combined together. This is the most widely used method in integration testing In sandwich integration and testing, some low level components and crucial functions are developed and tested bottom-up, avoiding the need to create lots of stubs, especially stubs that would be difficult or impossible to write as good simulations of finished code. Top-down integration and test can then proceed using these finished lower-level components. Sandwich integration and testing requires careful thought to identify those low-level components that should be developed early in an overall top-down framework so that big-bang integrations are avoided. 4.2.4 Integration Testing Vs. System Testing Many times the terms Integration testing and System testing are used interchangeably and for simple applications that do not have many components, the criteria and test scripts required to perform testing are similar. But as an application increases in complexity, and size and users demand new functionality and features the need to perform Integration Test becomes more obvious. Following paragraph gives a more clear distinction between Integration Testing and System Testing An Integration Test will thus allow "flaws" in the application between different Objects, Components, and Modules etc to be uncovered while the Application is still being developed and the developers are still conceivably working in the same portion of the application. If the problem were to discovered in a system test at the end of the Development cycle it would probably require more resources to correct than during the cycle. This is especially important in today's market where the drive is to be the first to market a product. System testing specifically goes after behaviors and bugs that are properties of the entire system as distinct from properties attributable to components (unless, of course, the component in question is the entire system). Examples of system testing issues: resource loss bugs, throughput bugs, performance, security, recovery, transaction synchronization bugs (often misnamed "timing bugs"). 4.3 System Testing A fully integrated system that has been thoroughly tested at every level is not enough. It represents the halfway mark 4.3.1 What’s left to Test? If all elements from Unit to system have been thoroughly tested, functionally and structurally, and no known incompatibilities between elements remain, what then is there left to test at the system level that has not already been tested? Approximately half of the testing and QA effort remains to be expended in the following tests: · System level functional verification by the programming staff · Formal acceptance test plan design and execution thereof by the buyer or a designated surrogate · Stress testing – attempting to break the system by stressing all of its resources · Load and Performance testing – testing to confirm that performance objectives are satisfied · Background testing – retesting under a real load instead of no load – a test of proper multi-programming, multi – tasking systems · Configuration testing – testing to assure that all functions work under all logical / physical device assignment combinations · Recovery testing – testing that the system can recover from hardware and / or software malfunctions without losing data or control · Security testing – testing to confirm that the system’s security mechanism is not likely to be breached by illicit users 4.3.2 Choosing System Test · System level functional testing, formal acceptance testing, and stress testing are required for every system. · Background testing is required for all systems but the simplest uniprocessing batch systems. Background testing is usually not required (but is desirable) for application programs run under an operating system. · Load and performance testing is required for Online systems. · Configuration testing is required for all systems in which the program can modify the relation between physical and logical devices and all systems in which backup devices and computers are used in the interest of system reliability. · Recovery testing is required for all systems in which data integrity despite hardware and / or software failures must be maintained, and for all systems that use backup hardware with automatic switchover to the backup devices. · Security testing is required for all systems with external access 4.4 Functional Testing · Black – box type of testing geared to functional requirements of an application. Testers should perform this type of testing 4.5 Regression Testing · Tests the effects of the newly introduced changes on all the previously integrated code · The purpose of regression testing is to ensure proper behavior of an application after fixes or modifications have been applied to the software or its environment. · To create a synergy among functional areas and information system where continual maintenance and improvements to regression testing become part of a normal monthly activity. · To implement lifecycle testing for end-to-end testing. 4.6 Sanity Testing Sanity testing will be performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a sub-set of regression testing. It will normally include a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers etc. 4.7 Acceptance Testing There is more to acceptance testing than just testing hardware and software. Acceptance Testing criteria include: · Focuses on the complete integrated system to evaluate “fitness of use”(acceptance tests are done from the user’s perspective) · Hands-on testing and acceptance must be performed by the actual users and their assistants including consultants, auditors, internal systems staff, etc. · The actual software and hardware configuration (or equivalent configuration) must be tested, and · The actual policies, procedures, manuals, operations, organization structure, and controls that will be in place and required to meet the stated objectives of the systems must be used in the test. 4.8 Installation Testing · Testing full, partial or upgrade install / uninstall processes. · The Installation test for a release will be conducted with the objective of demonstrating product readiness · This test is conducted after the application has been migrated to the client’s site · It will encompass the inventory of configuration items and evolution of data readiness, as well as dynamic tests focused on basic system functionality 4.9 Compatibility Testing · Testing how well software performs in a particular hardware / software /operating system / network environment etc. 4.10 Comparison Testing · Testing that compares software weaknesses and strengths to competing products 4.11 Alpha Testing · Alpha testing consists of the tests done by the team itself . · Product is release to very small and focused group · It’s bit of a final check before releasing the game 4.12 Beta Testing · Beta testing is normally done by the sample of intended audiences for the application · Product is released to wider range of people 4.13 Smoke Testing · This is performed only when the build is ready · Every file is compiled, linked and combined into an executable program every day, and the program is then put through a “smoke test”, a relatively simple check to see whether the product “smokes” when it runs 5.0 Testing Techniques 5.1 Black – Box Testing / Online Testing Focus on functional requirements. Compliments white box testing. Attempts to find: 1. Incorrect or missing functions 2. Interface errors 3. Errors in data structures or external database access 4. Performance errors 5. Initialization and termination errors. Some of the Black – Box testing techniques are: Equivalence Partitioning Boundary Value Analysis Cause – Effect Graphing Error Guessing 5.1.1 Equivalence Partitioning Equivalence partitioning aims in selecting a small subset of all possible inputs that has a high degree of unearthing most errors. The equivalence partitioning is done by taking each input condition and splitting into two or more groups. One group will be a valid equivalence class that represents valid inputs to the program and other will be invalid equivalence class representing erroneous input condition. After these groups are formed, the test cases can be derived as follows. For a valid equivalence class write a test case that covers this equivalence class with an input value. Then write another test case that covers an invalid equivalence class with an input value. Here the equivalence class should be chosen so that, the input condition for a valid equivalence class produces the same result for all input values within the class. For invalid equivalence class a separate test case should be written for each invalid input that is passed to the condition. This is done in order to avoid the masking of one invalid input by another. 5.1.2 Boundary Value Analysis Large number of errors tends to occur at boundaries of the input domain. BVA leads to selection of test cases that exercise boundary values. BVA complements equivalence partitioning. Rather than select any element in an equivalence class, select those at the ''edge' of the class. Examples: 1. For a range of values bounded by a and b, test (a-1), a, (a+1), (b-1), b, (b+1). 2. If input conditions specify a number of values n, test with (n-1), n and (n+1) input values. 3. Apply 1 and 2 to output conditions (e.g., generate table of minimum and maximum size). 4. If internal program data structures have boundaries (e.g., buffer size, table limits), use input data to exercise structures on boundaries. 5.1.3 Cause Effect Graphing Techniques Cause effect graphing comes as a complimentary method for equivalence partitioning and boundary value analysis. It fills in the gap of testing a combination of input conditions which both equivalence partitioning and boundary value analysis lacks. The advantage of cause effect graphing is, it also aids in finding out ambiguities and incompleteness in specification. 5.1.4 Error Guessing Error guessing is a technique, which aims to find out a program for a pre-defined type of error prone situation. Often this is purely based on experience, and presence of documentation of similar error conditions, it proves to be a valuable test case design to unearth errors 5.2 Batch Testing The Batch testing is primarily designed to test batch processes. A batch process is one, which have more than one transaction to be executed one after the other. The significance of batch process is that either all transactions get executed or nothing gets executed. This guide serves as a reference document for performing batch testing in a professional manner. In most of the projects, we do perform the batch testing by default. But we have to remember the fact that the same cannot be proved unless otherwise we do have documental evidence. The familiar and popular testing techniques used for batch testing are: 5.2.1 Complete Execution In this type of testing, the tester will completely execute the batch process. The tester also ensures that there are enough resources for the smooth execution of the transaction. Pass Criteria: The tester should ensure that all the transactions are executed properly without fail. 5.2.2 Partial Execution In this kind of testing, the tester stops the application when the system is processing a batch transaction. There are two methods to stop the execution. a. Application Level Termination In an Application level termination, the tester uses the ‘Reset’ or ‘Cancel’ options in the software application to stop the batch process. b. System Level Termination In a system level termination, the tester physically stops the system or the hardware on which the application is running. Pass Criteria: The tester should ensure that wile terminating a batch transaction in the middle; the application should roll back to the previous state. i.e. No transactions should be have been executed. Examples of Batch processing: 1.Year End Processing in a banking application. 2. Payroll processing. 6.0 Useful tips For Integration Testing · Integration testing is an important part of the testing process. · Sandwich testing is the most preferred method of integration testing approach For Batch Testing To execute a batch test, it is advisable to have a significant time gap in completing the batch process. Processing time can be increased by inserting large volume data in the database. (i.e. batch testing can be clubbed with volume testing) For Online Testing The tester can club all the above-mentioned techniques in forming a test strategy for functional testing.