# SENG 426 - Group 13 - Delivery 3
**Automated Testing & Continuous Integration**

**Outline**
**Task I: Automated Functional Testing**
- Create an integration test suite using Selenium for all user stories related to:
- Bank account creation by customers
- Money transferring by customers
- Bank account management by Staff and Managers, including account approval
- New features
- Collect test execution results daily
- Plot defect arrival graph (showing daily progress)
- Comment on application’s quality (general comment covering different aspects of software quality)

**Task II: Implement New Functionalities and Fix Bugs**
- Implement the following new functionalities:
- Loan Payment Calculator
- Automatic Interest Credit
- Proposed feature
- All bugs related to the features covered by the integration test suite implemented in Task I fixed as well as some other high priority ones and if possible some minor ones
- Describe how the features were implemented and how bugs were fixed
- Log work time metrics on GitLab for each closed ticket
- Tabulate ticket data (priority, original estimation and actual time spent) for each closed ticket
- Calculate teams velocity or estimation accuracy
- Comment on expected progression of velocity/accuracy with time
- Comment on pros and cons of Story points ans Hours for task estimation
- Collect Jenkins data and reports (same as from previous assignment)
- Comment on CI utility during assignment and differences to real professional environment
- Create a release

**Rubrics**
- Test suite (40%)
- Coverage: All key behaviours and most secondary ones covered. Bugs have specific tests if they are not covered otherwise
- Correctness: Tests correctly asserts every necessary condition and only fails if related to a uncovered bug
- Quality: Tests are readable, deterministic, resilient to changes, independent and cover a single behaviour each. Suite is well structured and repetition is kept to a minimum
- Bug fixes (25%)
- Discovery: Bugs are found
- Correctness: Bugs are properly fixed (fix the issues without causing regressions)
- Quality: Code is readable, well organized, resilient to changes and repetition is kept to a minimum
- Implemented features (20%)
- Correctness: Features are properly implemented (do what they are supposed to do without causing regressions)
- Quality: Code is readable, well organized, resilient to changes and repetition is kept to a minimum
- Branching, PRs and release procedure (5%)
- GitHub model followed
- Pull Requests are reviewed and approved by at least one other team member
- Release created correctly
- Report (10%)
- General quality
- Descriptions of implementations and fixes
- Defect arrival graph
- Work time data and calculation
- Jenkins data
- Commentaries

**Delivery Requirements**
- [ ] 1. The release (tag) available on the group’s repository containing the updated code and the test suite;
- [ ] 2. The GitLab issues and Pull Requests;

**Report Requirements**
- [x] 1. The test cases with test data values;
- [x] 2. A description of the uncovered bugs;
- [x] 3. The defect arrival graph;
- [x] 4. Commentary on different quality characteristics of the released application before and after this part of the assignment;
- [x] 5. A description of how the new features were implemented;
- [ ] 6. The new user stories;
- [x] 7. Screenshots showing the Jenkins’ build history, trends and reports;
- [x] 8. Description of the pros and cons of using Story points or Hours for task estimation and the definition of which one was chosen;
- [x] 9. A table with the priority, estimation and actual time spent with each ticket created;
- [ ] 10. The velocity or estimation accuracy calculation;
- [x] 11. The consideration of whether and how the value would change with time;
- [x] 12. A commentary on whether doing CI provided any benefit or hindrance during this assignment that would be different in a real professional environment.

<!-- Report begins here -->

---

## Test Cases
### Account Creation
For the flow of a banking account by a user, the following tests were conceived. To cover the full breadth accounts available, this flow was modified to run for each of the account types available to users (Savings, chequing, credit, and loan).
### Test Flow
- Login as user
- Count the number of present accounts before adding
- Navigate to "Accounts" page
- Click the "Create Account" Button
- Fill out the account type for the test running
- Fill out any other user info
- Confirm account
- Verify that one account has been added to the list

To ensure all data was required to create an account, tests were added following the above flow, but omitting some data in order to ensure the proper error was shown.

### Login
For each of the types of users within the system (user, staff, manager, and admin) login through the main page was tested. These tests were considered passing if we were able to verify we reached a page with either the user menu dropdown, or in the admin/manager case, navbar items unique to their user type.
#### Test Data

| User Type | Login |
| --------- | --------- |
| User | lpaprocki |
| Staff | jbonano |
| Manager | asmith |
| Admin | pcosta |

