Test Environments: Do You Have Them?

🗄️ Archive
1

I’ve started seeing a lot more discussions pop up recently about test environments. It got me thinking do you have dedicated test environments?

If so, what is the setup? Do you test locally and push to production? Test in production? Or something else?

1 Like
2

Have worked on both extremes:

  1. Too many environments: Environment for each individual, a squad, per feature, sprint, non-prod, prod (i.e. completely abusing infrastructure as code) - (automated tests could be run in all environments)

Advantages:

  • build quick POCs and prototypes
  • Robust infrastructure (as a code)
  • In a very complex project with third party vendor apps, we can integrate different apps of the project in stages
  1. Two (just enough) environments: non-production and production (Automation tests in non-production, and smoke/any remaining manual test in production). It does need a careful implementation of feature toggling option

Advantages:

  • Avoids ‘merge hell’ (merging / integrating different branches/environments together before production)
  • Because of feature toggling, Once SME tested in prod, feature can be just switched ON to percentage or all users in seconds
  • fastest time to prod
  • superfast bug fixes
  • Overall happy customers

What you need for option 2:

  • Good implementation of feature toggling service
  • Breaking complex changes down to small shipable features
  • Team/managements buy in
  • Strategy for data and user management in production (e.g. dummy test data for testing, dummy users/accounts)
  • careful planning for complex projects with multiple in-house/third-party apps support.
2 Likes
3

It is utmost important to have test environment.

You should never test locally and push to production except it is a
single developer application and a very small application.

If your team of developers is more you will need a integrated test
environment as well as user acceptance test. Large organisations will
have two test environments, but smaller teams can do with one test
environment before the code is pushed into production. This helps in
keeping the issues out with bugs on production.

The size of the test environment is significantly small compared to the
production. as long as you are able to integrate and test the application.

Hope it addresses your query.

1 Like
4

QAppAssure has a test environment with dedicated device cloud attached on which you can push your build and Appium script to execute automation tests. The test result, along with attachments are available for download

The whole test environment works through APIs. You can find more details about the APIs on the website.
To start using the APIs, you need to setup an account with us. We are providing 30 day free trial. You can activate this on QAppAssure

1 Like
5

Partially dedicated test environments. There are 3 test environments shared by about 10 teams, 6 subsystems(internal and external).
I have enough knowledge of most subsystems and their status to understand a strange behavior when I see it. I have enough access in order to build, setup, deploy the build packages and APIs as needed.
I do also test locally features which seem to be decoupled from others or design related adjustments.
In production I do brief checks after release, investigations into users issues through logging system, monitoring and helping support handle problems of the product which are related to other departments, teams, services in the company or outside with some service providers.

2 Likes