Software Quality Assurance Plan
Our Software Quality Assurance (SQA) Plan outlines the strategy for verifying the business logic in the backend through both static and dynamic testing. It defines the unit testing approach to achieve desired test coverage and reports the actual coverage attained. Additionally, the plan includes quality assurance techniques such as integration testing, which ensures seamless backend service integration with the RESTful API.
- Test Coverage Criteria: Aiming for 80% method and line coverage to ensure thorough testing of code paths.
- Unit Testing Approach: Focused on validating individual business methods within the backend, covering various inputs, outputs, and edge cases.
- Integration Testing: Designed to ensure that backend components (e.g., services and databases) interact seamlessly at the interface level, verifying that components work together correctly across defined boundaries.
This plan ensures that our code is robust, reliable, and fully integrated, addressing all necessary quality assurance processes throughout development.
To achieve reliability and a high standard of code quality, we have set the following test coverage criteria:
- Statement Coverage: 75%
- Branch Coverage: 70%
These targets ensure that we test not only the code paths but also a majority of logical decisions within our business methods. We use JaCoCo to monitor and measure these metrics automatically during each build.
In our unit testing, we utilised JUnit and Mockito to isolate and validate the core backend logic. For example, in the case of the OrderService, we tested service methods by mocking external dependencies like the OrderRepository to simulate data retrieval and persistence without hitting the actual database. The tests were designed to cover both valid and invalid inputs, as well as edge cases such as null values and empty fields. This ensured the service handled all possible scenarios gracefully. Additionally, we applied stubbing to simulate external calls (e.g., mock repository responses) and ensure that the business logic was correctly executed, even when external components were unavailable. We focused on key business flows like order creation, order retrieval, and order validation, verifying that each function adhered to the expected behaviour and failed appropriately when necessary.
For integration testing, we employed Spring Boot with @SpringBootTest and MockMvc to ensure that our backend services were correctly integrated with the RESTful API. We wrote tests that exercised the full end-to-end flow, from sending HTTP requests (like POST, GET, and PUT) to the API to validating the responses and ensuring that the service layer handled the requests correctly. The tests also involved database interactions, confirming that data was properly persisted and retrieved. Additionally, we tested edge cases like invalid inputs and missing fields to check if appropriate HTTP status codes (e.g., 400 Bad Request, 404 Not Found) were returned. This allowed us to validate not only the internal service logic but also the seamless interaction between the API and the database. For example, we tested how the OrderService handled requests and ensured that it properly interacted with both the API layer and database.
In addition to the unit and integration testing, we applied other quality assurance practices to ensure code quality and maintainability. Static verification and validation (V&V) tools were used to detect potential code defects early in the development process. These tools helped identify issues related to code formatting, variable naming, and unused imports, ensuring that the code met predefined quality standards.
We also followed coding conventions and best practices, including maintaining clear and concise code, modularizing functionality, and keeping methods focused on a single responsibility. These practices helped ensure that our codebase remained maintainable and understandable for the entire development team.
Furthermore, we conducted peer code reviews using Git to maintain high code quality. All pull requests were reviewed before merging, allowing team members to catch issues early and share feedback. This peer review process promoted collaboration and helped us maintain consistent coding standards across the project.
Author: Jason
ID: UC1
Title: Create account
Description: A user creates an account for the game store system.
Actor: A user who does not have an account.
Pre-condition: A user clicking and create account button and does not have an account.
Post-condition: The system redirects user to the login page.
Main scenario:
- The user indicates that they want to create a customer account.
- The system displays the new user registration page with a form.
- The user enters their email, username, password, re-enter password (twice to avoid typos), and address.
- The system confirms that their account was created successfully.
Alternative scenarios:
- 4a) The user enters an empty email, username, password, or address
-
- 4a.1) The system informs the user that the email, username, password, and address they enter cannot be empty.
-
- 4a.2) The system highlights the empty fields.
-
- 4a.3) The use case continues at step 3.
- 4b) The password that the user enters does not have at least 8 characters
-
- 4b.1) The system informs the user that the password has to be at least 8 characters long
-
- 4b.2) The system erases the password and re-enters password field
-
- 4b.3) The use case continues at step 3
- 4c) The two passwords that the user enters does not match
-
- 4c.1) The system informs the user that the passwords they entered do not match
-
- 4c.2) The system erases the password and re-enters password field
-
- 4c.3) The use case continues at step 3
- 4d) The email address already matches with an existing user in the database
-
- 4d.1) The system informs the user that the email they entered is already linked to an existing account so try logging in.
-
- 4d.2) The system redirects the user to the login page.
Author: Jacob
ID: UC2
Title: User Login
Description: The user signs into their existing account for the game store system.
Actor: A user who has already created an account.
Pre-condition: A user on the login window.
Post-condition: Returns to the page they were previously on where they can now access their account information by clicking a tab.
Main scenario:
- The user clicks on the login button available on any page.
- A new login window pops up containing a username and password field.
- The user enters their username and password.
- The user returns to the page that they were previously on where they can now complete actions that require logging in.
Alternative scenarios:
- 1a) The user attempts an action that requires logging in (viewing account information, purchasing/returning a game, adding a review, etc.)
-
- 1a.1) The login window pops up.
-
- 1a.2) The user enters their username and password.
-
- 1a.3) The user returns to the page that they were on when the login window popped up.
- 3a) The user enters an incorrect or non-existent username or password, and the page displays a warning.
Author: Jordan
ID: UC3
Title: Adding/Removing a game
Description: The manager adds and/or removes a game from the game store system.
Actor: A user with manager privileges
Pre-condition: User with manager privileges is on the Manage Games page
Post-condition: The game is added/remove with a confirmation message displaying the action
Main scenario :
- The user navigates to the Manage Games page
- The user clicks the Add Game button
- A new form appears where the user enters game details, such as title, description, price and category
- The user clicks the Submit button
- The game is successfully added to the system and a confirmation message is displayed
Alternative scenarios:
-
2a) The user removes a game
-
- 2a.1) The user selects a game from the list of games
-
- 2a.2) The user clicks the remove button next to the selected game
-
- 2a.3) A confirmation prompt appears, asking the user to confirm the removal
-
- 2a.4) The user confirms the removal
-
- 2a.5) The game is now archived, and a confirmation message is displayed
-
3a) The user enters an empty title, description, price and/or category
-
- 3a.1) The system informs the user that the title, description, price and/or category they enter cannot be empty.
-
- 3a.2) The system highlights the empty fields.
-
- 3a.3) The use case continues at step 3.
Author: Yvehenry
ID: UC4
Title: Reviewing a Purchased Game
Description: A customer gives a review on a game he previously purchased.
Actor: A user who has a customer account and who has purchased games on the system
Pre-condition: The user is logged into his customer account and is on their “Purchase History” page
Post-condition: A review is added to a game, and the review can be seen by other users
Main scenario:
- The user navigates to the purchased game they want to review
- The user clicks on the “Review Game” button
- The system redirects the user to a form where a star rating from 1 to 5 and a description can be inputted.
- The user gives a rating from 1 to 5.
- The user writes a description for the rating.
- The user clicks the “Submit Review” button.
- The review is successfully added to the system and a confirmation message is displayed
Alternative scenarios:
- 7a) The user does not provide a star rating from 1 to 5
-
- 7a.1) The system informs that a star rating from 1 to 5 is required
-
- 7a.2) The use case continues at step 4.
- 7b) The user does not give a description to his rating
-
- 7b.1) The system informs that a review description is required
-
- 7b.2) The use case continues at step 5.
Author : Ben
ID: UC5
Title: Add game to cart
Description: The customer adds a game to the virtual shopping cart
Actor: A customer
Pre-condition: Customer is on the browsing/shopping page with the available-to-purchase games displayed
Post-condition: The game is added to the cart which can be seen when the user enters the “go to cart” page
Main scenario :
- The user navigates to the browsing/shopping page
- The user clicks the title/icon of the game they are interested in
- The Game Information page is displayed, with accessible buttons such as add to cart and add to wishlist
- The user clicks the add to cart button
- The game is added to the user’s cart, which is verifiable in the cart page
- The button changes to say “added to cart” and a new field is displayed to allow the user to increase the number of copies of the game that they would like to add to cart
Alternative scenarios:
- 4a) The game is already added to cart and the user attempts to press the add to cart button
-
- 4a.1) The user is prompted to confirm if he would like to add a second copy of the game to cart
-
- 4a.2) The user can select yes, which would add the copy to the cart, or no which would simply remove the prompt from the page
Author: Ben
ID: UC6
Title: Return Purchased Game
Description: The customer returns a game online with the anticipation of shipping it back to the store warehouse
Actor: A customer
Pre-condition: Customer is on the purchase history page with the display of games he has purchased
Post-condition: The game is virtually returned with a confirmation for pick up date
Main scenario :
- The user selects the game he would like to return
- The user selects the button “return game”
- The user is asked to provide a reason for his desire to return the game and to select a method of refund as well as a refund address
- The user is given a date for the pick-up of his game and asked to confirm if all provided information is correct
- After confirmation, the user is given the opportunity to leave an optional review of the game
- The user is returned to the purchase history page and the game is grayed out to indicate it’s return
Alternative scenarios:
- 3.a) The user does not provide a reason of return, credit card or pick-up address and is prompted to give all appropriate information before executing any further commands
- 4.a) The user does not confirm that the information is correct, and can execute step 3 again
- 5.a) The user refuses to leave a review, and is redirected back to the purchase history page regardless
- Decision: Employee and Customer are subclasses of the abstract Person class.
- Explanation: This avoids repeated common attributes among customers and employees. Also, a user must be either a customer or staff, thus the Person class is abstract.
- Decision: Manager is a subclass of Employee.
- Explanation: Again, this avoids repeated common attributes. Manager inherits all the attributes from the Employee class, where the isManager field can be set to True. This also allows Manager to complete tasks that only they can do (e.g.: game approvals, promotions, etc.)
- Decision: Order class
-
Explanation: Each instance of the Order class will contain a unique ID and order Number that can be used to track, view, and manage specific orders from the system and the user respectively.
-
The status field relates to the separate enum class Status. Here, an order can be defined as “PendingPurchase” when a customer has added games to their cart without purchasing yet.
-
Next, once customer has purchased the items in their Order, the status changes to “Delivered” (since delivery issues and tracking are outside the scope of this project).
-
Alternatively, the customer can cancel a pending order in which case, the order status is “Canceled”, and the order can be deleted.
-
Finally, a “Delivered” order can be returned by the customer, thereby changing its status to “Returned”. Customers and Employees can view the purchase histories by filtering for “Delivered” orders.
- Decision: Game class
-
Explanation: Each instance of the Game class has a unique ID that can be used to manage it from the backend. Also the game’s title, description, image, price, and stock can be viewed by the user (Person).
-
When an employee adds a game to the GameStoreSystem, the isApproved field is defaulted to False, thereby setting the archivedDate to the current Date, and archiving the game until it has been approved by a manager.
-
Once a manager approves (or if they themselves add a game directly), the isApproved field changes to True. When this happens, the archivedDate field is emptied (set to null), meaning the game is no longer archived and can be viewed by the customer.
-
Additionally, if an Employee needs to remove a game, or if the stock is down to zero, the archivedDate can be changed. This not only acts as a Boolean to track if a game is archived, but also records the archived date for staff records.
- Decision: PaymentInfo is a separate class from Customer
- Explanation: Although the fields in PaymentInfo could have been included in the Customer class, having them as separate classes with a 1-to-many association allows a customer’s payment information NOT to be stored in the system if they so choose.
- Decision: Wishlist class
- Explanation: Wishlist is a separate class from Order because there is no imminent purchase implied in a wish list. Indeed, a Wishlist simply allows customers to save games they are interested in.
Multiplicities Composition Associations:
- Review and Game
- a. A review cannot exist without a game.
- b. If a game is removed (archived) from the system, it is logical that all the reviews about this game are also removed.
- c. A game can have multiple or zero reviews.
NOTE: A case could be made that Review should have a Composition association with Customer as well (i.e. A review cannot exist without a customer). Although this is true logically, it is illegal to have Review depend on 2 classes in a part-whole relationship (Customer and Game) without and {xor} branch between associations. Additionally, if a customer is removed from the system, it is still beneficial to keep their reviews about a game.
- Promotion and Game
- a. Promotions apply to games and cannot exist without a game.
- b. If a game is removed, the promotions on this game should also be removed.
- c. A game can have zero or one promotion. If multiple promotions exist, only the highest one should apply to the game (i.e. promotions do not add up).
Unidirectional Associations:
- Wishlist and Game
- A wish list requires access to information available in the Game class, while the opposite is not true: a game does not need to know if it is included in a wish list, much less the details of a specific wish list.
- Employee and Category
- A category does not need to know the information of the Employee creating it.