Quality Management

Summary

Todo

quick overview Quality Assurance vs. Control

Quality Assurance

Coding Guidelines

Todo

general Clean Code guidelines and Code documentation. Every Team should agree on Coding Styles

Issue Tracking

Important Sources: * Cheatsheet: provides a short and concise overview over Issue Tracking and Git Flow.

Issue Tracking provides a frame for developers to be productive while keeping the overview over several tasks. Therefore, we separate the development phase in several steps. These are depicted roughly in the following flowchart.

Issue Workflow

When an issue is opened and it is roughly specified, it can be either of Type: Suggestion or Open. If the issue has been specified, assign step: ready to your issue. If you fill some of the issue templates, it is likely that these issues are specified. As a consequence, templates such as feature request or bug report assign step: ready automatically. If you do not want that, you have to remove that lable from the /label line which ads the default labels. When an issue is planned for the current sprint, the issue can be moved from step: ready to step: current sprint. The attentive observer recognizes that we are now in the sprint phase. If you start to work on an issue, move the issue to step: in progress. If you advance in the resolution of the issue, assign the respective state labels:

  • state: implemented : implementation completed

  • state: tested : all tests for the new implementation have been added, respectively, existing ones have been adapted

  • state: documented : the changes have been documented. This does include code comments, but may also include to update the Sphinx documentation, an API documentation, or similar.

When you are done with your implementation, move the issue into step: in review. When an issue is in the review phase, there is a small task cycle between reviewer and developer. The reviewer gives feedback which is evaluated and implemented by the developer. This is continued until the reviewer accepts the implementation. If an implementation has severe problems, the reviewer can decline the implementation by assigning the label state: rejected. Severe problems can be:

  • wrong implementations, e.g. if a developer misunderstood the issue

  • rough weak points in the implementation, e.g. missing authentication when requesting personal data

  • weak implementation, e.g. use of deprecated methods, very bad code styles.

In such cases, the developer team must revise the issue. If the problem can be solved, e.g. by clarifying the issue or training the responsible developer in the technology in use, move the issue back to ready. If the problem cannot be solved, close the issue and add a comment which describes the reasons for rejecting the issue.

Let’s continue the case, that the review was successfully accepted. Then, the reviewer approves the merge request. Then, the reviewer or the developer merge the feature branch onto the respective target branch. When the merge is successfully completed, the issue is moved into step: done. After the sprint retrospective, where each team should reflect its work on an issue, the issue shall be closed.

Note

The action ‘move’ describes that the label for a previous step is removed and the one for the next step is added. Hence, we recommend to use the issue boards (e.g. ‘Sprint’) for that action.

GitFlow

Here you can find a short and concise overview over the IssueTracking and Gitlow.

Todo

about GitFlow with link to cheatsheet

Documentation

Todo

about project documentation with sphinx

Quality Control

Software Testing

Todo

about Testing

OLD

Process Specifications

All process-related aspects should be documented here. This includes Specifications about git-branching, commit-message-templates, issue-templates, Merge Request Reviews etc.

Continous-Integration und Deployment

Terminology:

Continous Integration describes the practice of frequently integrating new features into the application, so that conflicts between changes are instantly recognized and can be rectified before major damage occurs. This includes both the “mergeability” of the code bases as well as automatic integration tests to verify that the system still works as specified.

Continuous delivery and continuous deployment are both describing the automatic generation and publication of builds after changes are merged and have passed continuous integration. In Continuous Delivery, the release must be manually triggered, but then it runs automatically, whereas in Continuous Deployment, the release is made automatically as soon as you merge to a certain branch.

See further explanation here

In the UniApp project(s), we strive to apply all three techniques where sensible.

Continuous integration is applied by the Gitlab CI system - every commit is automatically tested (Unit Tests and Integration Tests). Commits are merged after a Merge Request has been code reviewed. Continuous delivery (= manual trigger for automatic deployment) will be used for the production backend system (with versioning) and the beta and production branches of the apps Continuous deployment (= fully automatic deployment on merge) is employed for the Backend when merging to Alpha and Beta branches. (Later: Do Continuous Delivery when merging the apps to Alpha branches)

Test-Setup

This section documents the general test setup, or describes which aspects such as testing.

Unit tests

(with which frameworks? On which components?)

This section features testing in Android. This is divided into unit tests and ui tests. For unit tests, we mostly use mockito. For ui tests, we use the espresso framework and dagger mocking.

Android Unit Testing

Here you find a guide for the Android

IOS Unit Testing

Here you find a guide for the IOS

REST-API tests

(with which data?)

UI Tests

Android UI Testing

Here you find a guide for the Android

IOS UI Testing

Here you find a guide for the IOS

Also a description of how test cases are created on the different levels or where templates/examples can be found is helpful.