We were managing a test process for a financial organization project, some changes were requested from the customer to a specific charge rate, the modification test scope was defined and approved, and we start dealing with it.
Before they go live by a few hours, the test analyst confirmed that the modification affects a report and it’s not mentioned in the test scope it missed out because this report is a low priority and it’s not used in a frequently critical system path.
This leads to a review of all test conditions and suites that were created before to make sure that all E2Es are covered regardless of the priority of the test item.
The converging system flows is not an easy task, especially if the domain knowledge not exists.
Many friends ask me in different training sessions and projects as well as the queens about what is the difference between system tests and an end to end-to-end
System test and End to End test most of used the terms interchangeably, but they almost are not the same.
On the Term of definition, we can consider system tests as a level when we test an integrated system to verify that it meets specified requirements. meanwhile, End to End test is an under-functional test to validate the suitability and interoperability characteristics, and identify system dependencies and, ensure that the right information is passed between various system components and systems.
The key challenge in E2E is to define the flow of applications from starting point to endpoint ts.
For example, in our case study, if the charges are assignee d to any transaction you need to know what the endpoints of those transactions are, it may be another transaction, form, module, report, etc…, and maybe with different “approval statuses” for each transaction.
You can run the E2E with any test level not only the system test, using stubs and drivers may help in component integration tests not only when the development or while application is done.