Test cases document is one the artifacts that ESB team needs to prepare.
Normally ESB team should do the testing in Dev and QA environment before processes are handed over to program or project team for UAT testing.
We should capture all the test cases covering each function mentioned explicitly and implicitly in FS. You should ask source system team to provide sample payload. You can use the same in testing tools (SoapUI /Postman etc) to trigger the processes.
You should involve source and target application team to test the process in development environment if possible rather than involving them in higher environments for UAT. The sooner you involve them the better. They should start with sanity testing and dry run afterwards. You should detect as many bug as possible in development environment itself. It will save efforts as detecting and fixing bugs in higher environment is costlier.
The test cases I have mentioned below should be prepared and executed by middleware team.
UAT testing plan should be prepared and executed by respective application team intended to receive or send data. Because most of the time middleware team does not have access to the source and target application.
You can use same documents to capture test results. That is why fields related to test results are also added.
The test cases document should have following contents.
List of processes to be tested.
| Sr No | Process Name | Successfully Tested(Y/N) | Date of Testing | Comments |
(You can have separate test case document for each processes if processes are complex and there are large number of test cases for each process.)
Process Name: (Mention the process Name to be tested)
Testing scenarios:
(You should capture high level test scenarios. Normally you should do negative testing first, I have given sample test cases as per sample FS which transfer web service payload to destination after database lookup. You should set up test cases scenarios in order of functionality to be executed by the process)
| Test Case No | FS-ID | Description | Accepted(Yes/No) | Reject Reason | Comments |
| TC-ERR-01 | FS-ERR1 | Check if invalid Messages sent from Target | |||
| TC-ERR-02 | FS-ERR-2 | Check Connection failure to the database | |||
| TC-ERR-03 | FS-ERR-3 | Check connection failure to the Target system | |||
| TC-GEN-04 | FS-GEN-1,FS-GEN-2,FS-GEN-3,FS-GEN-4,FS-ERR-3 | Check all the processing steps of successful Message transfer |
Test case: TC-ERR-01 (For each test cases, you should define detail steps)
Description: Check if invalid Messages sent from Target
Steps
| Step No | Step Description | Test Data | Expected Results | Actual Results | Date of Execution | Execution Status(passed/Failed) | Comments |
| 1.1 |
Trigger the process with invalid payload (from any SOAP /REST API testing tools like Postman, SoapUI etc) |
Payload=Invalid payload | 1.Error mail notification should sent to the support group with invalid payload notification message
2. An audit entry should be inserted in audit table. |
Test case: TC-ERR-02
Description: Check connection failure to the database system
(Mention actual test data in the testdata column)
Steps
| Step No | Step Description | Test Data | Expected Results | Actual Results | Date of Execution | Execution Status(passed/Failed) | Comments |
| 2.1 | 1. Change database connection to wrong jdbc url
2. Trigger the process (from any SOAP /REST API testing tools like Postman, SoapUI etc) |
Jdbc Url=wrong url,
Payload=valid payload |
1.Error mail notification should sent to the support group with database connection failure messages
2. An audit entry should be inserted in audit table. |
||||
| 2.2 | 1. Set connection String to correct JDBC url
2. Set userid/password to invalid credentials
3. Triger the process |
Database url=correct url,
Userid/ Password=invalid, payload=valid |
1.Error mail notification should sent to the support group with invalid credentials message
2. An audit entry should be inserted in audit table. |
Test case: TC-ERR-03
Description: Check connection failure to the target system
Steps
| Step No | Step Description | Test Data | Expected Results | Actual Results | Date of Execution | Execution Status(passed/Failed) | Comments |
| 3.1 | 1. Change the connection url to any wrong url as per test data,
2. Change the database connection to valid URL with valid credentials
2.Trigger the process |
url=invalid url,
JDBC=correct url,payload=valid |
1.Error mail notification should sent to the support group with Connection failure messages
2. An audit entry should be inserted in audit table. |
||||
| 3.2 | 1. Set connection String to correct url.
2.Set userid /password to invalid credentials
3.Triger the process |
Connection url= valid url,
userd/password=Invalid payload =valid |
1.Error mail notification should sent to the support group with invalid credentials message
2. An audit entry should be inserted in audit table. |
Test case : TC-GEN-04
Description: Check successful message delivery
Steps
| Step No | Step Description | Test Data | Expected Results | Actual Results | Date of Execution | Execution Status(passed/Failed) | Comments |
| 4 | 1. Set connection credentials to correct values
2.Trigger the process with valid payload |
Connection url=Valid,
JDBC=correct url, Credentials =correct, payload=valid |
1.Success return code is sent from target.
2. An audit entry should be inserted in audit table. |