This might be just a proof-of-concept but looks likely to be implemented in the near future. So, last week I received information from my coworkers, that there were several users who complained about experiencing looping issues when trying to share a unique link from web (the users using Firefox) to Telegram. And then I asked, “have you tested it before?” they replied, “not yet, because little time to test in a different environment”. And thus, this idea was born
Background Problem
To sum up the background problems about what happened
- Parallel testing is difficult to do because it is limited by time and the person who’s testing it
- Need to perform testing in different environments (whether it’s related to the browser driver version or different edge scenario)
- Little time to test, but too many test cases or test scenarios were covered. Existing automation also doesn’t come in handy
After doing little research and some development, the parallel testing flow that I propose is relatively simple and straightforward. We only need to execute some existing automation test cases that already exist in our TestProject agent, then we will prepare the deployment for the TestProject agent, afterwards the web driver we want (Chrome or Firefox) which later when we execute the test, the TestProject agent will automatically run on the Kubernetes cluster and will execute all the test cases that we have prepared before in a different environment. The simple concept looks like this
But, why on Kubernetes?
To maintain extensive and exhaustive test cases, long-running automation UI test and complexity, you need to do auto-scaling, auto-deployment or auto-replication on multiple different environments. Like I said before, because there is little time to test in various browsers or environments, we need to orchestrate it somehow, and that’s why Kubernetes is the right choice
There are a lot of PaaS outside that outsource this kind of work like BrowserStack or Saucelabs, but here we are trying to reduce the cost possibility (of course because they are more expensive :P)
But, another problem might occur if you asked me about how to do a test in Safari. That’s quite hard to do after a few testing iterations, since on iOS/Mac device, it can’t be dockerized due to different OS, the only possible way is to use a VM which will be connected later from the Selenium hub
Caveats
Since all the primary test suite collections for the TestProject agent only exist in the cloud, integration testing with our primary codebase is currently not possible