Test Strategy

Strategic Overview The underlying strategy for the testing and automation for Union project is driven by the fact that the product to be tested/automated is an Angular based web application. An important part of the testing also involves the APIs that need to be tested for Union. As part of the first phase of the testing framework, we would be creating one framework, that will have UI tests as well as API test suite. The main focus will be on how to implement end to end integration tests, in order to provide maximum code coverage.

Objective The Major objective of the testing entails making sure that the product being delivered is of high quality. Since quality is a team objective, the testing will start from the development side, where the bulk of testing will be done as part of Unit Testing. The unit tests will provide a surety that the individual components are working fine and then the focus can be put on integration tests and end to end tests. The essence of testing is creating test cases, that are meant to break the product. The focus should be more on the negative tests, that would cover the corner scenarios and would confirm the robustness of the product. The framework would be created keeping in mind that the UI as well as API tests are easy to kickoff and easy to update.

Scope The scope will comprise doing all possible testing to break the product. The unit tests will be created by the dev team within their dev framework and will be kicked off as part of the build cycle. The API automation tests will run once the unit test run is complete and once the API automation completes, the UI tests will be kicked off. At the moment, the plan is to create the test framework in such a way that we can merge the API and UI tests to create end to end integration tests. In case any area needs to be manually investigated, we might need to do some basic exploratory testing. Regarding the scope from business perspective, we have defined the scope of the testing to be done until the Union specific UI and APIs. The integrated product testing is out of scope. To enhance better integration with the products, the test framework will make sure to test the scenarios around the integration of API endpoints of the products with Union.

Business Cases One important thing to note in the testing is that we have a bilateral structure to test. The Union application hosts different applications in the Iframes and the applications are integrated via APIs. The business cases have been created keeping in mind that we do not have to test the products integrated, rather we need to test the Union application and ensure smooth functioning of the onboarded products. We have identified a set of use cases, that would form the basis on which the framework will be based. 1. End to End: Give permissions to a user from DB and then perform the UI test scenarios. 2. Permissions: Give and retract permissions and verify the user login accessibility via permissions API. The scenarios around level of permissions need to be tested. 3. Single Sign On: Scenarios for company logins using SAM. 4. Domain support in federation login: Need to get details as to which domain would be supported by Union. 5. New User landing page: Need to get details on the Union application landing page for a new user and permission verification. 6. New product: Need to create generic scenarios which are not dependent on a product, so that any new product that is integrated can be tested by just making config changes. 7. Refresh and timeout scenarios: With refresh, should the union be refreshed or the product should be refreshed. 8. Routing: Scenarios around the content that need to be displayed and the query map and breadcrumbs via Route APIs. 9. Union Access token: Scenarios around the access token that is generated and the way it is shared in the browser settings, like making sure it is not publicly accessible. 10. Widgets: Scenarios around widgets and their use cases via Widget APIs. The above cases are a set of fundamental business scenarios, which we can leverage to create our test cases. As the development progresses, we will keep adding business cases to the above list. Dependencies: After creating the above mentioned business scenarios, we came across a set of areas, where we are dependent on the product or business. To ensure smooth functioning of the Union application and smooth onboarding of the products we have created a set of dependency areas, which we need to curb prior to moving ahead. 1. Login logout APIs of the products should be exposed, to be integrated with the Union APIs. 2. Getting data from the product APIs. 3. Session Management for Union and the products. 4. SSO Management. 5. Logging in different users and providing permissions via APIs and not using databases. 6. All applications to be integrated with Union should fall under the same domain name i.e. SnPGlobal

Architectural Diagram Looking at the architecture of the union application, we designed a structure from QA perspective where we have identified the areas where we need to regress the testing activity, to ensure smooth integration with the products.

*The perforated boxes are the areas that we have identified that need to be tested thoroughly.