Skip to content

Exercise 1: Automated Software Quality Assurance Activities

In this exercise, you will practice on setting up test automation, including CI/CD, to improve software quality assurance in a open-source project. The tasks will include configuring a new SonarQube project on SonarQube CSUI, adding some built-in GitLab CI jobs into the project, and improving the code quality and code coverage of the project.

The open-source project used in this exercise is a fork of Spring Petclinic REST. The project's codebase provides both the production code (i.e., the actual source code of the app) and the test code (i.e., the source code for testing the app). Currently, the the test suite covers 86% of the production code when run locally using Maven.

Getting Started

Do the following steps before starting the exercise:

  1. Ensure you are enrolled in PMPL (SQA) course and have an account on GitLab CSUI. If you don't have an account on GitLab CSUI, please notify the instructors as soon as possible.
  2. Create an account on SonarQube CSUI by logging in using your GitLab CSUI account.
  3. Set up the required tools for this exercise in your local development machine:
  4. Open the project page on GitLab CSUI.
  5. Clone the codebase into your local development machine using Git: 
    1
2
    git clone git@gitlab.cs.ui.ac.id:pmpl/examples/spring-petclinic-rest.git <some path in your local development machine>
cd <location of the cloned repository>
  6. Ensure that the main branch of the forked repository is called csui: 
    1
2
3
    $ git status
On branch csui
# ... (omitted for brevity)
  7. Run the test suite and generate the coverage report: 
    1
    ./mvnw test jacoco:report

If everything goes well, the tests should pass and the coverage report can be found at target/site/jacoco/index.html. Verify that the current code coverage is 86%.

Task 1: Configure SonarQube

Even though the original (upstream) version of the project has a SonarQube project, remember that you cloned a fork of the project. Thus, you need to set up a separate SonarQube project on SonarQube CSUI because the analyses cannot be inherited from the upstream.

Follow these steps to set up a new analysis of the forked project on SonarQube CSUI:

  1. Open the list of projects page on SonarQube CSUI. Click Create Project and choose Local project.

  2. Fill in the required fields with:

    • Project display name: spring-petclinic-<your name>
    • Project key: spring-petclinic-<your name>
    • Main branch name: csui

    See the provided screenshot to see an example using burhan as the placeholder name. alt

  3. In the next page, choose Use the global setting. Then, click Create project button.

  4. In the project page on SonarQube, the view should display Analysis Method with some possible configuration choices. Choose With GitLab CI and then choose to generate a new SONAR_TOKEN. Take note of the generated token. You do not need to concern with SONAR_HOST_URL and the GitLab CI job template because it has been preconfigured in your cloned fork.
  5. Open the forked project on your GitLab CSUI namespace and go to Settings - CI/CD page. Add a new variable called SONAR_TOKEN and fill it with the previously generated token.
  6. Open your text editor/IDE, then load the cloned project repository.
  7. Create a new branch called task/1-setup-sonarqube from the main branch: 
    1
    git switch -c task/1-setup-sonarqube
  8. Open pom.xml and replace the current sonar.projectKey value with the new project key. Save the modified file and commit the changes: 
    1
2
    git add pom.xml
git commit -m "Update the project key"
  9. Push the updated branch to your forked repository on GitLab CSUI: 
    1
    git push -u origin task/1-setup-sonarqube
  10. Create a Merge Request (MR) to merge task/1-setup-sonarqube branch to csui branch of your own repository! Please double-check the merge target because, by default, GitLab will set the merge target to the original repository of a fork repository. The instructors do not want to be flooded with Merge Request notifications.
  11. Make sure the pipeline in MR pass and merge the branch.
  12. Verify the sonarqube-check job run successfully after task/1-setup-sonarqube branch is merged to csui.
  13. Open the SonarQube project and verify the analysis results successfully reported on SonarQube CSUI.

Task 2: Explore GitLab CI Job Templates

To keep stay within the GitLab platform, GitLab provides several built-in CI job templates that can be included into a project's CI/CD configuration. By doing so, we can minimise the tools need to be maintained and also focus on utilising the built-in features on GitLab.

Note: GitLab does offer a code quality analysis using CodeClimate. However, it is being deprecated in latest GitLab version. Hence the emphasis on using SonarQube.

