Websites and online services need to be tested, but what if I told you there was a way in which you could be more thorough while also reducing the time it takes to get results?
Welcome to the world of automated testing.
In your father’s testing department, there would be a piece of software and a book of test cases and specific steps to create a scenario and how to walk through it. Then there would be a phalanx of testers each of whom had an area for which they were responsible (the test cases for that area) and they’d spend the day manually doing each step in the test case: go to this page, click on that button, enter this text.
If a software developer made a change to the functionality, the tester would have to go through each of the tests again. For some features, there could be a very complex set of steps that would have to be executed. It could be a very time-consuming process.
With automated testing, we spend our time writing the test cases first on paper and then we implement them in the Python programming language. It automatically makes the call into our system’s API (interface) or in the case of the graphical user interface, automatically runs the browser and does all the steps.
Once the test case is implemented in the programming language, it literally becomes a case of “one press and it’ll do the rest”. You can watch it on the screen automatically log into the DynECT portal, enter usernames and passwords, pick from the menu, enter the necessary information for whatever feature is being tested, make the necessary selections and click the necessary buttons.
If needed, it can then go out to the Internet and check results against our DNS servers and verify that the change propagated through the system.
In short, what might have taken 10 or 15 minutes by hand is completed in less than a minute automatically.
This allows us to build up a whole suite of tests that can run at any time we want, even at three in the morning. We can run a test of the entire product and report the results back within 30 minutes or so, whereas if these had to be done by hand, it could easily take two days or more.
Within that, we’re also structuring our test modules whenever possible so we create a library of test components that can be reused within the testing system and are working to build tests on abstract layers so they can be run against various scenarios (e.g. various lab environments, against production and with various client profiles).
The net result is that we can accomplish the same testing with a handful of engineers and some technology that otherwise might have required a roomful of testers to achieve the same result, and we can do it consistently and faster.