... | ... | @@ -2,3 +2,41 @@ |
|
|
|
|
|
|
|
|
# Quality Assurance Plan
|
|
|
|
|
|
|
|
|
## Overview
|
|
|
Before we began writing our code we discussed how we were going to handle keeping a consistently acceptable level of quality. We decided for our Quality Assurance Plan that we would focus on the Testing and Inspection methods.
|
|
|
|
|
|
|
|
|
## 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.
|
|
|
1. Know what you are doing.
|
|
|
- This was the first large scale Android application for all of us so this was the most difficult to exercsie, because of this we took things slower and tried to research the best practice for each piece of code we added into the project. Once we felt we had a good enough understanding of the the piece we were going to add, we would begin and made sure to comment the thought process throughout so that the code would be understoon by the others during a code review.
|
|
|
2. Know what you should be doing.
|
|
|
- Because we had flushed out personas, epics, and user-stories this step went smoothly. Using user-stories and acceptance tests as a guide we had a goal in mind and were therefor able to write code with a purpose making it much easier to achieve what we set out to.
|
|
|
3. Know how to measure the difference.
|
|
|
- We decided for our project it would be best to focus on testing and inspection methods for measuring the difference between our goal and what we have achieved. Each of these will be talked about more in-depth below.
|
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
### 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 eachother, code would be tested each time one of these new features was being tested and we were able to find bugs this way.
|
|
|
|
|
|
### 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 atleast one other person would need to read through the code changed before the merge was added into develop. This rule saved us a couple 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 eachother's code.
|
|
|
|
|
|
We would take turns editing files to add new features which was helpful because it gave another set of eyes to previously implemented code which allowed us to look for opportunities for improvement if something was written in a way that could be improved upon.
|
|
|
|
|
|
We had weekly meetings for talking about which direction we were heading and what we have accomplished. Each person would give a brief rundown of things they implemented and how. If anything was deemed to not meet the standards set we would add an issue to the Issue Board on GitLab to be tackled by the person assigned.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|