As part of the exercise, you need to modify the existing CI/CD pipeline configuration of the forked project to include the following CI job:

Let's start by setting up SAST:

  1. Open your text editor/IDE and make sure the latest update on the csui branch is sychronised to your local development machine: 
    1
2
    git switch csui
git pull origin csui
  2. Create a new branch called task/2-update-gitlab-ci.
  3. Open .gitlab-ci.yml file. Notice that there are two TODO comments. First is a mandatory task to set up SAST & Dependency Scanning jobs and the other one is an optional task to set up DAST job.
  4. According to the SAST documentation on GitLab, SAST job can be included into a GitLab CI/CD configuration by using include syntax. Add the SAST job into your project's GitLab CI/CD configuration.
  5. Save the modified GitLab CI/CD configuration file and commit the changes.
  6. Since GitLab CSUI is an instance of GitLab Ultimate Edition, let's try enabling the advanced SAST scanning as well. According to the SAST analyzer settings documentation, there is a CI/CD variable named GITLAB_ADVANCED_SAST_ENABLED that toggles to advanced SAST feature. Set the variable either by overriding the included SAST job in the GitLab CI/CD configuration file, or via the Settings - CI/CD page of your project page on GitLab CSUI. If you made changes to the GitLab CI/CD configuration file, do not forget to save and commit the changes.
  7. Push the updated branch to your forked repository on GitLab CSUI.
  8. Create a MR to merge task/2-update-gitlab-ci branch to csui branch of your own repository!
  9. Verify that the SAST job is running on the MR pipeline.

Once you confirmed that the SAST job is running, let's configure the Dependency Scanning job, which is also a feature in GitLab Ultimate Edition:

  1. Open the GitLab CI/CD configuration file again (i.e., .gitlab-ci.yml) using your text editor/IDE.
  2. Similar to the SAST job, the Dependency Scanning job can be added into the CI/CD configuration by using include syntax. See the example at the Dependency Scanning documentation.
  3. Save the modified CI/CD configuration file and commit the changes.
  4. Push the updated branch to your forked repository on GitLab CSUI.
  5. Open the MR page on GitLab CSUI and verify the Dependency Scanning job is running.

Once you have confirmed both SAST and Dependency Scanning jobs are running on the MR pipeline, you can merge task/2-update-gitlab-ci branch into csui branch. At initial configuration for the first time, both SAST and Dependency Scanning jobs may not produce interesting findings because they have not established the baseline based on the current state of the main (csui) branch. In the next task, both jobs should be able to provide findings by comparing analysis in a new MR pipeline with the existing baseline.

Task 3: Improve Coverage and Code Quality

In this task, you will analyse the SonarQube analysis report and improve the project's code quality and test coverage. Unlike previous tasks, this is self-directed task. That is, there won't be any guided steps to follow and you have freedom on how to achieve the goals. The goals are as follows:

  1. Increase the code coverage to at least 90%.
  2. Resolve at least 5 issues identified by SonarQube.
  3. Maintain passing Quality Gates enforced by SonarQube and GitLab CI/CD.

The overall structure of working on this task is as follows:

  1. Pull the latest update on the csui branch to your local development machine.
  2. Create a new task branch called task/3-improve-coverage-quality.
  3. Analyse the SonarQube report on SonarQube CSUI. Check the coverage report in the Measures tab to look for uncovered classes and lines. Then, check the Issues tab to get list of identified SonarQube issues.
  4. Increase the code coverage. Pick 2 - 3 classes with the lowest coverage and try to write the tests to cover them.
  5. Fix the SonarQube issues. Pick 5 fixable issues. Make sure the test suite still pass before and after you fix the issues!
  6. Check the SAST and Dependency Scanning reports in your MR pipeline. If there are vulnerable or outdated dependencies, update them in pom.xml and ensure the tests still pass. Similarly, if there are vulnerabilities identified by SAST, fix them and justify your changes. Some findings may be false positives, so please explain why you ignored them.
  7. Document your changes. For each new test and fix, describe the reason why you made the changes and highlight how the changes were implemented. You can follow the template provided in the last part of this document.
  8. Push your task branch to GitLab CSUI and create a MR to merge the task branch into csui branch.
  9. Ensure the CI/CD and SonarQube's Quality Gate still pass.

