1. Evaluating Functional Testing: completeness, correctness, and suitability. The function of a system is WHAT the system is doing. It can be measured through functional coverage.?Functional test design and execution may involve special skills or knowledge, such as knowledge of the business problem the software solves. Should be performed at all test levels and done as early as possible.
- Component Testing: Tests are designed based on how a component should calculate compound interest.
- Component Integration Testing: Tests are designed based on how account information captured at the user interface is passed to the business logic.
- System Testing Tests: are designed based on how account holders can apply for a line of credit on their checking accounts.
- System integration Testing: Tests are designed based on how the system uses an external microservice to check an account holders credit score.
- Acceptance Testing: Tests are designed based on how the banker handles approving or declining a credit application.
2. Evaluating Non-Functional Testing: liability, performance, efficiency, security, compatibility, and usability. Answers the question HOW the system is doing it??Non-functional test design and execution may involve special skills or knowledge, such as knowledge of the inherent weaknesses of a design or technology. ISO standard (ISO/IEC 25010): Classification of software product quality characteristics.
- Component Testing: Performance tests are designed to evaluate the number of CPU cycles required to perform a complex total interest calculation.
- Component Integration Testing: Security tests are designed for buffer overflow vulnerabilities due to data passed from the user interface to the business logic.
- System Testing: Portability tests are designed to check whether the presentation layer works on all supported browsers and mobile devices.
- System Integration Testing: Reliability tests are designed to evaluate system robustness if the credit score microservice fails to respond.
- Acceptance Testing: Usually tests are designed to evaluate the accessibility of the banker’s credit processing interface for people with disabilities.?
- Performance Testing: how many users can connect to the system and how will that affect the performance of the software.
- Load testing: how will the system perform if we do a single transaction so many times.
- Stress Testing: how will the system perform under very tough circumstances, many users, many transactions, low memory etc.
- Usability Testing: is the system easy to use.
- Maintainability Testing: Is the system easy to maintain if we need to fix a defect.
- Reliability Testing: is the system reliable or does it crash eventually.
- Portability Testing: is the system easy to port from one platform to another?
- Security Testing: is the system secure enough that no hackers can hack into the system and get unauthorized data?
3.??????Evaluating White-box Testing: such as architecture of a component, or system is correct, complete and as it’s specified. Derives tests based on the system’s internal structure or implementation. Internal structure may include code, architecture, workflows, and data flows within the system. Can be measured through structural coverage:
-?????????At the component testing level, code coverage is based on the percentage of executable statements tested in the component or, the percentage of decision outcomes tested. These types of coverage are collectively called code coverage. At the component integration testing level, white box testing may be based on the architecture of the system, such as interfaces between components. White box test design and execution may involve special skills or knowledge.
- Component Testing: Tests are designed to achieve complete statement and decision coverage for all components that perform financial calculations.
- Component Integration Testing: Tests are designed to exercise how each screen in the browser interface passes data to the next screen and to the business logic.
- System Testing: Tests are designed to cover sequences of web pages that can occur during a credit line application.
- System Integration Testing: Tests are designed to exercise all possible inquiry types sent to the credit score microservice.
- Acceptance Testing: Tests are designed to cover all supported financial data file structures and value ranges for bank-to-bank transfers.?
4.??????Evaluating Change-related Testing: such as confirming that the defects have been fixed. Old confirmation testing and looking for unintended changes in behavior resulting in behavior of the software or environmental changes, which is called regulation testing. After a defect is fixed, the software may be tested with all test cases that failed due to the defect, which should be re-executed on the new software version. It is important to ensure that the test is executed exactly the same way as it was the first time, using the same inputs, data and environment. The software may also be tested with new tests if, for instance, the defect was missing functionality. The purpose of a confirmation test is to confirm whether the original defect has been successfully fixed.?
- Component Testing: Automated regression tests are built for each component and included within the continuous integration framework.
- Component Integration Testing: Tests are designed to confirm fixes to interface related defects as the fixes are checked into the code repository.
- System Testing: all tests for a given workflow are re-executed if any screen on the workflow changes.
- System integration Testing: Tests of the application interacting with the credit scoring microservice are re-executed daily as part of continuous deployment of that microservice.
- Acceptance Testing: All Previous-failed tests are re-executed after a defect found in acceptance testing is fixed.
