... | ... | @@ -7,6 +7,61 @@ |
|
|
## Overview
|
|
|
Before we began writing the code we discussed how we were going to handle keeping a consistently acceptable level of quality. We decided on our Quality Assurance Plan that we would focus on the Testing and Inspection methods.
|
|
|
|
|
|
## Quality Objective
|
|
|
* Users will be able to visit every page and use any interaction element, buttons or text entry, without the application crashing.
|
|
|
* Users can intuitively understand how to use the application once launched without the assistance of external resources.
|
|
|
* Users are able to set up and run the application with the use of the instructions inside the README file.
|
|
|
|
|
|
|
|
|
## Scope (FURPS+)
|
|
|
* Functionality (functional requirements)
|
|
|
* Users should be able to log in to their account (in the app)
|
|
|
* The user/member should be able to search for leagues and teams
|
|
|
* The user should be able to join a team
|
|
|
* The user should be able to see members on their team
|
|
|
* The user should be able to see and add scores for games played by their team
|
|
|
* Team owners should be able to accept user requests to join their team
|
|
|
* The user should be able to edit their info in the app
|
|
|
* Usability
|
|
|
* Our app should be easily downloadable, which we will ensure by publishing on the Google play store
|
|
|
* Our app should be easily navigate-able by an average university student (including both our stakeholders, which are university students), and intuitive enough so that a user can use the basic functionality of the app without reading a manual/instructions
|
|
|
* App layout should be consistent for the user (i.e. navigation menu placed at the same location on all pages, etc.)
|
|
|
* Reliability
|
|
|
* Our app should be available 24/7 with minimal downtime (ideally 0 seconds)
|
|
|
* Since our app relies on the main point of storage being a server (firebase database), our app will be affected if any outages occur on this server. However, we will try to also store data locally on the phone, so that the user can use the app without being connected to the server (and then the app auto-syncs when connected to the server).
|
|
|
* Performance
|
|
|
* The app should look and feel smooth in terms of loading data, rendering the UI, and displaying animations (i.e. switching between screens). The user should not be able to notice the time between frames in an animation.
|
|
|
* Our app should also load within 3 seconds max. if we compare this time to a website, it will be faster than 50% of the web and corresponds with the time that the average user leaves a website if it has not loaded yet (https://www.bluecorona.com/blog/how-fast-should-website-be/). We will aim for 1-2 seconds load time, but 3 seconds will be our max.
|
|
|
* Supportability
|
|
|
* Our product (the app) will be published on the Google Play Store. Releasing updates/revisions will also be published on the Google Play Store, which is how our users will be able to update the app.
|
|
|
* Our system is very maintainable since we own (or have access to) all aspects of the app: Android Studio (which is where our app can be modified and features can be added), and Google firebase. Both of these things will be available and used by us even after the class is done this semester.
|
|
|
* Testing for this system will occur locally through Android Studio (unit tests by testing individual classes, and systems tests by using the Android emulator). Through the emulator, we will be able to test our app on a variety of phones and Android OS versions.
|
|
|
* Our app can also be easily modified (and features can be added), since all the source code can be edited on android Studio.
|
|
|
* "+" (design, implementation, interface, and physical constraints)
|
|
|
* Design Constraint: Since we are using firebase for database/cloud storage, our app needs to integrate this (and therefore only use the features available in firebase).
|
|
|
* Implementation Constraint: We are limited in construction of the app by our language, Java, which is the main language used for Android apps worldwide. Another limitation is using Android Studio which is the official/main IDE for android development.
|
|
|
* Interface Constraint: We self-imposed a restriction of programing for only Android 5.0 (lollipop) and up. This was selected because of our need to use modern functionality, while also supporting older phones. Developing an app for Android 5.0 and up satisfies 85% of the worldwide market (and larger in North America).
|
|
|
* Physical Constraint: One of our largest constraints is the size of a phone. We need to make an app that is usable in a relatively small format (and the various different sizes available for Android phones, which means our design/layout has to be adaptable). We also need to take into account the different shapes for Android phones available (i.e. notch vs no-notch, camera cutout, different aspect ratio, etc.).
|
|
|
|
|
|
|
|
|
## Roles and Responsibilities of Team Members
|
|
|
* Brayden
|
|
|
* Front End
|
|
|
* Responsible for All Leagues, League, Team and Member pages, pop-up pages, and the design theme for the application.
|
|
|
* Will ensure the theme is consistent throughout the application and each page is laid-out cleanly.
|
|
|
* Lee
|
|
|
* Back End
|
|
|
* Responsible for java classes, interfaces and assisting in database operations.
|
|
|
* Will ensure back end code is efficient and of sufficient quality.
|
|
|
* Jay:
|
|
|
* Front End
|
|
|
* Responsible for the complete sidebar navigation menu, icons, header bar, and home page
|
|
|
* Will ensure that user navigation is intuitive & smooth and that the respective GUI components work as expected.
|
|
|
* Shantanu
|
|
|
* Back End
|
|
|
* Responsible for Database and application integration with database for running query and log-in.
|
|
|
* Will ensure back end code is efficient and of sufficient quality, Also will take care for further API integration.
|
|
|
|
|
|
|
|
|
## Quality Assurance Principles
|
|
|
Good Quality Assurance relies on the three principles which we tried our best to implement at each stage of the development process.
|
... | ... | @@ -20,12 +75,20 @@ Good Quality Assurance relies on the three principles which we tried our best to |
|
|
|
|
|
## Quality Assurance Methods
|
|
|
These are the methods to used to see if the software being developed is meeting the standards that we and the clients have set for us. As mention above, we decided to focus on testing and inspection methods as they have the largest impact on the quality of the final product.
|
|
|
## Test Methodology
|
|
|
* Regression testing is applied at the unit level to each back-end java class in our model, each back-end java class has a corresponding testing class used for testing the methods and functionality of that particular class. The JUnit framework is used to support this. Unit testing is done by the developer who implemented the class itself, these tests are verified during inspection.
|
|
|
* The app is tested at the system level as new features are added, for example if a new screen is developed, the screen and its interactions with the rest of the system are tested and explored before the new changes are added to the repository. This testing takes the form of trying various inputs and actions with a test version of the application; for example if some database functionality is being tested, a developer might input various values to some interface and ensure that the correct values are written to the database by inspection. This may be done by the developer responsible for these changes, by the developer verifying or inspecting these changes during a merge, or both.
|
|
|
* Bugs can be reported informally in person or via slack to the relevant developer, or a new issue can be created describing the bug with the relevant developer assigned to the issue.
|
|
|
|
|
|
### Testing
|
|
|
For each of the classes that were made, we set up unit-testing for each of the methods that would be used in the application. Unit-testing provided us with a solid foundation knowing that these methods are working as expected so when moving up to higher-level code we could trust the functions that were being used.
|
|
|
|
|
|
One of the difficulties we ran into when determining the best way to test for an application was automating tests at the user interface level. We decided the best way to test this would be manual testing of the application between the four of us and anyone else we could get. Anytime a new feature was added in we would make sure to manually test the application for that feature and any of the code that it could affect. After having a handful of features built off each other, code would be tested each time one of these new features was being tested and we were able to find bugs this way.
|
|
|
|
|
|
## Inspection Methodology
|
|
|
* Code inspection and review occurs before a developer merges one of their branches back into our main development branch. By convention each developer creates a new branch whenever they have changes to make, once these changes are implemented and tested this branch is merged back into our development branch. At the time of this merge a developer asks another developer to look over and approve of their changes, the developer doing this inspection should be aware of the nature of the changes being made. For example asking a developer whose main focus is on the database to inspect change to the front-end user interface of the app is bad practice as the database is unrelated to the UI. The inspecting developer views the changes made, assesses code quality and does testing of their own. The inspecting developer then decides to accept and merge in the changes or deny them if quality is not met.
|
|
|
* No formal documentation or artifacts are produced during this process, an inspector may give informal verbal or written feedback to a developer however. Likewise there are no formal guidelines for code quality or practices, however quality requirements have been discussed as a group, and the judgement of each developer should be sufficient for a project of this size.
|
|
|
|
|
|
### Inspection
|
|
|
Before any code had been written we agreed to enforce the rule that merge-requests could not be accepted by the person who made it. This meant that at least one other person would need to read through the code changed before the merge was added to develop. This rule saved us a couple of times when the person inspecting found an issue that the requestee didn't notice when writing the code. Another important bonus of this rule was that we had a much better understanding of what everyone else in the group was working on, and if needed we were able to edit files that had been made by someone else because we all were on the same page from reviewing each other's code.
|
|
|
|
... | ... | @@ -36,6 +99,9 @@ We had weekly meetings for talking about which direction we were heading and wha |
|
|
## Acceptance Testing
|
|
|
Before we know our product is ready to be released, we have multiple stages of testing by our stakeholders', user-group, and any friends or family we can rope into it. Giving them control and asking them to explore the product on their own, then later guided, to see if they are able to understand how the application works without a given explanation. We also ask them to try and break the application so we can find bugs that might not have appeared during internal testing.
|
|
|
|
|
|
See [Acceptance Test Results](Acceptance-Test-Results)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... | ... | |