Skip to content

Use Cases⚓︎

Original Use Cases⚓︎

Here are original Use Cases (from the EOEPCA+ Use Case Definition Document) applying to the Application Quality Building Block.

  • UC71 As a user, I want to access to the logs of my workflow execution, so that I can verify correct function and debug/investigate failures.

  • UC72 As a user, I want an Application Testing Service to performance test the speed of my service, so that I know it is fit for purpose.

  • UC73 As a user, I want Application Testing Service to robustness test the reliability of my service, so that I know it is fit for purpose.

  • UC74 As a user, I want Application Testing Service to access the quality of my code so that I know it is easy to maintain and share with others

Derived Use Cases⚓︎

The following Use Cases elaborate from the original ones and express with further details the expected features from the user perspective.

Note: “As a user” has become “As a developer” hereafter as the Application Quality service is intended to be used by application developers.

[UC71.1] As a developer, I want to be able to access the log traces generated by my applications during their execution in Application Quality pipelines

The actual execution of the developed applications occurs during performance testing. Applications are only executed in that stage. In the other stages, static analysis is performed on the source code, application building and documentation generation are attempted, and unit tests are executed on code fragments.

[UC72.1] As a developer, I want to be able to access performance metrics collected during Application Quality pipelines executions

Performance metrics include the amount of cloud resources (CPU, memory, disks, network traffic) consumed during the application executions.

[UC73.1] As a developer, I want to be able to configure the input values used to test the applications in the Application Quality pipelines

Different sets of input values allow verifying the proper functioning of the applications in different contexts.

[UC74.1] As a developer, I want to select the tools to integrate in Application Quality pipelines depending on my application or service characteristics (e.g. programming language)

Specific tools may not be appropriate in all cases to assess the quality of an application. Also, some tools may only be executed on source code written in specific languages.

So a web application must allow the developers select the tools they want to integrate in their Application Quality pipelines.

This requires:

  • Appropriate tools to be packaged and available for integration in AQ pipelines.

  • A pipeline editor in the web interface that allows selecting the tools to be executed.

Note: This does not need to be as advanced as a workflow editor. It must be closer to a CI/CD pipeline where tools may be organised in “stages”. All the tools located in the same stage are executed independently to each other. Tools located in a “downstream” stage are executed only if all the tools in the previous stages completed successfully.

  • The web interface must allow relating pipelines to selection criteria based on characteristics of the application files or project.

For example, a pipeline may be configured to be executed on an application that contains at least 50% of Python code (this information is provided by GitHub), or an application that contains a certain file (e.g. main.py, or package.json, vue.config.js, etc.)

  • Integration of the web app with the IAM to restrict the access to the pipeline owners.

[UC74.2] As a developer, I want to manually execute Application Quality pipelines on my applications and services

On-demand execution of Application Quality pipelines by applications and services developers.

This will be useful in different situations, including:

  • If the developer wants to apply a pipeline to an application (GitHub repository) that has not been edited within EOEPCA (and thus no “update” message has been pushed through the Notification Service).

  • If an application “update” message has been pushed to the Notification Service but the Automation Service has not been configured yet, or has been misconfigured, preventing the automatic execution of the pipeline.

  • For testing difference pipeline configurations before configuration automated executions (using the Automation Service). This requires:

  • Pipelines configured in the Application Quality service (UC74.1).

  • A web interface that allows selecting an existing pipeline, entering execution parameters (such as the link to the application in GitHub and its branch name or tag), and initiating the execution.

  • Integration of the web app with the IAM to restrict the access to the pipeline owners.

[UC74.3] As an application or service developer, I want Application Quality pipelines to run automatically on new versions

Automated execution of Application Quality pipelines triggered via the Notification and Automation services. Application developers may want a given pipeline to be executed each time they push or build a new version of their applications.

This requires:

  • Pipelines configured in the Application Quality service (UC74.1).

  • Pipelines tested using on-demand (manual) executions (UC74.2).

  • A web interface that allows configuring the properties of the messages (channel, subject, action, etc.) that must trigger a pipeline. Behind the scene, this information is used to configure trigger functions in the Automation service.

  • Integration of the web app with the IAM to restrict the access to the pipeline owners.

[UC74.4] As an application or service developer, I want to access the reports generated by the Application Quality pipelines

Application developers must be given the possibility to access, visualise and analyse the metrics collected during pipeline executions.

It must be possible to visualise and export individual execution reports.

It must also be possible to perform time series analysis, for example by visualising the evolution of the collected metrics in subsequent versions of the same applications.

Example metrics include:

  • Amount and severity of best practice issues detected in the code.
  • Amount and severity of security / vulnerability issues detected in the code (static analysis).
  • Amount and severity of security / vulnerability issues detected in execution artefacts (such as Docker images/containers).
  • Amount of issues related to software dependencies.
  • Amount of failing tests (when executing unit test, for example).
  • Execution times using test values for input parameters

The available metrics will depend on the tooling that will be made available in the Application Quality service for integration in the pipelines.

This requires:

  • Pipelines configured in the Application Quality service (UC74.1).

  • Pipelines executed either manually (UC74.2) or automatically (UC74.3).

  • A configurable dashboard that allows

  • Selecting a particular pipeline execution

  • Selecting a set of executions of the same pipeline on the same application (e.g. between two dates).
  • Visualising the metrics using various chart types: area charts, line and bar charts, pie charts, point cloud, data tables, etc. Applicable chart types depend on the characteristics of the collected metrics.

  • Exporting reports.

  • Integration of the web app with the IAM to restrict the access to the pipeline (and execution) owners.