Skip to content

Latest commit

 

History

History
288 lines (205 loc) · 13.6 KB

testPlan.md

File metadata and controls

288 lines (205 loc) · 13.6 KB
Raw

SportShield - Test Plan

Table of Contents

I. Introduction

A. Overview

The project was commissioned by CORIS Innovation1 from ALGOSUP students, and involved software maintenance. The software is an application for securing sports equipment, which is implemented on hardware supplied by the company.

The goal of the project is to optimize the consumption to make it last longer, from 3 days to 7 days or more, add an NFC2 component, and improve the security and the user experience based on the existing prototype.

B. Requirements

By following the requests of the client company, the students will focus on the following points of the project:

  • Send device information to the API3
    • Battery level
    • Position (latitude, longitude)
    • Movement (rotation, new position)
  • Efficient Alarm management
    • 3 light sounds when a light shock is detected
    • 5 long high sounds when a strong shock is detected
    • Give the possibility for the user to make the alarm stop ringing whenever he wants
  • Manage the battery: it lasts as long as possible without recharging
  • Manage security issues: resolve as many basic errors as possible to prevent the end user from having access to the software
  • Have an NFC: be able to activate/deactivate the locking mechanism without using the phone
  • Manage multiple events in real-time
  • Send notification to the phone

All the code must be written in Arduino's4 language (a variant of the C++5 programming language), following the existing code convention. No libraries except the ones that have already been given are allowed.

II. Ressources Requirements

A. Testing Environment

Operating system: MacOS, Windows language: C++, Arduino IDE6: VisualStudioCode, Arduino IDE Libraries:

To automate and facilitate tests, we created some GitHub actions.

B. Testing Tool Requirements

W3C - Testing/Requirements

III. Strategy

A. Testing Type

Unit tests

Unit tests are very low-level and close to the source of an application. They consist of testing individual methods and functions of the classes, components, or modules used by your software. Unit tests are generally quite cheap to automate and can run very quickly by a continuous integration server.

Integration tests

Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.

Functional tests

Functional tests focus on the business requirements of an application. They only verify the output of an action and do not check the intermediate states of the system when performing that action.

End-to-end tests

End-to-end testing replicates a user behavior with the software in a complete application environment. It verifies that various user flows work as expected.

Smoke tests

Smoke tests are basic tests that check the basic functionality of a device. They are meant to be quick to execute, and their goal is to assure you that the major features of your system are working as expected.

source: Atlsassian - types of software testing

B. Test Strategy

There are 8 categories of tests that are carried out independently, from the most important to the least important:

  • battery management
  • security issues
  • locking/unlocking
  • NFC
  • alarm management
  • alarm notification
  • GNSS position acquisition
  • activation/deactivation by application

To test the product, we must use a code convention7 and each test must be run 3 times correctly to be validated.

We assess the severity8 of the tests using 4 levels of evaluation: Level 1 - Critical (system shutdown, complete system failure) Level 2 - Major (significant degradation of service) Level 3 - Minor (most of the system is operational) Level 4 - Low (informative)

Due to a problem with the hardware provided, we have to use ancillary equipment. In order to test whether the features are functional, we use Breadboards with LEDs to simulate the components (buzzer, electromagnet, etc.) and resistors.

Source: TestSigma

IV. Documentation test

ID Document Writer Reviewers Deadline Completion date
a Project Charter Elone DELILLE (Technical Leader) Grégory PAGNOUX (Quality Assurance), Mathias GAGNEPAIN (Program Manager), Robin DEBRY (Project Manager), Enzo GUILLOUCHE (Technical Writer) 14/03/2024 14/03/2024
b 1st Weekly Report Robin DEBRY (Project Manager) Grégory PAGNOUX (Quality Assurance), Mathias GAGNEPAIN (Program Manager) 15/03/2024 15/03/2024
c Functional Specifications Mathias GAGNEPAIN (Program Manager) Grégory PAGNOUX (Quality Assurance), Enzo GUILLOUCHE (Technical Writer), Robin DEBRY (Project Manager) 18/03/2024 18/03/2024
d 2nd Weekly Report Robin DEBRY (Project Manager) Grégory PAGNOUX (Quality Assurance) 22/03/2024 25/03/2024
e Technical Specifications Elone DELILLE (Technical Leader) Grégory PAGNOUX (Quality Assurance) 26/03/2024 26/03/2024
f 3rd Weekly Report Robin DEBRY (Project Manager) Grégory PAGNOUX (Quality Assurance), Mathias GAGNEPAIN (Program Manager), Elone DELILLE (Technical Leader) 02/04/2024 02/04/2024
g 4th Weekly Report Robin DEBRY (Project Manager) Grégory PAGNOUX (Quality Assurance) 09/04/2024 09/04/2024
h User Manual Enzo GUILLOUCHE (Technical Writer) Grégory PAGNOUX (Quality Assurance), Elone DELILLE (Technical Leader), Mathias GAGNEPAIN (Program Manager) 10/04/2024 10/04/2024
i Theoretical calculation Mathias GAGNEPAIN (Program Manager) Grégory PAGNOUX (Quality Assurance) 10/04/2024 10/04/2024
i Test Plan Grégory PAGNOUX (Quality Assurance) Grégory PAGNOUX (Quality Assurance), Robin DEBRY (Project Manager) 10/04/2024 10/04/2024
j 5th Weekly Report Robin DEBRY (Project Manager) Grégory PAGNOUX (Quality Assurance) 15/04/2024
k 6th Weekly Report Robin DEBRY (Project Manager) Grégory PAGNOUX (Quality Assurance) 19/04/2024
l README Robin DEBRY (Project Manager) Grégory PAGNOUX (Quality Assurance) 19/04/2024 10/04/2024

