Home/Remote Testing

Remote Testing: when all cry out, please go back to same old, same old…

All was tested thoroughly and planed to the smallest detail. You really were looking forward to this rollout. A rollout in 5 different countries, set in their own environment used by the people locally. All at once released from the headquarters. And then it happens, the first feedbacks arrive: it is a disaster! To clarify, it was unusable, every action took a gazillion time longer than with the old software. To sum it up, a story based on real-life experience.

This can happen to cloud solutions as well as on-premise installations. If you have not experienced one of those rollouts that did not quite work as expected, you can feel extremely lucky. Most of us still remember the feeling after this happened for the first time. Everything is prepared for the magic go-live and then, a few hours later, hell breaks loose.

Sometimes it is because of a faulty go-live decision in the first place, but other times we signaled green, as all tests are passed, nevertheless the customers (internal or external) experience a mess – from their point of view. Till the point the call it “unusable”.

This blog post describes a modern approach to solve this problem: Remote testing.

A possible solution take the modern approach of remote testing.

stop testing on your local PC

The Go-Live was a disaster!

What went wrong in this delivery example? Testing was limited to a single location! After you have the short answer, let us dig a bit deeper in this real-life example. The whole CRM system is cloud based and all tests were successfully passed.

Central Repository

The tragedy started at the time the test plan was defined. It was a global rollout of the CRM and testing was split in functional, performance & usability testing. Functional tests were executed on-premise in the headquarter, usability was accepted by the managers and performance testing was passed with tremendous success.

how to get help in running tests

Why are all complaining but the Headquarter?

After the go-live everybody complained. Everybody but our users in the headquarter. While everything worked for our little shiny world, the headquarter, exactly where it was tested, it did not work for the rest of the world. Small latency problems caused by accessing a central system hosted in the headquarter summed up and made it, and I use the term of the customers, unusable. Some examples: It took the salesman 5 minutes to open the “create new lead” form, a search took more than a minute to return results, reports where generated overnight because they took too long.

It took the salesman 5 minutes to open the “create new lead” form, a search took more than a minute to return results, reports where generated overnight because they took too long!

How do you test? Did you consider that your code might access central infrastructure from different places? Did you think about log uploads or central crash prevention system? How do you run these tests from different places?

No additional draw back with remote testing.

No matter how you test, the software is still tested in a non-scaled fashion, i.e. it is tested locally to the group that oversees testing. Why is that? Sadly, the testing has not changed since the 1980s. Which means, you will be testing the software on the testers Laptop. Or more advanced, multiple testers test it. Or even one step further, the testing is already automated.

Remote testing changes that. It is executing your existing test cases from all locations that you plan to deploy your software to. Just to be clear, almost any modern piece of software has attached some sort of online service.

Your performance is top-notch!

In other words, your functional tests automatically uncovers performance problems, in case they exist. If you have performance tests even better, you can run them from any site as well. Just to confirm that performance is top-notch.

remote testing worldwide

Firstly, every location executes all your tests. Later, your TestResults.io Dashboard, controlls centrally all those tests. Bear in mind, this happens independently,  if you run your tests in China, New Zealand, Switzerland, Brazil, or South Africa nothing changes for you.

Open Portal > select target to run tests > hit execute = DONE!

All you do to execute all tests in all locations: Press “Execute” in your portal, select the targets you want to run your tests on, done! Now, all test reports are all centralized. Moreover, they are easy accessible in your dashboard, as well as, from around the world.

run performance tests from target infrastructure

Everywhere for anywhere at any point of time

Think about all test systems being available at your fingertip from anywhere in the world. You write your test cases locally, upload them to your personal TestResults.io portal and execute them on any given environment. Completely independent of where you or the test environments are.

In short, this is testing for the home-office, for the remote worker and for digital natives a like.

New way of testing: start with Remote Testing today!

For remote testing to work you need to have a de-centralized test execution structure with a centralized control. Which is not easy to setup and maintain with most of today’s test automation tools.

scale indefinitely?