This article provides the number and types of tests required to achieve high test coverage of the requirements outlined in the following sections for granting credit limit access to customers. The software under test belonged to WonderCard Ultd. Credit card operations division after updating the company’s business rules governing the awarding credit limit access procedure. The test sets outlined in this article represent the preliminary test cases inferred from the requirements gathered by the testing team before the software solution implementation. Therefore, the criteria used to identify these test cases focused on covering all the conformance and fault-directed testing options available to the testing group. The following section outlines the number and types of test sets identified based on the system requirements provided by the company and their justification over other approaches.
Test Sets
The testing approach in this project broke down the test requirements into test sets based on the testing design options, such as conformance-based test designs that provide the conformance test set and fault-directed tests that provide the boundaries and scope test sets for the data requirements. The selected test sets included the test set for determining credit limit increase-worthiness of a customer based on the new operational needs of the company, the business rules test set, and the data validity test set. Each of these test sets contains several test cases covering specific areas in the scopes outlined by the boundaries of the test sets. For example, the conformance-oriented test set for determining if the provides the required outputs for customers based on the criteria outlined in the new algorithm only consists of tests that cover a wide array of possible customer states as inputs. The business rules take different organizational states as inputs and tests for potential failures in the system, given invalid assumptions concerning the new business rules. The final test set developed for this project consisted of cases that determined whether the software held up under varying data conditions. Clearly, the software would require more than three test cases, but this criterion provided a sufficient starting stage for the process.
The choice to divide the testing protocol into test sets that contain multiple test cases was based on the approach’s ability to abstract complex test details involved in test design away from the protocol design to make the problem smaller and more manageable (González, 2015). An integrated test set that encompasses all test cases would force the testing team to lump all the diverse test details for multiple test cases in the same repository, introducing various points of failure in the testing process. Specific test cases divided along test design approaches available to the testers divided the problem into categorical sub-problems that could be analyzed individually to produce more coverage of the requirements. Therefore, this approach encourages the systematic processing of information at each testing stage (González, 2015), reducing the probability of leaving out crucial conformance requirements or conditional defects in the software. A testing model for each test case could help test the intended behavior of the system in the dimension under focus during subsequent stages in the software implementation process (Felderer & Herrmann, 2019). The following section outlines the test cases selected under each test set based on the functional requirements provided by the organization for the new system.
Conformance-oriented Test Set
The test set for determining how well the system conforms to the highlighted requirements will include test cases for deciding when customers do not qualify for credit limit increases and when they are eligible for ten, fifteen, or twenty percent credit limit increases. These four test cases would ensure that the organization always captures the correct customer status and produces the expected outcome given that they fulfill the suitable condition. The choice to include only four conformance-oriented test cases was to capture all the abstract details encoded in the requirements in the form of test case designs. Once the software product passed all test cases in this test set, the developers would have confidence it captured all the functional requirements described by the management to a satisfactory extent. The conformance-oriented test cases could also act as test sets, providing an avenue for further analysis of the system’s behavior under various functional states.
Fault-Oriented Test Cases
The other test cases focus on identifying possible faults that could make the system behave unexpectedly, such as not adhering to business rules or failing to account for various user data. Therefore, the test cases included these two broad approaches to fault-oriented software testing. The business rules test set included all test cases that sought to identify faults in the system’s implementation of the rules specified. These test cases were the test to determine if the software operates on the expected inputs and handles unexpected inputs correctly and whether the business rules exclude any customer demographic. The two test cases above support the system’s business logic and ensure it conforms to the outlined requirements by mitigating faults in the business logic.
On the other hand, the data validation tests sought to identify possible areas of failure in the data provided or produced by the system, such as invalid input types, invalid inputs in terms of relevance and currency, errors in data analysis and manipulation, and logical errors in the flow of data through the system. Test cases for output data included the test for errors in data samples with customer information based on random distribution. These five test cases could be split further into more granular test cases as the system’s data requirements become more apparent. This choice of test cases made it clear that the testing process would follow a systematic design, providing a clear pathway to implementation.
Conclusion
In conclusion, this software testing project would follow a systematic approach involving breaking down the test process into test sets that contain various test cases in specific domains. The test sets include conformance-oriented and fault-driven test design approaches and helped divide the problem into smaller groups that we solve separately (divide and conquer). After determining the test sets required for the project, this article outlined the number and type of test cases in each to provide a top-down view of the entire testing process.
References
Felderer, M., & Herrmann, A. (2019). Comprehensibility of system models during test design: a controlled experiment comparing UML activity diagrams and state machines. Software Quality Journal, 27(1), 125-147.
González, M. R. (2015). Computational thinking test: Design guidelines and content validation. In EDULEARN15 Proceedings (pp. 2436-2444). IATED.
write