Test Architecture design for a microservice environment, an example
There was a time when there were solid SDLC and STLC cycles which had endless iterations when the project has a higher complexity. With the advent of Agile and CI/CD tools, the tech teams get to run any tests at any point of the pipeline upon any change in code however minuscule it maybe. I have a design for one such architecture in mind with respect to the test pyramid above.
First and foremost, my apologies for the imperfect flow chart diagram. Still trying to wrap my head around drawing them. Now lets go block wise, the first block is the Manual test.
Manual Tests : The first line of verification when a new feature/design level fix is pushed. if you're wondering "Why is this guy still talking about manual tests? Is he a dinosaur??". I assure you that I am a human, that too an AGILE one :). The whole point of manual tests and writing manual test cases is that the test data sets coming from the manual testers are highly valuable for the developers for writing unit tests before committing or merging the code as seen in the diagram.
QA Phase 1 : This is an important phase where the build verification testing is done. The most basic tests in UI and all the service related tests for the already existing API’s are done here. All the possible combinations of the currently existing API calls can be stored inside a few JSON files or a .csv file or any other medium and can be run sequentially using a data driven approach by the respective API test tool/framework.
QA Phase 2 : All the regression tests(The specific modules where the changes have been done) will be tested separately by triggering the specific test scripts. The whole design pattern of POM(Page object model) can be referred here. Using git hooks, whenever the UI and backend branches are merged, the test related to the respective module can be triggered.
Test Report/Integration : The result of all the tests can be sent to the respective teams using the respective language’s mail API/jenkins plugin. If a test management/Project management tool such as Jira/TestLink...etc is used, the status of the specific automation test case can be updated so the average stability of every module can be checked WRT the number of test cases passed/failed per period of time
Complete Test Pass/Fail : If all the tests passed, the build is deemed to be stable and the load/performance tests can be run on that build WRT the performance metrics collected and the . All the modules that are failed will be considered for fixing and those fixes will be tested along with the new functionalities that are added.
Once all the test tools are finalized, each and every stage of the above plan can be modified/scaled as per the project requirement