Validation approaches for API testing
Recently I am rather confused of validating APIs. I’m concerned about this because now all the validations are based on the value of the successful node. I think the response is not credible because it is provided by Web services too. Let us suppose a situation: If we receive a successful response after sending a delete lock request ( GUID not generated by API), but the lock still exists in Life admin. This is not correct.
Approach | description | Advantage | Disadvantage | Suitable situation |
---|---|---|---|---|
Success node from response.xml | Validate the value of success node is true or not | Time saving when preparing TDM data | Not credible | Add/Get(lock=1)/Delete APIs + Extra steps validation |
UI validation | Validate the result in life admin through UI | More exact | Lower efficiency with UI check, not applicable for Get(lock=0)/Find APIs | Add/Get(lock=1)/Delete APIs + Extra steps validation |
API VS life DB | Validate the result by comparing data from API VS life DB | More exact | Time confusing when preparing TDM data, not applicable for Get(lock=0)/Find APIs | Add/Get(lock=1)/Delete APIs |
Extra API steps | Validate the result by next API steps. | Time saving when preparing data | The validation for the next steps must be reliable | Add/Get(lock=1)/Delete APIs. E.g. if the Amend API can be passed validate by other credible method, the successful response of Add API is credible. |
I can’t agree with the view in your last email “add a step to invoke a Policy Enquiry screen in the BO and walk through the screen to check the details passed in are stored and displayed correct” based on the following reasons:
- Data display on screens is
out of scope
or API cases .
Data displayed functions can be included in other manual function cases or UI automation cases, but not API cases. - All details displayed on screen are
sourced from LifeDB
.
If wevalidate the API result on screen via BO, the defect from Client-side(like datadisplayed incorrectly) will confounds the API cases. - Validate Response node VS Life DB to ensure the
data integrity
for API cases. * -
- All the related data(according to the schema criteria ) should be returned of the GET API. Ifnot , it’s a API defect.
-
- Automated cases should validate the APIs by comparing the data from TDM API(I.E. request.xml)& response.xml with Life DB. For example, validate data in ct_client tableVS AddClient, qt_quotation VS GetAndSaveQuote, ha_holding_area VS AddProposal,PolicyEnquiry VS po_policy, etc.
UI requirements
usuallychanges with different builds.
Moreefforts will be paid during developing and maintenance. Current keywords(Checkpoints) of C# TAF is- Invoking application screen and going through all the details will lead a sharp reduction in
testing efficiency
.