Go back to all articles

Testing Environment in the Project Lifecycle

Oct 19, 2021
6 min read

To launch a product, you often need several testing environments. But why? Why pile up equipment, overload engineers with tasks, and hire more staff? Is it really inevitable? We will take a closer look at this problem below, but trust us, it is. We have been providing performance testing services since 2008, and have done it for 300+ customers, so we can’t even count how many testing environments our 400 engineers have set up.

Is the Production Environment Suitable for Running Performance Tests?

Let’s imagine you have a project, a production environment, and the latest version of your product in it. Unfortunately, after the launch or the next release, you would often find some bugs in it. It’s very tempting to launch or release your software as soon as possible, but then the users may notice the bugs, too. Even if you run tests in the product environment to get rid of the bugs, the mere fact of their existence can repel the users. And if the bugs are critical, those users may as well just leave you: afterall, who needs a product that doesn’t perform the tasks it was designed for? An example would be an app providing bank card services, but instead of current account balance it shows users the balance from 2 hours ago. Unacceptable, right?

Even if testers do find these bugs and errors before the users see them, it will take time to fix the bugs and reupload the app. While reuploading, the services will be unavailable. And you are in a trap: your customers are leaving you while all you are doing is trying to improve your product for their convenience.

Do You Want to Load Test Your Product?
Drop us a line to find out what our team can do for you.

Different Environments for Different Teams

What kinds of environments are there? Why is a separate environment necessary for every kind of test? The types of testing environments include:

  • -dev – for testing by developers;
  • -test – for testing by testers;
  • -pre-prod – for integration testing, installation testing and business testing.

You can have several environments of each type. For instance, you may need different environments for functional and load testing, or several dev environments for different lines of development. The number varies and is usually from 4 to 20 per project.

The work starts in the dev environment, where they can test different functions and whether software works at all after the updates or has crashed because of some new feature they added.

If it does work after the updates, proceed by taking it to the test environment. There, testing engineers can look into business processes in detail and find errors and minor defects that developers should continue working with. Every function is tested separately.

Afterwards, it’s the turn of the pre-production environment. Here, you test  system deployment and run integration tests. Separate improvements of different features are united into a big update, which is mounted over the previous version of software. Then, check how the connected systems work.

If your application is rather heavy and/or complex, and if the number of your end users is rather big, you should also run load testing. Most probably, it will need a separate environment of its own. Load testing is quite a process, and it is crucially important that other teams’ processes won’t have any impact on it. Don’t use developers’ environment for load testing: errors may occur and prevent you from running the tests correctly. You will also steal time from them, since they need their environment to test updates, while load testing should be run on the latest version of the product.

The same goes for the tester’s environment: their work can create additional load, which can compromise your tests results, or otherwise your tests may interfere with their tests.

For example
Applications can work slower under stress load. Testers will lose time, since every test case will take more time than normally. If you run your load testing after functional testing instead of simultaneously, the functional testers’ team will have nothing to do in the meantime. They could be testing the next release, but since their environment is occupied, the team is idle. This kind of process is far from optimal.

How to Create a Separate Environment?

If each team needs its own environment, it makes a minimum of 4 environments total: for developers, test engineers, load testers and management. What steps are needed to create them, then?

Step 1. Analyze the requirements to the environment, and calculate the configuration.

First of all, analyze access patterns to the site’s internal servers. It is important for the environment to be closed, so that it does not influence other environments.

Then, analyze the requirements to the environment, and calculate the configuration. Write down why you need your environment to be as similar to production as possible, how to make it this way, and what characteristics should be kept in mind.

If some particular functions do not require the capacities of prod to be tested, these environments may be made with smaller capacities, but generally, architecture should mirror that of production. Specifically, the load testing environment should be at least 70% of the production environment. If you make it less productive, the results of the tests will be very uneasy to extrapolate, since the load will be different.

Let us give you an example. Say, there is a problem in the production environment. Some operations take too long to be executed. If you run load tests in an environment that only makes 50% of the production capacity, you can crash into the wall of capacity limitations in CPU or RAM of application servers. But in production they may work well, so the problem might in fact be in the DB that is too slow to process so many queries. A weaker environment does not allow to apply the necessary level of load, so it would be impossible to find the source of the problem.

Step 2. Choose between hardware and cloud.

