Hard times have come... They make us sit at home and not go anywhere. In our industry it's not so bad yet, we can and even have to work from home. I'm not going to elaborate here on how to arrange for yourself to work from home so as not to go crazy. You've probably watched or read a lot of industry material on the subject. I want to look at the current situation from the other side. Has your software testing process lived up to the coronavirus? Is it as effective as it was just 2 months ago?
If your solution is mainly based on manual testing, the smoothness of its execution, may now be adversely affected by the overall load on the Internet. It is known, now almost the whole world, if it can, works from home. Even video platforms are limiting the maximum resolution of the content delivered. Working from home, connecting to the server of the application under test, using a VPN connection, you may not have the same bandwidth as in the office. And this increases the time it takes to perform tests, as well as your frustration. Maybe this is a good time to finally start implementing automation?
When it comes to automated tests, the most important rule is: don't run tests from your computer. This is your machine for creating tests, not for running them. The same goes for the software you are testing. After all, you don't agree to test it on the developer's machine, it's just uploaded to the test environment. You should put the same regime in place for automated tests.
With this approach, you provide your tests with additional stability and repeatability. They are no longer dependent on the location of your computer and its load. In a nutshell, no matter where you are or where you run your tests from, they always execute under similar conditions, and most importantly, they can be confined to your corporate intranet, so the current conditions should not affect them in any way.
Build server / CI
source: https://pixabay.com/illustrations/devops-business-process-improvement-3148393/
Since you shouldn't be running tests on your computer, run them on an external server, a build server. The most commonly used products these days are Jenkins or TeamCity.
Keep in mind that to begin with, this doesn't have to be a full CI process right away, where tests are automatically fired after every build and after every new application deployment. If this is your first approach to integrating automated tests with the build server, it's worth starting with the simplest solution: tests run manually on the server. This is still a much, much better solution than testing from your own machine, and that's where I advise you to start. There will still be time for more automation....
If your automated tests are based on one of many programming languages (Python, Java, C#, etc., etc.) along with a dedicated library to make writing tests easier (e.g. RestAssured for Java) then you should have no problem running these tests on your CI system. After all, running such tests is practically no different from building the application you need to test. Just make sure that the CI server has access to the service under test. Use the same command that you run the tests from your machine.
Postman
If your automated testing solution is based on Postman, here is a little complication, but most importantly, it is still possible. In this case, a tool called Newman rushes to your aid. This is a tool that allows you to run Postman collections from the command line, bypassing Postman itself. You now need to export your test collection, and then:
1newman run <plik_collections>
of course, instead of <file_collections> substitute the file name of your tests. If you use environment variables as well, predefined global variables, newman also allows you to use them, add options to the command:
1--globals <plik_globals> --environment <plik_environments>
Newman also supports a dataset file for parameterized tests. Unlike Postman, it only supports the CSV format, so if you've been using data in the form of JSON files so far, you'll be faced with converting it to the appropriate format. After that, all that's left for you to do is to extend the command with an additional option:
1--iteration-data <plik_danych>
In summary, newman gives you the ability to run Postman tests, using all the necessary functionality sewn into the original. As a result, you should no longer have a problem running such tests from the CI server.
Web UI tests
source: https://pixabay.com/illustrations/software-testing-service-762486/
If you need a browser for automated tests, you can still have the CI server perform such tests. You just need to solve the problem of How to provide a browser to the server? Here you have two basic solutions available.
1. headless mode
Firefox and Chrome allow you to run in the so-called "headless" mode . This is a mode in which the browser does not display its window, everything happens in the operating memory of the system. Aside from this minor difference, all other functionality remains the same, It also works to take screenshots, as long as you use the Web Driver's built-in features and do not use system calls.
If you decide to use this approach, all you have to do is install the browser you need on the server that hosts the CI system, and fire it up in "headless" mode for testing. You can find more information for Firefox here, and for Chrome here.
2 - Selenium Grid
The above solution has one drawback: it puts additional load on the CI server, which is usually not acceptable. If there are multiple projects using this server, building them and running unit tests can become much longer, which is not desirable. To the rescue comes Selenium Grid, which is a dedicated server whose shared service is browsers (mostly run in headless mode).
Once you've decided on this solution, or just want to give it a try, my advice is to use one of the off-the-shelf solutions. The biggest advantage from such an approach is the simplicity of running such a service, in the age of ubiquitous docker it is one command and the server is up and running, and you can use it. The second advantage is additional functionality such as extended reporting, or recording the browser window during the execution of the test, so that you can later play back such a recording and see exactly what went wrong.
For my part, I can recommend two such ready-made Selenium Grid products: Selenoid and Zalenium. Check them out yourself and see how easy it is.
Summary
If the effectiveness of your tests in the era of coronavirus is the same as before, bravo to you! You have everything well thought out and your project passes the coronavirus test. But if it doesn't, maybe this is a good time to see what you can improve so that in the future it won't matter where you run your tests from. And once you've improved it, it might be a good opportunity to buy an RV and hit the road, of course still working from wherever you happen to be staying....
