# **MyscannarApp** #

## **CA326 Testing Documentation** ##

Comfort Dopamu & Mahjabeen Soomro

## Table of contents ##

We need to have all these implemented. Only part 2 is done to satisfactory
* [1.Interface Testing](#1-interface-testing)
* [2.Unit Testing](#2-Unit-Testing)
* [3.Android Studio logs](#3-android-studio-logs)
* [4. Website Testing](#4-website-testing)
* [5.Dummy Testing](#5-dummy-testing)
* [6.Heuristic Analysis](#6-heuristic-analysis)

## 1.Interface Testing
We tested MyScanner app on HTC dual sim and TECHNO mobile phone; here are the screenshots from both phones.

## 2.Unit Testing
We decided to do some unit testing to test some of our methods that were used often and contained any user input. While users use this so often, it is important to perform tests to decrease risk of something going wrong.

We unit tested the following:

### Scan code Testing
If the qr code is empty, this might cause the app to crash. The test did the following:
* Allows users to scan both strings and digits.
* Makes sure to check for empty qr codes to prevent the app from stopping.
* Makes sure the qr code string length is not greater than 15.

### View Attendance Testing
Arraylist and shared preference saving
We created two function test on the methods that were used in the view attendance activty. Adding items to arraylist and saving them in shared preference usign google gson as well.

The test did the following :
* Prevented the arraylist from adding empty strings.
* Removes whitespace and returns the strings after converting to lowercase.
* Shared preference allows arraylist to be stored as long as it is not empty.
* shared preference saves and retrives arraylist.

### Register Testing
We used both android sqlite and flask mySql for the user registeration and login authentication. We however, made unit test to test the email address the users register with. They contain the following functionalities:
* The passord must be in the correct form using "@".
* The password must contain at least 6 characters.

### Password and module checking
We created functions to test the module code and the password. These test cases limit the number of errors the users can make while creating an account such as:
* Prevent users from submiting empty module code
* Whitespaces must be removed.
* return the module codes in lowercase

## 3.Android Studio logs
Inorder to continuously track our progress, we used android studio log cat. This helped to display any error we encounter such as programming error, we were able to debug our android app easily.
We also used log cat to display json data sent from our server to android studio and data sent from android app to the server. It is impossible to track our progress as it needs to be tested on an android app, however the logcat provided by android studio tremendously helped us to keep track of all our errors. Whenever we added to our dependencies in the build gradle, we were notified to sync our project immediately. Logcat made debugging easier.
This image shows how 'Log.d' alowed use to view the qr code string that we scanned.
Log cat also allows us to view our connection to the server, if the server page is unresponsive we are notified. Below is an example of a server error when we attempted to login

## 4. Website Testing
It is complicated to test the website for any errors and what must have caused the error. The common website errors are 400,404 and 500; while we get the errors it is hard to tell what leads to this error. We decided to use our terminal to get the passed data from android studio to the app. We were then able to see that information was being sent to the server that could cause the website to crash. When we send a post request from the android app to the server we were able to view the information by printing the post parameter sent.
Here is an example of a users information being sent to the server.
A user attempted to login without inputing thier username and password, thus this could have caused an error in the log cat but we were able to view the real reason behind the error. The second 'LOG CALLED' shows us what the user entered during their login.

## 5.Dummy Testing
We performed dummy testing in replace to actual users testing this app, this allowed us to see how the website would look if our app were to be used.
The above image showed us the students who have scanned the provided qr code, the qr code that was scanned and the Date with time that this occured.
The below image shows how many student are registerd with their username, email, ID and module.

## 6. Heuristic Analysis
Our primary goal is to make an attendance tracking device to be used in schools by students. In order to mae use of this app, it must be accessible to all. In order to make this app accessible and easy to use, we ensured the following:
* Used same theme for every activty
* Made text big enough to read
* Made buttons big and obvious
* Place scan button in the middle
* Used the right layout(Home activity should open after login page)
* Make use of 'Toast' to display error message and flash quick message

We also made the website simple to use and navigate. It primary goal is to view the students who scanned the qr code as it indicates that they attended lecture. We ensured the following
* The lecture can use the search button to filter students of a specific class.
* The pages have same stylings
* Used same colour for all pages
* lecture must be logged in to see students attendance