Quality Assurance

Overview

Quality Assurance is the Software Team's last line of defense. It is their job to make sure that whatever code we compile and load on to the computers involved in a run is suitable for the job. Due to our limited resources, namely money and time, it is paramount that we avoid failures as they could potentially set us back a lot!

Tasks

There are three main measures to determine the quality of our code base:

1. Correctness - Are we confident that the code does what it's supposed to?
2. Maintainability - Will it be easy for other HYPED members to read, understand and verify the code in the future?
3. Efficiency - Does the code perform in practice?

To ensure the quality of our code, the QA team has the following means:

1. Reading the code: This goes for what's already there as well as the changes that we will be making over the year.
   • Correctness: Are there any obvious flaws? Are the provided tests sufficient?
   • Maintainability: Are there any style guide violations? Is the code too complicated?
   • Efficiency: If there are any dynamic memory allocations, are they truly required? Are the right data structures being used? Is anything being done that would be block the other subsystems from running? (locks, I/O, ...)
2. Talking to the other members: What is it they are trying to achieve?
   • Correctness: Do all projects/sub-teams have the same idea? Maybe the hardware people are expecting different behaviour?
   • Maintainability: Are different projects trying to do the same thing? Maybe this should be handled centrally.
   • Efficiency: Is it feasible on paper? Some rough calculations may be helpful here.
3. Continuous Integration (CI): We can run checks on every commit to verify that everything works correctly.
4. Researching large modificaitons: Would a certain systematic changes improve the code? If so, how long would it take to implement? What are the drawbacks?

Fundamentally, it is the Quality Assurance Project's job to put the finger where it hurts.

Here are two fundamental rules that every contribution should follow:

1. If it's not documented, it doesn't exist.
2. If it's not tested, it doesn't work.

Code owned

1. Utilites and core. I.e. all C++ that does not belong to another project.
2. Configuration files
3. CI