| Authors | Axel David |
|---|---|
| Created | 23/09/2024 |
| Last Modified | 21/10/2024 |
| Role | Name | Signature | Date |
|---|---|---|---|
| Project Manager | Enzo GUILLOUCHE | ✅ | 21/10/2024 |
| Program Manager | Evan UHRING | ✅ | 21/10/2024 |
| Technical Lead | Maxime Caron | ✅ | 21/10/2024 |
| Software Developer | Elone Delille | ✅ | 21/10/2024 |
| Technical Writer | Pierre GORIN | ✅ | 21/10/2024 |
| Quality Assurance | Axel David | ✅ | 21/10/2024 |
Table of Contents
We were tasked to recreate the game Frogger using an FPGA[1] using the verilog[2] language.
According to the types of players, our Frogger will have different requierements.
Take a look at personas definition in functional specification for more information
What retro players need is a game that works just fine and that allows them to feel the sentation of old games.
What new players need is a working game that let them experience the game without the risk of any issues coming from the game.
What speed runners need is a game with no bugs and fast enough to allow them to play fast without the game crashing.
For this frogger project, we have been imposed to use specifics hardware and software.
FPGA is an integrated circuit that can be repeatedly programmed.
Take a look at FPGA[1] in the glossary for more details.
Verilog is the programming language we will use to program on FPGAs.
Take a look at verilog[2] in the glossary for more details.
We use test criteria to know what the Quality Assurance will have to test.
Critical bugs are bugs that prevent the game from working properly and from implementing new features before resolving those bugs. If a critical bug is encountered, we will suspend the tests until the bug is resolved.
You can look at the tests and tested functions here.
Every function of the game will have to be tested.
Before the product is deemed ready for distribution, several key benchmarks must be met to ensure its quality and reliability. These criteria collectively ensure the product meets the required quality standards before progressing to distribution. These include:
- Test Case Coverage:
- Achieve a minimum of 80% test case coverage across all identified features and functionalities before concluding the testing phase.
- This guarantees that nearly all components of the software have undergone thorough testing.
- Bug Resolution Rate:
- 100% of reported 'High' and 'Medium' severity bugs must be resolved before the testing phase is considered complete.
- At least 80% of 'Low' severity bugs must also be addressed before exiting the testing phase.
- This requirement prioritizes fixing critical issues to improve the software's overall stability and reliability.
- Documentation Completeness:
- All relevant documentation—such as test plans, test cases, test results, functional and technical specifications—must be fully completed and reviewed.
- Documentation should be clear, comprehensive and accessible to the entire team, ensuring everyone has a solid understanding of the testing procedures and results.
Here's the purpose of our testing strategy:
- We will implement Unit Tests to ensure the quality of the code.
- We will perform Testing sessions to ensure that the documented quality of the project is up-to-date.
- We will use External tools to help us testing the product.
The two main things to test during this project will be the documents and the game itself.
About the documents, it's paramount to ensure their quality, so that communication with users is clear and the whole team can work on the same basis.
Not only will we check the documents for grammatical and typographical errors, but also the content itself, to ensure that no crucial points have been overlooked or erroneous elements introduced into the document.
We will operate unit tests, functional tests and collaborative game testing to ensure the quality of the project.
Unit testing is an important part of the process. These tests will be written by the Software Engineers throughout the project, in parallel with project development. Then, the Quality Assurance will run these tests during tests cases.
These unit tests serve three crucial objectives:
-
Code Functionality: Verify that each function performs as expected under various scenarios.
-
Code Quality: Assess the clarity and quality of the code to promote maintainability and ease of collaboration among developers.
-
Code Coverage: Guarantee comprehensive testing to prevent future changes from unintentionally altering the original behavior of the code.
Functional tests consists in palying the game and looking for bugs by testing every events (exemple of an event: moving to the left) within the game.
Collaborative Game Testing consist in making people play our game and report each bug.
Priorities are given to determine which test has to be done first.
There will be 4 explicit priorities:
- Critical
- High
- Medium
- Low
Test tools are what we will use to test the quality and the functionality of the code.
System VERILOG is a programing language used for VERILOG simulation. It permits us to test functions by setting inputs and looking at outputs.
EDA Playground is a website with an integrated testing environment using VERILOG and System VERILOG.
To document and track easily test cases, their results, and overall testing progress, the tests would be divided into these three sections:
Test Case Pattern:
We have to make a certain pattern for test cases to ensure the readability and consistency of the work:
For further details, refer to the test case document.
Test reports Pattern:
We also have to make a certain pattern for test reports to ensure the readability and consistency of the work:
For further details, refer to the test report document.
Progression:
- Test Amount Representation:
- A visual scheme representing the test reports based on the amount of their status (Passed, Failed, In Progress, Not Implemented).
- Provides a visual snapshot of the overall testing status.
You can see all tests on the test spreadsheet.
| Task | Start Date (dd/mm/yyyy) | End Date (dd/mm/yyyy) |
|---|---|---|
| Create and give templates | 23/09/2024 | 20/10/2024 |
| Review the documentation | 23/09/2024 | 21/10/2024 |
| GitHub Actions | 23/09/2024 | 21/10/2024 |
| Unit tests | 16/10/2024 | 20/10/2024 |
| Functional tests | 16/10/2024 | 20/10/2024 |
- Test plan/test strategy: define the testing strategy and how the tests will be done.
- Test cases: define all the test that will be done to be sure that the game works as intended.
- Bug reports: report all the bugs that have been found during the tests.
- Bug data report: to have a global view of the bugs that have been found during the tests.
| Word | Definition | Source |
|---|---|---|
| [1]: FPGA | Short of Field Programmable Gate Array, it is a type of configurable integrated circuit that can be repeatedly programmed after manufacturing. | wikipedia.org |
| [2]: VERILOG | It is a hardware description language (HDL) used to model electronic systems (like an FPGA). | wikipedia.org |
| [3]: VGA | Short of Video Graphic Array, it is a video display controller. | wikipedia.org |
| [4]: seven segment display | It is a form of electronic display device for displaying decimal numerals. | wikipedia.org |
| [5]: Konami | It is a japanese corporation focused on digital entertainment and sport businesses. | konami.com |
| [6]: SEGA | It is a japanese corporation focused on the video game business. | sega.com |
| [7]: sprite | In computer graphics, it is a two dimensional map used to texture models of a 2D game. | wikipedia.org |
| [8]: The Go Board | The Go Board is a low-cost, beginner-friendly FPGA development board. | nandland |
The glossary is the same as the functional one you can find here