V. Code test

Test convention

  • explicitly state the purpose of the test

ex:

public void Add_SingleNumber_ReturnsSameNumber()
{
    var stringCalculator = new StringCalculator();

    var actual = stringCalculator.Add("0");

    Assert.Equal(0, actual);
}
  • separate each of these actions

ex:

public void Add_EmptyString_ReturnsZero()
{
    // Arrange
    var stringCalculator = new StringCalculator();

    // Act
    var actual = stringCalculator.Add("");

    // Assert
    Assert.Equal(0, actual);
}
  • naming variables (without magic chain9)

ex:

void Add_MaximumSumResult_ThrowsOverflowException()
{
    var stringCalculator = new StringCalculator();
    const string MAXIMUM_RESULT = "1001";

    Action actual = () => stringCalculator.Add(MAXIMUM_RESULT);

    Assert.Throws<OverflowException>(actual);
}
  • No logic in the tests

ex:

[InlineData("0,0,0", 0)]
[InlineData("0,1,2", 3)]
[InlineData("1,2,3", 6)]
public void Add_MultipleNumbers_ReturnsSumOfNumbers(string input, int expected)
{
    var stringCalculator = new StringCalculator();

    var actual = stringCalculator.Add(input);

    Assert.Equal(expected, actual);
}
  • Execute three times the test (when it's possible)

source: Microsoft Learn

Criterias

Test Case ID Function Developer Description criteria Severity
00 Hardware Coris Innovation - battery supplies the board
- LED on board flash
- buzzer ring
- Electromagnet can be locked
- SIM card communicate data
- GNSS antenna communicate position
- NFC can lock/unlock the device		 Critical

Testing Schedule

Test Case ID Test Type Description Deadline Completion date Result
00 End-to-End Hardware 20/03/2024 19/03/2024 Fail
XX/0X/2024 XX/0X/2024 None
XX/0X/2024 XX/0X/2024 None
XX/0X/2024 XX/0X/2024 None
XX/0X/2024 XX/0X/2024 None

Test cases

Test cases are done on GitHub issues.

Some tests are done thanks GitHub Actions (we have the workflow file and the test file).

Glossary

Footnotes

  1. CORIS Innovation The company's main activities are engineering and engineering consultancy, recruitment and headhunting, business management consultancy, and strategic operations. The head office is not far from Lyon and has been in existence since 2015 thanks to Thibault Peltier and Stéphane Maite. Source: CORIS Innonvation ↩

  2. NFC (Near Field Communication) Wireless transmission technology that simplifies the exchange of data. The technology is used in particular for Bluetooth on mobile phones. Source: Phonandroïd ↩

  3. API (Application Programming Interface) A software interface that allows one piece of software or service to be "connected" to another piece of software or service to exchange data and functions. Source: CNIL ↩

  4. Arduino Arduino designs, manufactures, and supports electronic devices and software, allowing people to easily access advanced technologies that interact with the physical world. source: Arduino ↩

  5. C++ C++ is a programming language developed in 1983 by Bjarne Stroustrup, who wanted to 'increment' the C language (hence the name, c++ meaning 'add 1 to C'). It is object-oriented programming. C++ allows you to write optimised, extremely fast code. It is one of the most widely used languages, particularly in software development (e.g. iPod interface, web browsers) or video game programming (e.g. PS3, PS4 operating systems), due to its performance and versatility. Source: DataScientest ↩

  6. IDE (Integrated Development Environment) Software application combining all the tools needed for a software development project in one place. It provides an interface for writing code, organising text groups, and automating redundant programming tasks. Source: DataScientest ↩

  7. Code convention Coding conventions are a set of guidelines for a specific programming language that recommend programming styles, practices, and methods for each aspect of a program written in that language. Source: Wikipedia ↩

  8. Severity The severity is the impact of the issues on the project/program. It measures thanks to a level system where 1 is critical, 2 is Major, 3 is Minor, and 4 is Low. It's the role of the QA to define the severity of the issue. Source: TestSigma ↩

  9. Magic Chain A value that is not defined and for which we don't know what it represents. (e.g: Action actual = () => stringCalculator.Add("1001"); "1001" is a magic chain and must be defined using a constant such as: const string MAXIMUM_RESULT = "1001"; Action actual = () => stringCalculator.Add(MAXIMUM_RESULT);) Source: Microsoft Learn ↩