"Please ask the team leader via the test chat if the scope of the environment is unclear to you and avoid making assumptions."
Table of contents
The creation of multiple environments is a common practice among software developers. The idea is to create two (or more) independent versions of the app or website so you can use one without affecting the other. Usually, the most common environments are called Production environments (which can also be called Live environments) and Staging environments (also called Pre-production or Test environments). Still, each customer can set their own names for their multiple environments. In this article, we'll help you identify which type of environment you're working on and its main characteristics.
How do I find the environment I should test on
The environment will always be provided by the customer under the Access section on your test overview page. It can be a website or a link to access the app download page. To avoid testing the wrong environment, always access the customer product via the link provided in the instructions and never try to guess the environment based only on the title of the cycle.
Once you access the environment, you must pay attention to the domain to avoid accessing areas outside of the scope of the test. If the domain of the website changes while you navigate through the website, you are in fact testing a different website, even if its name or design is similar. Unless stated otherwise, this other website is not in scope and must not be tested. For example, if the URL mentioned in the Access section is https://test.io and while navigating you end up on the website https://epam.com/testio, the domain clearly changed, so you are visiting a section that is out of the scope of the cycle you should navigate back to the correct domain immediately.
When you navigate around and you land on a page that is on a subdomain, this can also mean that you left the test environment. For our example, https://test.io has multiple subdomains such as https://app.test.io or https://academy.test.io. Bear in mind that paths (appended to the end of the URL such as https://test.io/services or https://test.io/crowdtesting) are not subdomains, so you can test the page safely if there's a feature enabled for it, unless stated otherwise in the instructions.
Finally, for mobile apps, some pages might be opened on what we called an integrated Web Viewer. Those are built-in tools that allow users to view web content (such as webpages) inside the app without the need for a third-party browser. Even if the page shown inside the app is part of the customer ecosystem, sometimes the team who develops the app is not the same one that develops those websites. Hence, those pages might be out of the scope of the cycle as well.
In any case, please ask the Team Leader via the test Chat if the scope of the environment is unclear to you and avoid making assumptions.
The Environment Setup and Scope
Once you identified the test environment, you must look for the extra information left by the customer about it. Some customers will allow you to freely test their apps, while others will impose some limitations on the actions you can do on the environment. Therefore, note the following general scope limitations:
Don't trigger orders. Stop testing before the end of the checkout process, which includes accessing any third-party payment page.
Don't submit data or content, e.g. support requests, product reviews, or comments. Submitting data will otherwise require clean-ups by our customers or it will even be visible to real users of their products.
Don't interact with our customers, e.g. via support chat, phone, or email.
Don't interact with other real-world users, e.g. sending friend requests or messages to them.
DO NOT test any of such functionalities unless stated differently in the test instructions. If you're not sure and want to avoid rejections and other penalties, the best way is to ask for the Team Leader's help via the Test Chat.
To help you with your tests, we'll identify two of the most common test environments created by our customers in the following sections.
Live environments are operational products, the same version and build real-world users are currently using. Companies can lose customers and revenue through bugs in live environments. Therefore, bugs on live websites or apps are normally more relevant than on websites that are not published yet.
To avoid affecting the experience of the users, customers will usually restrict you from freely testing the website. Hence, it is really important that you read the cycle instructions carefully and do not perform any action that may be seen by other users (e.g. the ones described in the section The Environment Setup and Scope).
Live apps are released products and usually will be available on the official App Store of your device. For websites, you must access the production environment via the link provided by the customer in the Access section of the test instructions. Keep in mind customers might have hidden developer tools integrated into their live products, so it's important to follow the cycle instructions and click on the link provided by the customer to make sure you're testing the correct environment.
Staging/Pre-release Website Environments
A staging environment is typically an environment created for testing purposes. It will usually replicate the functionalities and the interface of the Live environment plus the latest modifications applied by the development team. While the domain of a Staging Site is usually the same as the domain of the live website, the staging site runs on a subdomain of the site. As staging environments are usually not accessible to the general public, they will either be accessed through our test IO proxy or after entering credentials that will be provided in the test instructions of your test.
Staging products can still be in the development stage, which is why they can be different from working production environments. They can also be updated while a cycle is active, so you must expect some instabilities while testing the environment.
Content bugs are often out of scope. Content – such as texts, pictures, and links – may be missing or replaced by placeholders. Functional bugs are most relevant here.
Similarly, links may point to the live website instead of the staging website (the subdomain is not included in the URL of such links). Intentional or not, this is a setup problem and not a valid bug.
Beta apps are not released yet and need to be downloaded via the link provided in the Access section of the test instructions. They are usually equivalents of Staging environments for websites. Installing a beta app is not as easy as installing a live app:
iOS beta apps can be distributed via a given Over-the-Air (OTA) link that you need to open on your iOS device, or via TestFlight.
Android beta apps are usually distributed via APK files. Simply click on the given download link on your Android device to download the file to your phone or tablet directly. Locate the file in your Downloads directory, run it, and follow the installation instructions. Alternatively, download the file to any device like your computer, transfer it to your Android device, and repeat the same steps.
Both iOS and Android beta apps can also be distributed via Firebase.
To find out more about installing iOS and Android beta apps on your device, please check our Setting Up Your Workstation article.
If you run into any trouble installing an app, you can contact the Team Leader via the test chat.