Feature	Verification Plan
General Requirements
Users must be able to sign up and create a profile	Manually create two users First user has valid formatted email address ([email protected]), valid password (between 6 and 100 characters) and confirmed password. Once created, page is the Gallery with user logged in. Then press logout, user should also be on gallery. Second user has same email as first user, with valid passwords. Account should not be able to be created, with warning specifying that email is already being used.
Style Gallery
Each page should display 8 styles with pagination (pagination: allow to page through results). Users must also be able to flip through the paginations.	Navigate to webpage on mobile device and verify that at most eight images are loaded by scrolling down through them. At bottom of first page, verify that user can only navigate to the right (next page). On second page, verify that user can navigate back (the last 8 styles) and that they cannot navigate forward if the page loads less than eight images or there are no more styles to show.
Users, upon entering the Style Gallery, shall see a default set of hairstyles based on the amount of ‘likes’ the record has sorted in descending order.	This functionality will be manually tested by assigning ‘likes’ to 10 records within our database ranging from 0-9 and loading the Style Gallery page. We will confirm that the records are displayed in descending order based on the number of likes. The page will be reloaded no less than 5 times in order to confirm the above action.
Should a user like to filter results, they may change the filter field(s) and on click of an “Update” button, the results will be updated accordingly by reloading the page.	We will be loading webpage and trying each filter option individually, and checking to see that results, once submitted, are loaded and only applicable for the given filter. Then combinations of all available filters should be tried.
Users must be able to bookmark and un-bookmark (“star”) styles. Each style will have an accompanied “star” ☆. An empty star ☆ indicates an un-bookmarked style A filled star ★ indicates a bookmarked style. On each click of the star changes whether or not a style is bookmarked. These stars are tallied to present a criteria for loading most relevant styles	In order to test the functionality of the star, the style icon will be manually selected to confirm it changes to a filled in star and unselected to confirm it changes to an empty star. Styles will also be favored on a blank instance and then the webpage reloaded to see if they become the most relevant in a non-filtered view of the gallery. Additionally, we will manually view the “favorites tab” after favoriting five records to confirm that the favored hairstyle appears in that section.
Hair cut log (the “Hairy diary”)
Users must be able to upload images to their haircut log	We will write unit tests that test the dependents of the “Blob Bob” component to verify that the upload image logic is correct
Users should be able to record and view the details of every hair cut log entry	We will manually verify this functionality by logging into an existing account and creating an entry. We will input text into each of the fields. We will then confirm that the record can be viewed by manually clicking on it and viewing it.
Need To Know
This page must present enough key hair cut concepts that a user could learn all of them and then engage with a barber in surface level conversation about the technical details of the haircut they want (assuming they have a particular one in mind).	We will manually inspect the text content in the need to know page by impersonating a user persona of someone who is in need of knowledge instruction and evaluating how well they would be able to communicate their hair cut given only the knowledge we provide on this page.

We organized our branching strategy to promote good verification practices. We have a master branch for production code, a dev branch for staging changes, and feature branches for volatile development. We agreed as a group to never push broken code to master. We are treating our master branch as a live production environment. That is why we have dev, where we can stage our integrated changes and do testing in there before pushing to master. We will use pull requests to merge changes into master, and require that at least one other person review a pull request before accepting it into master.