Intended Testing Plan
Unit Testing
The only part of our app that is easily accessible to unit testing is the map. Specifically, we aim to write some unit tests in Swift that will check the expected behavior of user-map interactions. For instance, we plan to write tests that will show whether a specific coordinate on the map lies on any of the touchable greens.
Integration/System Testing
To expedite the system testing, we have launched our app on TestFlight and have distributed the app to several UNC Golf team members (and we also downloaded it on our phones) for feedback. This allows us to catch any obvious bugs early on and make changes so that the finished product can be mostly bug free. Moreover, when we make changes to one branch (or feature), we make sure the entire team builds the simulated version of the app and tests out the feature before merging it with the main branch. As we get closer to the end of the semester, our process will remain the same as this testing system has proven to be effective.
Specifically, our process consists of the following: first we build the app and simulate it on a few different versions of the iPhone. Then, we start by interacting with the drills section by viewing drills and entering in dummy data for the records. We also test out the admin portion of the app by adding and removing drills to ensure that this functionality remains working. Next, we move to the map, where we move around the pin to test out the distance calculations. We also switch tabs to make sure that there are no bugs when the user performs this action. Lastly, we test out the activity page to check the behavior of when we click on “attempt now” for a given drill.
Performance/Reliability Testing
One of our goals is to cache of the data locally on the user’s phone so the number of reads and writes to the firebase database is reduced. In part, this helps the app’s overall performance; however, it also enables us the client to not have to pay for using the database (as firebase has a free tier for any app that uses less than N number of reads/writes).
Additionally, our app uses Firebase’s cloud functions, and even given our small testing size, we are getting close to hitting the free tier limit. Thus, our aim is to spend the next month figuring out how to make this process for efficient.
Acceptance Testing
Our team has already given our client a prototype of the app through TestFlight, which has enabled us to get continuous feedback on the features. With every feature modification, the entire team tests the behavior of the app before handing it off to the client for more critiques. To assist the client and provide us with more diverse feedback, we have also distributed the app the members of the golf team, who use the app regularly to identify bugs and features that they would like to see included. As we close out the final month of the semester, our aim is to spend a lot more time ensuring that the behavior of the app is as the client intended, and that the app itself is mostly bug free!
Tools
We plan on using the XCTest framework to test the map features. This is the most reliable (and documented!) way to test Swift code, and thus we aim to employ it soon.
End Users
Our end users consist of two groups: the admin and the default users. They both will end up using the iPhone app; however, the list of features differs for both groups. This, of course, means that the app is not open to users who do not have an iPhone, but our client insisted that this would not be a problem as everyone on the golf team has access to an apple product to download and use the app.
Idealized Testing Plan
Unit Testing
Ideally, we would want to employ unit tests everywhere possible to ensure that the app is free of bugs. Mainly, we would want to make sure that our sorting algorithms for displaying the leaderboard is correct and our filtering algorithms also work when adding and deleting new drills. Currently, we are just testing this behavior by seeing if our algorithm produces the expected results; however, this is not a guarantee that it works in all edge cases.
Integration/System Testing
If we had a lot more time, we would try to make sure that UI works perfectly as expected–especially for the drills section. Recently, we noticed that there were a few bugs when the user types large negative scores when recording their drill performance. It is probably fair to say that there are similar bugs like this that can only be caught by extensive testing.
Performance/Reliability Testing
Ideally, we would like to test out how the app performs when all of the golf team members uses it at once and whether daily use would push the app to send out too many firebase reads/writes that the client would have to pay for them. Additionally, we would like to test out the reliability of the map by going out to the course ensuring that this distance calculation is accurate; however, we may not be able to exhaustively test this out given our time constraints.
Acceptance Testing
Given infinite time and resources, we would try to distribute the app to both the golf team coaches and student athletes. This would give us a lot more feedback on the app and allow us to restructure in ways that would benefit our client the most. Additionally, we design the app for the apple watch and android devices as we can anticipate that feature users may prefer using these devices instead of their iPhone.