### User Creation Management by Admin
For the admin user, a possible use cases were the creation and deletion of other users. To verify the system for these use cases, tests for deletion and creation flows were made, with the flow outlined below.
#### Test Flow
- Admin logs in
- Verify we can reach user management screen
- Create user as admin
- Verify this user has been created
- Delete the user through user management screen
- Verify user deleted

## Uncovered Bugs
- While investigating the previously reported reset failed to send bug, it was found that the service's link to a mail server was misconfigured. This resulted in new bugs, such as confirmation emails also not being sent, and the failure of this function not being logged as desired.
- While testing account creation, a bug was found where bank accounts could be generated with negative balance.

## Defect Arrival

## Quality Characteristics
The main quality characteristics of the application that were affected during bug fixing and testing are mainly functionality and usability. When putting testing efforts into finding and fixing bugs, the usability increases because the app is far less broken than before. Also adding new features, or new functions to the application will increase the functionality of the application, because you can do more things with the application.

## New Features

### Loan Payment Calculator
The loan payment calculator was implemented on a new page under the banking tab. It was implemented through a form on that page and the calculations are done completely on the front end. The form relays on the state of the form and will auto-update when any value is changed.

### News Notifications
For our own chosen feature, we chose to create notification for all users for every news entity added to the sight. This feature was implemented though features on the front and back end. The front end required a request to be sent every time the page loaded to get the number of new notifications were added along with a badge to display the number of notifications on top of the 'News & Updates' tab. Every time the user views the news page the notifications are then cleared.

On the back end of the notifications, a new notification entity was created to serve as a basic event log and so that the app can query for what a user hasn't seen. A new notification entity is created for each user each time a new news entity is create. This portion of code was added to the News routing, but interacted with the notification model. The basic CRUD control was added to the app for notification as well as a count route that would simply return the number of notifications of the queried user.

### Automatic Interest
For the automatic interest functionality was implemented completely through the back end. The app is started with the interest rate defined in the `application-xxx.yml` files, then every night interest is added to every account according to the account type and whether it is activated or not.

## Jenkins Builds
Due to the problems faced with the Jenkins pipeline. We are unable to comment on the effectiveness of it for this deliverable. Given the situation, having Jenkins has not yielded any benefits during development.

## Story Point vs. Hours
The benefit of using story points is it gives a good representation of the difficulty of a task for every level of skill. This contrasts with to having hours to represent the difficult as what may take an hour or two for one person, might take several hours for another person. It also avoids having to request the amount of time needed for a task as the difficulty is relative to other tasks, rather than the the time it took to do it. The cons of using story points is it fails to make it easy for estimating the resources it might take to complete a task. If all of the people on a team are of a similar skill level, then it might be beneficial to have hours instead of story points, as it will be easier to estimate how much time is required for a release of a product.

## Estimation

| Ticket | Priority | Estimation | Actual |
|:-------|:--------:|:----------:|:------:|
|Automated Interest | High | 3 day (24h) | 3h |
|Transaction filter fields | Medium | 2h | 30m |
|Cannot edit customer| High | 4h | 1h |
|Error 500 when sorting branch| Low | < 1h | 45m |
|Transaction amount can be negative | High | 2h | 45m |
|Admin cannot view customer details| Medium | 1-2h | 1h
|Admin cannot view branch | Medium | 1-2h | 30m |
|Unable to upload documents| High | 2h| 0h (non-issue) |
|Error 500 when deleting customer| Low |3h | 3h|
|News notifications| High | 24h | 8h |
|Loan payment calculator| High | 8h | 7h |
|Password strength indicator always weak| High| 2h | 0h (non-issue)|

## Commentary on Time Estimation
The times that we chose for the given task varied considerably from how long they actually took. If another round of estimation were to occur, then the estimations would probably be smaller in terms of time because we always finished before the actual estimation. Over time, if we were to continue working on the same project, team members would get more familiar with the system and probably find issues and fix them more easily.

## CI Commentary
The CI definitely gave a indication of some bugs that were not caught when making a quick change, but there was some aspects about Jenkins that were annoying. One of the major ones being that running Selenium on Jenkins was a very frustrating task due to the system environment. Another key aspect of why we thought that the CI was, and still is a hindrance is the fact that no instructor, ever, has taken into account the fact that there might be a lot of load on the server near the time of submission. The outcomes of the Selenium integration tests are a simple pass/fail, where it would probably be useful to have a visual attachment or video recording when it fails a test to avoid having to run the tests locally again.