After you have finished this exercise, you can proceed to work on the first project with your team members.

Generative AI Usage Policy

You may use generative AI tools for this exercise, but you must understand that you are trying to learn and practice the subject, not the AI itself. Furthermore, remember that generative AI may produce incorrect results so it is still imperative to review the generated responses.

If you do use generative AI, you must agree on the following constraints:

Allowed Uses

  • Code generation: you can ask generative AI to suggest test cases, fixes, or update on the CI/CD configuration.
  • Explanations: you can ask generative AI to explain SonarQube rules violation, SAST warnings, or Maven commands.
  • Debugging help: you can ask generative AI to help you interpret error logs or failed pipeline outputs.

For every AI-assisted change, you must document them in the written report document under a new section called AI Assistance Log.

Prohibited Uses

  • Direct submission: you must not submit AI-generated code/text without understanding or testing it.
  • Bypassing learning: you must not use generative AI to write your entire report or explain concepts that you have not researched on your own.

Deliverables

At the end of this exercise, you are required to prepare the following artefacts:

  • A fork repository of Spring Petclinic REST project in your own namespace on GitLab CSUI.
  • An updated build configuration (pom.xml) and GitLab CI/CD configuration (.gitlab-ci.yml) in the repository.
  • An updated codebase that increases code coverage and code quality of the project in the repository.
  • A written report in a Markdown file named EXERCISE_1_REPORT.md in the repository. You can use the template to help you organise your report.

The due date of this exercise is: 12 September 2025, 23:55 UTC+7. Submit the URL of your fork repository to the designated submission slot on SCELE. Please ensure any updates to the fork repository related to this exercise were made and pushed before the due date.

Generative AI Use Disclosure

Mistral Medium is used to proofread this document and generate the tabular format examples in the report template.

Notes: Faculty's CI Infrastructure

For your information when setting up the GitLab CI/CD configuration that will run on GitLab CSUI. the following is the overview of the CI infrastructure in the faculty at the time of writing:

  • GitLab Runner is running on a server using Docker executor with privileged mode enabled. Consequently, all CI jobs running on projects hosted at GitLab CSUI will run in a container by default and able to access the Docker daemon running on the server.
  • The containers spawned by the Docker executor may utilise all CPU cores available on the server, but limited to memory allocation, which is only 8 GB per running container.
  • GitLab Runner has been configured to use a separate Minio cache server, thus allowing caching files and folders across multiple stages in a CI/CD pipeline.

Note: If you are interested with Infrastructure-as-Code (IaC) configuration of the runner, you can find the Ansible playbook used for setting up the server and installing GitLab Runner at Infra Kuda repository.

Report Template

You can use the following Markdown template as a starting point for your report:

Note: you can write your report in English or Bahasa Indonesia

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Exercise 1 Report

- **Name:** <NAME>
- **NPM:** <NPM>

## Changes Made to the Project

> In tabular format. The entries in the following table are only example!

| Type          | Location          | Issue/Test Goal                     | Fix/Test Implementation          | Validation               |
|---------------|-------------------|-------------------------------------|-----------------------------------|--------------------------|
| Test Coverage | `UntestedClass.java` | Cover `findOwnerByName()` method.     | Added `UntestedClassTest.java`. | Coverage increased to 88% |
| SonarQube     | `SomeClass.java`  | Improve regex | Used regex character class | Issue fixed on SonarQube.        |
| Dependency    | `pom.xml`         | Vulnerable logging package may cause log4shell CVE | Updated logback package version | Issue fixed according to subsequent Dependency Scanning run |

## AI Assistance Log

> In tabular format. The entries in the following table are only example!

| Task          | Prompt Used       | Summary of AI Response              | Your Evaluation                  | Final Implementation      |
|---------------|-------------------|-------------------------------------|----------------------------------|---------------------------|
| Replace regex | "Replace the regex with \d character class" | Edited the regex string to use `\d` regex class | Valid. Existing tests still pass | [Link to the corresponding commit/merge request](#) |

## Interesting/Relevant Findings

> TODO (optional): Write down your interesting findings here, if any, that not
> necessarily related to the exercise but still relevant to the SQA as a whole.
Last update: 2025-09-02 12:14:15
Created: 2025-09-02 09:31:58