My Innovative Solution to Test Automation: Run the same test against a different server with a click of a button

Very helpful on bug fixing.

This is included in the “My Innovative Solution to Test Automation and Continuous Testing” series.

“It worked on my machine” is one of the most popular excuses used by programmers. Programmers like to say that because there are usually several server environments: the issue reported by the tester could be a server infrastructure issue, not code, as it is fine on my local machine.

Table of Contents:
· A typical set of server environments
· The need for running the same test against different servers
· Automated Test Scripts (Selenium) that support multi-servers
  ∘ Run the same test against different servers from the command line
· Set up server environments
· Change the target server environment

It somehow that nearly all software projects agreed on server environments' naming and purposes, even those not taught at universities.

• Local or Development
  on the developer’s local machine.
• Dev
  a trial server for developers freely deploys immature builds.
• Test ( or System Test, or Integration)
  the main server for performing functional testing.
• Staging
  A production-alike environment.
• Production

Besides the software build, there are other differences among those servers, such as configuration, dependent third-party services, database servers and machine specifications. A good software company (such as Google’s engineering productivity team) will keep the differences minimal in terms of functional testing.

The need for running the same test against different servers

After I mastered test automation (End-to-End via UI), the need for quickly verifying a user story against two servers (typically, Local and Test) became obvious. One direct reason is to confirm the defect that the tester found on the Test server. (At that time, I worked as a programmer. I still am, but only coding my own apps). That means, I need to replicate the issue on my local server.