|
1. Testers Slowly and Manually Formulate Complex API Tests:
A single API can request a vast range of data. QA must identify every combination of call and data needed for rigorous API testing, but they are faced with incomplete documentation and highly technical specification files. Slow and complex test design misses out most of the possible tests.
|
1. Model Complex APIs as Easy-to-Use Flowcharts:
Clear and precise flowcharts are built automatically from API documentation and existing tests. The visual flowcharts map all possible routes that data can flow through an API. Missing logic is quickly spotted and added, and rigorous tests are generated automatically for every possible end point.
|
|
2. Expected Results Undermine Testing Confidence:
Testers must formulate the expected results needed to verify that each request gets the right response when used to call each data combination. These hard-to-define expected results are often missing from documentation, leaving QA teams guessing.
|
2. Define Full and Accurate Expected Results Easily:
Testers build asserts into the flowchart models, and generate expected results at the same time as the rigorous API tests. Mid-test asserts validate that an API functions correctly at every point in its logic, and testers know they got the right result, for the right reason.
|
|
3. Test Data Risks Non-Compliance and Undermines Testing Rigour:
Testers execute their requests against an incomplete database that only contains a fraction of the data types that might be requested in production. The majority of combinations go untested, leaving APIs exposed to costly bugs that will be highly time-consuming to fix post-release.
|
3. Specify “Just in Time” Test Data for Every Possible Test:
Dynamic test data is defined for each test step contained in the model, using a comprehensive range of over 500 easy-to-use data creation functions. The combinable functions resolve “just in time” during execution, ensuring that there is up-to-date test data to rigorously test every combination.
|
|
4. Resource-Intensive Testing leaves API Chains Vulnerable:
The number of possible tests grows exponentially as APIs are chained together, but QA teams lack the systematic or automatic means to reduce the vast number of tests. Resource-intensive API testing exercises only a minority of the call chains that could be executed post-release.
|
4. Generate the Smallest Set of API Tests Needed for Rigorous Testing:
QA teams drag-and-drop subflows from a shared repository to chain together APIs. The subflows contain all automation logic and data needed for testing, and coverage algorithms generate the smallest set of tests needed test complex API chains rigorously tested in-sprint.
|
|
5. Slow and Erroneous Data Comparisons:
Testers execute their tests, producing large quantities of complex responses. They must compare the resultant data slowly to poorly defined expected results, laboriously formulating run results.
|
5. Rapid "Single Pane of Glass" Test Execution:
API tests are executed across proprietary, homegrown, or open source frameworks. Responses are compared automatically to the expected results, with run results formulated automatically in a range of formats.
|
|
6. Test Maintenance Leaves Previous Request Versions Untested:
APIs change fast, but users continue to send old requests. QA teams must test against all possible versions, but lack version control and must update tests and data manually after every change. API testing falls behind, and insufficiently tested APIs return erroneous responses for old request versions.
|
6. Rapidly Test Against Every Possible Version of Request:
Updating the central model maintains all the API tests and data automatically. Full version control allows testers to quickly and simply roll-back to a previous version of their API tests, validating that the new API functions as it should when all version of API call are sent to it.
|
