Test matrix fundamentals

Story points: 8 SP
Estimated focus duration (perfect conditions): 7 days
Estimated pessimistic duration (worst case scenario): 12 days

Description

Click to expand Following nunet-infra#209 (closed), the work package architecture#208 (closed) was created, tracking the scope of the CICD pipeline deliverables. This issue consolidates the work breakdown for the first deliverable, which is the Test matrix definition in terms of visibility and stages.

The repository https://gitlab.com/nunet/test-suite documents the definition of the stages and environment in relation to the test matrix. This work aims to bring those definitions in the context of the CICD pipeline to answer the following questions:

  1. When should each environment be triggered?
  2. Which stages should be triggered in each environment?
  3. How can we visualize progress and failures for each stage in different platforms?
  4. Where should each stage be implemented, and how can we clearly see which stages are implemented and which are not?

Note: it might be that many steps and actions defined here are already being done or already implemented. This isn't supposed to be a re-implementation of those, but it should integrate them in the broader context of the pipeline so that the foundation is solid.

Who

  1. @gabriel.chamon
  2. @olakunle.oladimeji -- interested party - currently developing security stages in this repository

What

  1. Implement full visibility for defined stages on all platforms (defectdojo, testmo, gitlab).

How

  • Each report should have its own report visible for the developers

Why

  1. This builds a foundation for the entire process, end-to-end, for the code delivery pipeline, which will help us maintain a clear project structure and estimate

When

Acceptance Criteria

Click to expand

Work Breakdown Structure (WBS)

OBSOLETE

Task Description Duration Status Start Date End Date Comment
1 Read the test-suite thoroughly 2024-04-03
2 Add visibility to static reports by generating and publishing HTML artifacts
3 Document implemented pipeline behavior

Work done is tracked in two merge requests:

The work done in the second merge request expands upon the work done in the first merge requests and they should be reviewed in this order.

Edited by Gabriel Chamon