What is the test environment?

 The test environment is a collection of hardware and software, which helps us to execute the test cases.

Once we get the requirement from the customer, the developer starts developing the code.

When the coding phase is completed, the application should be installed in the test server. And that application can be accessible with the help of the URL, and the URL could be like this:

HTTP://COMPUTER NAME/PROJECT/COMPANY NAME

Suppose we have the ICICE Server, which has been configured with software, hardware, database, and the application.

• The test environment has a software configuration (operating systems), hardware configuration (RAM, Hard Disk, and Processor), and the test console, which help us to execute the test cases.
• The environment setting is an important part of the testing process because if it is not set correctly, the testing team cannot start the testing process, and the application might be collapse.
• And the Production URL could be the name of a server such as ICICE.com, and the environment.
• The database is secured; that's why we can use it to create, modify, and delete the data.
• This server can be used by n-number of the end-users (real user).

Software server

Here, we have four types of servers, which are as follows:

• Production server
• Development server
• QA Main server
• Staging server

Production Server

The server, which consists of software, hardware, and the application development environment, is known as the production server. It is a core server in which the users access any web application or website.

The production server configuration is similar to the staging server, and the application should be debugged and tested on the staging server before dumped into the production server.

Features of the production server

• The end-user or real user use this server.
• Security is given to the production server since it contains real user data.
• Highly configured system since it is used by n-number of users.
• The production URL accesses the production server.
• Once the application is developed/tested/stable, then it is deployed into the production environment.

Development server

Generally, it is accessed by developers for writing new lines of code as well as bug fixes. The dev server gives a run-time environment where the program developed and debugged.

QA Main server

The test engineers access it for conducting all the types of testing and also obtain by developers for reproducing the bugs. In this server, we will perform the unit and integration testing.

Test (Staging) server

We take another server to check the compatibility of the server because the production server is highly configured, so we need a similar server where we can perform the system testing.

Checking the application compatibility bugs is known as a staging server.

This server helps us to identify the software performance, behavior, bugs, and other issues before the application is deployed into the production server.

Process of test environment

• Once the requirement is given by the customer and developers finish the coding, we start the initial round of testing on the test server like functional/unit, integration testing with having normal configuration.
• Here, all the servers software should be the same, but the hardware and the database are similar to the production server and the staging server.
• For the system testing, we need a highly configured server, which is similar to the production server (similarity to the software and hardware and database) that is called the Staging server.
• In the staging server, we are using the test URL and perform the system testing.
• If we find any bug, we will be handed over to the developers, and they will fix the bug, and it will directly store in the staging test server.

• In a company, we will use only two environments, which are as follows:
  • Developer environment
  • Testing environment
• In the testing process, we will move to the database from QA Main 1 to the Staging server to save time, instead of creating a new one using the already existing dev database.
• And then move the application from the test server (staging server) to the Production server.

Note:
Production Issues: These issues can happen in the production site in real-time where end users are using the application.

Why test environment similar to the production server?

Since, if we move the application from low configuration to the production, the user may find some issues. To avoid this, we do one round off end to end (system) testing on an environment, which is similar to the production environment.

Following are the aspects which shows why we need the test environment similar to the production server:

The software should be similar to the production

• The database server should be similar
• The operating system should be similar
• The web server should be similar
• The application server should be similar

The hardware should be similar to the production

• The hardware configuration should be similar to the production server

For example: if the production server is the ICICE, then the test server should also be the ICICE server.

• The configuration and hardware must be similar but different capacities, i.e., the number of CPUs.

The data should be similar to the production

• We should create a data, which is similar to the production.
• In the real-time environment, we may make n-numbers of entries into the database, but while testing, we cannot enter n-numbers of entries manually. So, we write a test script that makes thousands of entries, which can be used for testing.

Note:

• Can we work on the one common server for the development and testing team?
  No, because there are no continuous tasks, and the developer silently change the code if we have the common server.
  
• When the developer reproduce the bug, and in which server, test server or development server?
  • Where the bug is found, it can only be reproduced there (test server, founded bug).
  • If we do this on the developer server, it is possible that some other developers can change the code, so the good approach is to reproduce the bug only on the test server.
  • The Application is always moved from the test server to the production server 569because the developer can change the code at any time.
  • But, in the test server, the people can't access the code, as we always transfer the application from the test server to the production server.
• Does the URL only gives access to the application which has to be tested?
  • When the customer needs to change or give the new requirement for the application, it will give it to a particular company.
  • After getting the requirement, the development team creates one separate server and use the developer URL to run the application.
  • Once the application is ready, it will hand over to the test engineer, and the test engineer will test the application using the test URL, which can be used only in a particular company.
• While we are using a URL, we can only give access to the application from the server or the frontend of the application.
  
  • The customer wants an application, then he/she goes to Software Company and gives the requirements; the company provides a requirement for the developer to develop the code in the development server.
  • After completing the code, the application is installed in the test server so that the test engineer will test the application until the application is stable then it will be deployed into the production server.
• Can we change the requirements into two servers?
  • The test engineer and developer can't change anything when the application is in the production server because they may have changed the requirement on the dev server and test server.