Feature flow

Getting features in the main branch

Most features should follow the path laid out on our project board. This document describes the requirements for features to move between columns of the board. Listing these requirements should reduce the bystander effect for doing code or QA reviews and make it easier for other developers to pick up these tasks. This would enable us to move features quickly from in progress to merged and avoid bottlenecks at either the review or QA stage. The required procedure to merge a feature into main are as follows.

1. Approved Features / Need Refinement → Refined Tasks

  • We are not reinventing the wheel: there is no high-quality library that already has this feature.

  • This issue is “bite-sized” and (only) leaves non-critical implementation details to the developer.

2. In Progress → Review

  • The authors of the ticket have created a pull request.

  • The Checklists for authors in our pull_request_template has been filled in by the authors.

3. Review → QA review

  • The Checklist for code reviewers in our pull_request_template has been filled in by a code reviewer.

4. QA Review → Ready for Merge

  • The Checklist for QA in our pull_request_template has been filled in by a QA reviewer.

5. Ready for merge → Done

The procedures above should guarantee that members of the kat-managers group can merge these features directly. We should actively aim to resolve any discussions about the implementation at stages 1 and 2. It is the responsibility of the authors to bring possible issues to the attention of anyone that might have an opinion about the issue.

Releasing features

Once a release branch has been created with a new set of functionality, it is important that we do a QA review again. This time, the QA has an extended checklist to also guarantee that there is no regression in the more advanced functionality of OpenKAT. Also, we need to assure that there is no regression between the different supported deployments options of OpenKAT.

Environments for the extended QA

  • Clone the source repository and run make reset [Linux and Darwin, perhaps different docker versions and installs]

  • Install the debian packages [On different distro’s: ubuntu 20.04 + 22.04, debian 11 + 12]

  • Install the container images

Ideally we would follow the following QA procedure on each of these environments:

Checklist for QA

  • I confirmed that there are no unintended functional regressions in this branch:

    • I have managed to pass the onboarding flow

    • Objects and Findings are created properly

    • Tasks are created and completed properly

Extended checklist for QA

Checking the UI/UX

  • Turning Boefjes on and off in the KATalogus

  • Create, turn off, and delete Boefjes-settings

  • Perform scans

  • Analyse results

  • Reports (Findings), per object, per report

  • Generating PDF-reports

  • Pagination of several tables

  • Translations

  • Manually starting Boefjes and normalizers

  • Manually adding and deleting objects and Findings

  • Automatic scheduling and starting of Boefjes and normalizers

  • Exporting the object list as JSON and CSV

  • Inspection of task details

  • Inspection of all pages interfaces, including de tree- and graph view of objects

  • UI/UX in general

Checking User/Organization management functionality

  • I can create and delete an organization

  • I can create and delete users

  • I can assign and revoke rights to these users

  • I can reset 2FA

Checking Performance

  • Verify that there is no significant performance regression