Skip to content

Project 1: Automated Software Quality Assurance Activities

This assignment is continuation of the first exercise and contributes to the project grade component.

You and your team members are required to fork an existing, medium-sized codebase from your previous coursework (e.g., a project during PPL or Propensi), or an open-source project other than Spring Petclinic REST that met the following criteria:

  • It has one or more test suites.
  • The code (line/statement) coverage can be improved by your team members, i.e., still less than 100% coverage and every team member should be able to contribute a new test case to increase the code coverage.
  • It has some code quality issues that can be identified by SonarQube and every team member should be able to contribute a fix.

In addition, this project work will continue on subsequent project assignments. So make sure you choose a codebase that you and your team members are familiar working with.

Tasks

Once you have decided on the codebase, do the following tasks:

  1. Clone the original codebase to your local development machine. Make sure every team members are able to run the project locally, including the test suite.
  2. Fork the original codebase into GitLab CSUI. If the original codebase is already on GitLab CSUI, then you can make the fork as easy as clicking a button. But if the original codebase is located outside of GitLab CSUI, then you need to clone the codebase and push it to GitLab CSUI.
  3. If the forked codebase originally not from any GitLab instance or does not have any CI/CD pipeline, set up a GitLab CI/CD configuration that automatically build, test, and report the code coverage. Otherwise, update the GitLab CI/CD configuration so it runs properly on your forked codebase and also includes the required CI jobs.
  4. Set up a new SonarQube project on SonarQube CSUI for the forked codebase. Do not forget to update the CI/CD configuration to include a CI job that runs Sonar Scanner after executing the test and coverage reporting.
  5. Set up, at minimum, SAST and Dependency Scanning CI jobs, on the codebase. Feel free to set up other built-in GitLab CI jobs (e.g., DAST, Fuzzy Test) that you feel relevant and useful to your codebase.
  6. Improve the code coverage and quality of the codebase. Every team members should contribute at least one Merge Request (MR) throughout the project that increase the code coverage or fix an issue identified by SonarQube/other static analysis tools involved in the CI/CD pipeline.
  7. Ensure the CI/CD pipelines are still working each time you and your team members merged an MR.
  8. Document all attempts to increase code coverage and fix issues into a text document similar to Exercise 1's report.

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 project, you are required to prepare the following artefacts:

  • A fork repository of project in a namespace on GitLab CSUI. You can create a new group to contain the fork or invite your team members to the fork hosted under your own namespace.
  • An updated codebase that increases code coverage and code quality of the project in your repository.
  • A written report in a Markdown file named PROJECT_1_REPORT.md in the repository. You can follow the template from Exercise 1.

The due date of this project: 12 September 2025, 23:55 UTC+7. Submit the URL of your fork repository to the designated submission slot on SCELE. Only a representative from the group is required to submit the URL. 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.

Last update: 2025-09-02 12:14:15
Created: 2025-09-02 12:14:15