Engineering

How to improve technical skills as a mobile app tester (Part 2)

Welcome to the second part of my article. [The first part] (https://appunite.com/blog/how-to-improve-technical-skills-as-a-mobile-app-tester) described various steps of learning to mock application data in code during manual testing. This part will cover the first two points from my previous article in more details - learning to use a terminal, getting to know commands, Git workflow and the related tool - GitLab. The content in this article is universal because both things are used when testing any mobile platform.

Step 1 - using terminal + commands

Command-line

The first basic step is to learn how to use the tools needed to build the project, since not all of them have a graphical interface. To do this, it's a good idea to start by learning the command line.

MacOS comes with a program called terminal. Using it can be clumsy and uncomfortable for beginners. However, there is an alternative in the form of iTerm, which is an equivalent of the macOS terminal. It has built-in auto-complete functionality, tooltips and is easily configurable, allowing you to add plugins to make your work easier.

Both tools - terminal and iTerm - allow you to interact with system tools that are necessary to build a project, as well as manage the code repository. This tool provides a text interface for entering commands and so the first key step is to become familiar with Git commands.

Terminal and Git commands

The commands that you should learn at first and will use most of the time are:

Terminals:

  • pwd - show current location
  • ls - show files in current location
  • cd <folder_name> - navigate to the folder with the specified name
  • open <file_name> - open file
  • cd .. - go back to the previous folder (lower level)
  • mkdir <folder_name> - create a folder

Gits:

  • git clone <url> - cloning a repository to a folder
  • git fetch - updating the repository with the server
  • git pull - downloading the latest changes from the current branch
  • git status - status of the current branch, shows the changes made
  • git stash - withdraw the current changes and save them to the working directory
  • git stash pop - recovering changes from a draft version
  • git clean -fd - deleting current changes irreversibly
  • git checkout <branch_name> - change of branch (change will not succeed if there are currently any changes)

Here is a simple and practical task to introduce the “world” of the terminal: opening any file on the desktop using the terminal.

Type the commands in the console:

  1. pwd
  2. ls
  3. cd <folder_name> - in this case the folder name can be “Desktop”
  4. again, it's worth typing "ls" to see what files are on the desktop
  5. open <file_name> - if the filename contains spaces, you must use them instead \, so you type e.g. open home\ home.jpg

Result: the photo on the desktop opens

When using iTerm, you can use the prompts. After typing any command, e.g. “cd” and then selecting tab, the following prompts are displayed. Navigating through the prompts to select them uses tab and confirms with enter.

An alternative to using a Git terminal, is to use a tool such as Sourcetree, but for some projects, command-line skills will be necessary.

Step 2 - getting to know the rules and the Git repository

Git rules

The next step that comes naturally is learning the rules of Git. You can visualize it by comparing the versioning process during one sprint with, for example, the stages of creating floors while building a block of flats.

  1. Work on the building starts on the ground floor. When developing an application, the first step is to push the changes made to the code to a branch called FEATURE or FEAT. By this name, you know that it is a version in which work on a particular feature is in progress. Once it is finished, it is pushed to the develop branch where it is ready for testing.

  2. The second stage of work in the block shown is the 1st floor, where the last improvements are made. It can be compared to pushing changes to a branch called FIX. Then you know that the branch is working on a fix for a feature or bug. After the fix is done, the version lands on the develop branch and is ready for testing.

  3. The next phase of work is the 2nd floor, which is finished and turned in for review. In the software development process, the place where the version with a set of features and fixes is ready for staging tests is the DEVELOP branch. When it is tested and the test results are positive, it goes to the branch release and is ready for testing on the production environment.

  4. In the picture, the third floor is ready and approved by investors. In the process of releasing versions of the application, this stage will mirror the version on production that is on the RELEASE branch. When a given version containing all the features and fixes passes the acceptance tests it is ready to be released to the store (the so-called Release Candidate). However, during testing, you may find that adjustments need to be made. Then the fixes are pushed to the release branch, and it is then merged to develop. The final (tested) version is merged onto the master so it can be released to the store.

  5. People use the fourth floor just like they use an app downloaded from the store. The version that is in the store is on the MASTER branch.

  6. The last floor refers to any repairs during use. When an app is in the store and you find that there is a critical bug that prevents you from using it, you need to fix it as soon as possible. Corrections to this version are pushed to the HOTFIX branch. After testing, a version from this branch usually goes straight to the store and later is released on the master branch for consistency.

Managing a Git repository

There are several platforms used to host a Git repository. In this article, GitLab will be used as an example. It allows us to see a lot of useful information for the tester. Such as: development progress and version numbers, which contain features and fixes that are especially necessary to build the version locally so that it can be tested before releasing it on the test environment. In the pictures below the places where this information is located are marked and described.

Summary:

And now I can warmly invite you to part 3 of the article, especially if you are interested in the iOS platform. It will include practical examples of how knowledge of Git and the command line can make mobile app testing more efficient, and how to navigate and test in Xcode.