This is an essential issue, since an environment with large capacities is quite expensive. Both solutions have their pros and cons. To make your choice, consider the following issues: urgency, utility, affordability, and availability.

  • Urgency is about how soon you need your environment. In bigger enterprises, it usually takes a lot of time to negotiate acquisition of servers. Tendering also takes time, as does the procurement process itself. Then it is necessary to find a place for your environments, assemble them and appoint a supervising team.
  • Utility is all about a possibility to use this environment in the future. If you are expecting your product to grow, will you be able to keep using hardware servers for this or another product? If you are not so sure, cloud should be your choice.
  • As for affordability, consider how much money you can spare right now. If you can’t afford hardware servers, try a cloud-based solution with a monthly plan.
  • Availability is a parameter that considers if you need physical access to your servers. If you are planning on customizing them, it’s easier to do so in your own office. A cloud-based environment is often uneasy to locate, and it does not guarantee you 24/7 access to the premises. In case of an emergency or an accident it is also easier to reach the servers on your own territory with the help of your own team. The cloud is usually 99% safe, but still not 100%.

Step 3. Configure network and access parameters.

As we mentioned above, each team should have their own access to the testing environment, and their environments should be placed into closed subnets. There was a legendary story once: while testing a stock exchange, a performance testing team was interrupted by a group of Special Forces fighters. They were interested to find out who had bought 70 pounds of gold. The testing environment and the production environment were interconnected, access parameters were configured in a wrong way, so when testing the purchase of gold, the engineers had literally done a real purchase.

Step 4. Configure the processes in the testing environment

What you have left to do is assigning a team and thinking about some standard procedures, such as automation of the version assembly, or setting up and restarting the environment. Plan the release cycle and add time for development, functional testing, load testing and integration testing. Then, just follow this roadmap, while also backing up DBs in your testing environments in time.

Have a Project in Mind?​
We have been working on performance testing projects since 2008.
Drop us a line to find out what our team can do for you.
Get a quote You’ll hear back from our tech account manager in one day if not sooner


Without organizing your release cycles around load testing service, new releases may become a weak spot in the organization of the project. Load testing is quite important in this cycle, and in the absence of an environment as similar to prod as possible, it can bring controversial or faulty results and threaten your product’s success.

Table of contents
Let us know about your needs
We can provide multiple performance testing services and a lot more than that if the situation needs a far more complex approach.
Get a quote You’ll hear back from our tech account manager in one day if not sooner

Related insights in blog articles

Explore what we’ve learned from these experiences
8 min read

Why Load Testing Is Essential for Ecommerce Businesses

why load testing is essential for ecommerce businesses preview
May 17, 2024

The success of 26 million online retailers depends on the page load time. It significantly impacts the profitability of online services and sales, as customers don’t want to wait over three seconds to make a purchase. To ensure the desired speed, load testing is widely applied. Common Ecommerce Problems That Can Be Solved with Load […]

8 min read

Everything You Should Know about Performance Testing of Microservices

everything you should know about testing microservices preview
May 2, 2024

About 85% of enterprise businesses use microservices. In this article, we will cover the primary specifics of microservices, explain why they need performance testing, and highlight how to make this process efficient. Microservices in a Few Words Microservices (or microservices architecture) refers to a methodology for developing and deploying applications. This approach separates an extensive […]

4 min read

PFLB is Now SOC2 Compliant

pflb is now soc2 compliant preview
Apr 24, 2024

The PFLB team is happy to share the good news. We have passed the SOC 2 compliance accreditation. It means we can assure our clients that our cooperation will be entirely secure. What Is SOC? Introduced by the American Institute of CPAs (AICPA), SOC, or Service Organization Control, is a cybersecurity series of reports made […]

11 min read

How Do Businesses Benefit from Frontend Performance Testing?

how do businesses benefit from frontend performance testing preview
Apr 15, 2024

Crucial bottlenecks are usually backend-related. That’s  why backend performance testing is generally regarded as a must. However, only 1% of companies perform frontend performance testing. They don’t consider that to achieve the best business results, one should combine the two types.  Let’s prove it. We will define their differences, emphasize the importance of conducting backend […]

  • Be the first one to know

    We’ll send you a monthly e-mail with all the useful insights that we will have found and analyzed