1. QA Lead: Nathan Ziri
   1. Mobile phone : 514--_
   2. Email addresses : [email protected]
2. Internal Testers
   1. Elias
   2. Micheal C

With regards unit testing we chose to use 2 possible unit testing frameworks which we will explain in depth in the following sections.

We will also be using Jest as one of our testing frameworks for our Unit tests. Jest is a JavaScript unit testing framework which aims for simplicity. We decided to use Jest for several reasons, the first reason is because it works well with Node JS which we plan on using as well. Jest also seems to be good because it seems to promote itself as something easy to set up. More information about Jest can be found at https://jestjs.io/.

For our project we will be using Travis CI. Travis is a continuous integration service which can be used to build and test repositories in GitHub. We will most likely be using this because this is what we have the most amount of experience with. It has very good integration with GitHub and can be run on projects using Java and JavaScript which is what we need. for our project. It can also be connected with coverage and static analyzers.

With regards to code coverage we will be using OpenClover. OpenClover is a code coverage program which can be used on Java and JavaScript which is good for us since our program will most likely be using both. Information about OPenClover can be found at http://openclover.org/index.

Because builds are made after every pull request we will do weekly reviews to check why builds failed (any). We will then set out to address these bugs and assign who will fix them.

1. Basic Responsibilities of Test Team
   1. Bugs
      1. When a build is pushed to the repository, if the build is successfully pushed without issues the test team will try the branch and check for bugs.
      2. If bugs are found the dev team is alerted of the bug and how to reproduce it.
      3. The dev team then researches the why the bug occurred
      4. Dev team resolves the Issue

1. Basic Responsibilities of Test Team
   1. The Build
      1. Since builds are only generated when a repository is committed, first we check for any new commits.
      2. Run the build and check for any known issues related to the new feature and perform regression testing on any old known issues.
      3. Alert the devs of any issues if they arise.

1. Weekly Tests
   1. Tests will be continually run throughout the week. reports will subsequently be made.
   2. The dev and testing team will have weekly meetings in which they can discuss about any bugs they have come across.
   3. If there are recurring bugs we will assign them to the devs to be resolved.

1. Perform specialized tests as requested by dev team.
2. Determine the appropriate level of communication to report the results of those tests

1. In the 2-3 before a deliverable is due, the testing team and the dev team will meet to discuss and look over the latest build.
2. Common and program breaking bugs will be tested.
3. Any bugs found will be assigned to a dev to be resolved and retested. Weekly review of bugs:

Verify that “fixed” bugs are really fixed and do not persist. Rank bugs relative to their urgency as well as the progress of the project as a whole. Generate a weekly report of fixed bugs (if needed).

1. “A” bugs are bugs that: causes the program to crash, breaches user security and data, allows users back-end functionality they should not have access to, disables major functionality.
2. “B” bugs are bugs that: disable minor functionality, allow users to use the program as normal with exception of affected components, and can be corrected by restarting the program.
3. “C” bugs are bugs that: cause minor graphical issues, lag the program but not to an excessive extent.

1. Graphical: Components appearing in the wrong colors or in the wrong position.
2. Database: Giving users access to data they should not have access to, not attributing documents to the proper creator, incorrect data being displayed.
3. Security, Ex: Backdoor to user accounts, data breach vulnerabilities.
4. Lag, Ex: slow load times, excessive buffering.
5. User health and safety, Ex: Unintended strobing light.

1. The testers will classify all the bugs.
2. Bugs will be reassigned to the developer to whom the commit belonged to.
3. Bugs are retested to ensure the issue is resolved
4. If the is of level B or greater it is retested before the next deliverable.

#6 Reports Reports should be made by the person who found the bug and take a the following format.

Label: Bug
Severity:
Type: (Select all that apply and add your own if need be)
Estimated fixed by date:
Description of Bug:
Steps to Reproduce:
Probable Cause:

Different types of testing has been performed in the previous sprints;however, more testing tools and methods need to be brought to the future sprints. Please notice that Travis CI has been implemented to continuously run tests on the project as development persists and changes are made. As for bugs, there is no doubt that more bugs and problems will emerge as development persists, it is almost impossible to detect them all; but still, with Travis CI, the developers will be able to perform more efficeint tests and detect problems. More bugs and problems will be specified in the future sprints. Travis CI could possibly delay project advancement, but that is manageable, possible solutions has been mentioned in the Risk Management Report.

Continuous integration tests can be seen running at https://travis-ci.com/github/Pyxsys/SOEN390_19.

These will be added to the list of issues and should then be moved to the Bug Kanban board