Changes

:The Postman Testrunner Framework was born out of a need to test our the API serving our mobile banking apps, in a large pan-company , integrated test environment, over which we had little control. :Our API server(s) (platform) acts as an aggregator of a number of different several core online banking systems (OLB's), each serving many multiple financial institutions (FI's), and each with its own API data/interface contract. :The integrated environment was used by hundreds of staff, across the company, and the data setup constantly change for the various testing needs. Testing here is never deterministic, it has to be opportunistic!:We needed a simple check of API functionality, capable of exercising all integration paths across the range of different OLB data interfaces, and FI/user configurations. To do this, it It had to be flexible so that it could to run for a range of users, FI's, and OLB's, as well as via for different test deploy instances of our platform. :We captured the API calls from the mobile app (Using network capturing tools (Fiddler, Burp Suite, and MITM Proxy) we traced the API calls from mobile app and designed a Postman solution that emulates the app's sequence of API calls. for a variety of users as they would have been made by the application. :For a test user to be able to start using the application they need to select the test environment that has an instance of the platform, a code to select the FI, and the user's credentials (as well as selecting the type of device). Thereafter, the information required must be obtained in preceding calls. For example, if you want to test a transfer scenario, you need to first obtain a list of their accounts.