Guides

Guides is the best source of information if you are interested in the technical details how our engineering team delivers quality software.

Manual testing

Data naming

Use only appropriate naming for test data.

Environments

For web apps, we usually have the following environments:

  • Staging. This is the “pre-release” environment. New features are deployed to this environment. Manual testing is usually performed in this environment. The integration branch (testing) is automatically deployed to the staging environment.
  • Staging2. This environment is usually used to test communication between two environments. For example, Staging is the main server and Staging2 is an additional server.
  • Production. Manual testing is never performed in the production environment unless someone explicitly requires to “check some feature on production”.
  • Local environment. Used for testing the feature while developing. Additionally, there might be a need to change the server time, in such cases, it is easiest to test the feature by running the application server locally.

Platforms

The client usually specifies which platforms the application must support. If this is not specified, here is a set of most the popular browsers (desktop and mobile) which should be supported.

Browsers

Desktop

  • Microsoft Edge and Internet Explorer 11 (Windows)
  • Firefox (Ubuntu, Windows, and MacOS)
  • Chrome (Ubuntu, Windows, and MacOS)
  • Safari (MacOS)

Tip: We use virtual machines to run Microsoft Edge and different versions of Internet explorer. They are openly distributed by Microsoft.

Mobile and Tablets

  • Chrome (iOS and Android)
  • Safari (iOS)

Native

Native applications and web applications are, usually, created as separate projects. This means that new features might not be implemented at the same time for the native application and the web application. Also, the features might be platform specific or the requirements might be different than those of the web application.

Native applications behave differently from web applications. For example, an iPad device is much more often rotated than the monitor of the computer. This implies that every view of the native application must be specifically designed to fit on the screen regardless of the device’s orientation.

When manually testing the native applications, it is important to:

  • Test the device orientation - switch from horizontal to vertical and vice-versa for every feature to check if the layout fits into the screen and the view is re-created as expected.
  • Test production app data against the new version of the application.
  • Test iOS applications in the multitasking mode

Integrations

Some web applications may provide some features for 3rd party applications via an “API integration”.

  • It is best to test the actual integration as a user of this 3rd party application and not the API endpoints themselves to ensure that everything works for the end-user. Use Postman if credentials for the integration are not presented and it is not possible to create them.
  • It is suggested to create high volumes of data in the 3rd party application to check for bottlenecks in the API integration.

A task might run only on midnight. In such cases, either:

  • wait for the task to run by itself - on the staging environment, create the required conditions for the task to operate on some data, check the test result the next day to confirm the correctness. This method is non-intrusive and is suggested to use as often as possible unless the event happens rarely (task runs once a bi-weekly).
  • run the task manually via the server console - on the staging environment, create the required conditions for the task to operate on some data, run the task and check the result to confirm correctness. This method is intrusive and may behave unexpectedly in some cases. For example, the task may create additional data which happens only if the task is executed more than once a day.

In other cases, you might need to change the current time of the platform in which the application is running (may it be back-end or front-end) to create the necessary conditions for the test:

  • If the front-end depends on the user’s time - change the computer time and test on staging.
  • If the feature depends on the time in the back-end - change the computer time and run the server locally, or change the server time using Timecop, for example, Timecop.travel(2017, 3, 23).