Quality Assurance

Basic daily QA- Processes

The work of the Quality Assurance (QA in short) at the AAW project is based on the project management workflow of the development process.
In short the development is based on agile software development methods. There are sprints of different length which end in a so called milestone.

The Github Repository is extended by a tool named ZenHub. It gives the Github the agile touch. All project members must install the ZenHub Browser AddOn to have the appropriate view of the Github project.
The AAW project decided to use the following ZenHub-states, called Pipelines:

• New Issues
• Backlog
• To Do
• In Progress
• Done
• QA - Need Testing
• Closed

Basically the QA greps all issues that were pulled in the "QA - Need Testing" pipeline and tests if the bugs are fixed or the feature is usable without flaws. To achieve this it can be usefull to meat up with either other QA-Members or even the developers if issues have to be clarified or if more men are needed to test the issue. Additionaly the QA can focus an issue at a playtest, to test a bugfix for which many players are needed (e.g. performance isssues). But that is normaly done together with the developers.

To assume the priority of an issue there are several attributes to meassure this:

• The labels: e.g. bug, critical bug, Super Anal, ...
• The milestone: For example: When the bug is normal but it is shortly before a code freeze of a critical milestone or playtest. Then the bugfix should be tested instantly.
• Part of Epic issue: Epic issues are very important issues that normaly consist of other issues. For example you make an Epic issue for a whole new logistic system then you need an (sub-) issue for the handling of crates. This issue should be tested in time and thoroughly by QA if the Epic issue is an important feature for the whole project.

If an issue is finaly tested the QA can decide in which pipeline the issue has to be moved:

• To-Do - if the issue is not solved
• Done - if the issue is done

Normaly the QA can also decide to close the issue if it was a minor bugfix and the bug is 100% gone.

Advanced QA- Processes

According to this document
AAW - Release Process
there are different branches used for development.
If any issue at another branch has to be tested the QA needs the possibility to change the branch of the Arma3 Testserver. To achieve this there exists a Discord-Bot on a Discord-Server which accepts the following commands: list, restart, build, branch, branches, clear

• list - Lists available projects
• restart - Restarts all servers linked to specified project
• build - Pull, build and restart specified project
• branch [branch] - Gets/sets branch of specified project
• branches - Lists branches of specified project
• clear - Clears the channel

So if one e.g. wants to review the branch which includes a new visual language with new symbols etc. you have to do the following:

• Make sure there is no other player on the server.
• Get in the Discord Server to the channel #ci_controll_room
• Type in the command !branches ArmaAtWar
• You get a list of the current existing branches like

[20:29:40.421] Running command: branches
[20:29:40.423] Available branches:
[20:29:40.457] master
[20:29:40.457] PreRelease*
[20:29:40.457] release*
[20:29:40.457] VisualLanguageUpdate*
[20:29:40.457] Command branches complete

• To actually change the branch of the arma testserver to the branch "VisualLanguageUpdate" set the following command: !branch ArmaAtWar VisualLanguageUpdate

• After amongst others you get the message Command branch complete you can verify the branch of the server by typing !branch ArmaAtWar

• QA is now free to test everything in this branch on the testserver.

• After testing don't forget to set the testserver back to the master branch.
  !branch ArmaAtWar master
  After the Bot has completed his task check the branch with
  !branch ArmaAtWar

This is a first version of the QA-Wiki and can change or extend in time...