Baselining--Stress Testing--Performance Testing--Oh My--Part One--Environments

Baselining--Stress Testing--Performance Testing--OH MY--Part One--Environments. by Barry Koplowitz.

This article is available as a podcast on "The ROOT Cause" podcast series available at iTunes.

This is the first article of a series of two and lays out where you test--not the details of how. The second article is, "Baselining--Stress Testing--Performance Testing--Oh My--Part Two--Differences." It drills down in the goals and processes of the various types of testing strategies--not where they are done.

What testing environments does your organization maintain? DEV, QA, UAT, Parallel Production? There is great variation in the way different organizations use and design these environments. Some are more useful than others.

TESTING ENVIRONMENTS

DEV: This is just for developers and very seldom sees Application Profiling or Stress Testing. But, why not? Wouldn't it benefit developers to see how their code works across a network? It can be a single PC under someone's desk--running services and applications representing all the Tiers of the Production environment, or it can be quite robust.

QA: This is not really the best environment for clients, end-users or business users to do Acceptance Testing. Nevertheless, it is very common for it be used that way. This is where code that has been tested in DEV goes to be tested by other teams--vigorously. It most certainly should be Stress Tested and fully analyzed by Application Profiling at this point.

While there may be different levels of QA, this environment is often too small. In order to be most useful in its role of anticipating the applications performance in PROD, it needs to be large enough to simulate such an environment. Consider making it a SCALED down version of PROD. I mean that literally. If it were a copy of PROD, more or less to scale--its performance would be much more transferable to a PROD reality. It is unlikely to be the same size--but can it be one quarter the size? How about one tenth? The size is less important than having a consistent ratio--keeping it to scale so that metrics are convertible.

Another Best Practice in the QA environment is to use production data wherever possible. Since no clients ever use it (see UAT), and it mirrors the security offered by PROD (I hope), this may be done safely. Then the Databases have the same characteristics--keeping the outcome closer to reality.

UAT (User Acceptance Testing): Where clients, end users and business users can go to test functionality and acceptability of the code. Unfortunately, this role is too often seen performed in the QA environment. However, with a dedicated UAT Environment, you can present clean information in an environment that is not subject to the same "slings and arrows" that are thrown at QA. Here the Client can do what they want. The goal for them here is to test functionality, not load. However, if they want to test load, they can do so. Therefore, it is best to build this environment to scale as well. Nevertheless, the ratios can be such that the UAT environment is smaller than QA. What matters most is that it function as close to PROD as possible.

PARALLEL PRODUCTION: This is a very valuable subset environment of UAT. Here we set up a "ready for prime time" version. It runs on PROD hardware in PROD networks, but in UAT volumes or other forms of segregation. The goal is to see how close to reality you can get using as much production equipment and environment as possible--without breaking PROD. It's not as difficult or dangerous as it sounds when planned out well and can save MILLIONS of DOLLARS in lost time and productivity--not to mention careers.

Here is how this works. You have volumes and directories on your non-prod servers. Create new and comparable volumes and directories on the same PROD servers that you plan on using for the application and put the data there. It is now running on a the PROD box--but not completely in the PROD environment.

Yes--there are issues with DNS and other such things, but they can be worked out for a set of Test Users. Remember, this is going LIVE very soon. Don't you want to find out what will happen with a way to rollback easily? This is NOT an alternative to UAT or QA. It happens after the application has passed all of those tests. It is an alternative to going straight into PROD. If you have sufficient doubts about the application or configuration, so that a Parallel Production test seems scary--you shouldn't be planning on going live yet. This is an additional step--it does not replace anything. Well, it does replace going straight from UAT to PROD--but that is a good thing.

Article Source: http://www.contentspool.com

Barry Koplowitz founded Interpath Technologies Corporation in 1999. He was an instructor for Network General and NAI traveling around the USA teaching for Sniffer University and is a executive consultant to large enterprise environments in the area of Processes-Network/Application Analysis and Troubleshooting. He is the writer and host of The ROOT Cause podcast. www.interpathtech.com

Please Rate this Article

5 out of 54 out of 53 out of 52 out of 51 out of 5 

Not yet Rated