Think different but keep it simple :)

There is content below, I can read can’t you? oh!  Think different to see the content, but keep it simple

This is the most common problem we testers encounter quite often, it works in developer machine but not in test machine.

Once an interesting incident happened in one of the web application I was testing, application was working fine in developer’s environment but not in test environment.

The most likely reasons could be either  the test servers do not have the latest code or  there is conflict in environment. Quick check revealed that both the environments had the same code.

Now the focus was on to investigate the configuration of the servers.

As a tester how will  you investigate such situations?

Few tips to nail down such problems. Please share your tips as well.

1. Test in another test machine\server

2. Test in another dev machine\server

This will help to narrow down if there the problem is at client side or server side.

3. Check if  that machine  is also hosting the web server.

Time out issues and session management related issues may not be reproducible, if the machine you are testing in is a server machine.

4. Check for additional softwares installed.

Generally developer box will have lot of additional softwares installed, like debug tools, development related softwares that may prevent from the bug to be reproduced. Even the web browser in dev box will be loaded with tons of additional tools and utilities. Such additional installation may also prevent from some bugs being reproduced.

It is not enough to check if required softwares were  installed, it is equally important to make sure no additional unwanted softwares were installed.

Coming back to the issue, following those above mentioned approaches by pairing with developer helped to nail down the problem in few hours. The issue was, a bulk data extraction component used (it was ETL project) will work only in localhost, that does not have the capability to connect with external host. In the developer machine and dev server both web server and DB server was hosted  in the same machine, so that worked perfecly fine.But test environment had DB and Web server running in different machine, so this caused the problem. An important lesson learned from the incident is it is always good to have the test environment mimic the production. Keeping the test environment similar to production helped in finding the problem very earlier in the cycle.

Another good practice to follow, at any given time at least one test environment should be  in sync with production server, so any production issues reported can be easily replicated and analysed in a test environment. Having only one test environment means most time that will be updated with enhancements going on, that may also prevent from reproducing production issues because of code changes applied in the test environment.

How many of you have set up the test environments? No, I didn’t mean double clicking an installer provided by the developer. As a tester I learned a lot, by setting up test environment and maintaining it, setting up test environments will help  to understand your application better, it will help to get better test ideas, analyzing of bugs can be done  effectively .

Understanding test environment improves testing.

——————————————————————End of Post—————————————————————————–