Quality Assurance - QA Stages, Formatting, Guidelines and Web Quality Assurance Handbook

README.md

@@ -16,5 +16,8 @@ We work with a number of different software platforms. Each has their own set of
   * [📲 React Native](platforms/mobile/react-native/introduction.md)
 * 🖥 Desktop
   * [🖼 Windows apps](platforms/desktop/windows.md)
+* ✅ Quality Assurance
+  * [♻️ QA Stages, Formatting and GuideLines](qualityassurance/qastagesformattingguidelines.md)
+  * [📗 Web Quality Assurance Handbook](qualityassurance/webqualityassurancehandbook.md)
 * 🛠 [DevOps](devops/devops.md)
 * 🔢 [Style Guides](styleguides/styleguides.md)

qualityassurance/qastagesformattingguidelines.md

@@ -0,0 +1,88 @@
+# ♻️ QA Testing Stages, Formatting and GuideLines
+
+This Section is to instruct on when to test, how you should be formatting the Bugs raised and GuideLines for QA
+
+## Developing with QA in mind
+
+### Commands
+When you are developing the project the project might require commands to run and work correctly, these can range from simple set up commands to automatic updating commands, a list of these commands and a breif description of what these commands do will help QA move more smoothly and avoid raising unnecessary questions.
+
+Some projects requires certain status or manipulation of the database to update systems and cause it to do the next stage/part of the system to test. We would like these to be formed into Commands, QA should not need to touch the database side to test the system, this leads to user error and this is leading it away from how the customer would user the system. So these processes need to put into commands where it will update the database for the required data with the correct process to ensure that it is changed to how the system will change it when on live.
+
+### ENV
+Ensure that the 'env.example' is update and remove redundant fields/areas that are not required anymore.
+
+## QA Stages
+
+For staging we are following a multi stage testing to enable us to ensure that the customer is getting a bug free and fully functioning system. This will be a merge between Agile and Waterfall.
+
+### Stage 1 - Dev Testing:
+This stage is for the Developers to test and ensure that there are not obvious bugs and that the code is working as expected before they create a PR (Pull Request), This will ensure that QA is not wasting time on obvious bugs that could have easily been spotted during development and be fix them before the pull request is made.
+
+### Stage 2 – PR (Pull Request) Testing:
+At this stage the PR has been created and this requires 2 steps of acceptance.
+One check will be from a member of the Developer Team to check over the code is to review the code itself. 
+The other Check will be from QA, that will test the code changes itself, ensure that it is working and there are not bugs in the relevant area. This is more of a Spotlight Check, testing around each change that has been made and near areas that could be affected by this change, this will have a high density of testing to ensure that we catch as many bugs as possible, no matter how small or unlikely the bug appears all bugs must be reported.
+Once Both parties have accepted the code we will then go onto Stage 3.
+
+### Stage 3 – M2S (Master to Staging) Testing:
+This area of testing is large end to end testing, This means that in terms of testing, we start of as a brand new user, with a cleared database (as much as can be cleared), This testing will go through the flows the customer will follow, This will require multiple user type testing such as (Client, Admin, User, Operative, Ect..), This will span through to an App if the customer has an App, Even if no changes have been made to the App. This will ensure that the customer flow will be clear and will be able to with confidence be able to say that this project works.
+
+### Stage 4 - Prod Testing:
+This area of testing is to test all key functionally of the application on prod to ensure that the application can function and does function as expected.
+If any issues are found on Prod these need to be raised as a HotFix request and to ensure that it get fixes as soon as possible.
+
+#### Staging - Prod Merge Timing
+Timing is a very important point in the merge between Staging and Prod, We do not want to do it at peak working hours as if something does go wrong it doesn't effect our customers and doesn't impact on our relationship to them. We also do not want to do it on a Friday or before any period that we will not be in the office for a few days. As we want to be able to fix the issue as fast as possible and not make the customer wait. Preferably this merge would be done at night with both Q/A and Dev in incase something does need fixing, But this is not possible. Every customer is different to when it would be best to merge, So ask if in doubt ask the project lead or a manager to when they would advise the merge.
+
+## Test Cycle
+
+Test cycles are a collection of tests that need to be ran. Cycles should always be given a time frame and a time estimate to ensure that we are completing them in a timely manner and to enable management to work out work flows.
+
+### Tests
+For Stage 2, Stage 3 and stage 4, a list of tests is required, this is to keep track of what needs to be tested and to ensure that all functionality is tested and to ensure we don't do any unnecessary testing.
+The structure of the tests are as follows:
+- Test Name
+- Priority
+    - Critical
+    - High
+    - Medium
+    - Low
+- Expected Outcome
+- Estimated time to complete testing
+- Area of Testing (Such as the what Pages/Screens)
+- Test Data (If Required)
+
+### Testing Status
+Each test requires a status once completed. The Status are as follows;
+- Passed – The testing passed and has been confirmed to work as expected.
+	- Data Required 
+		- Notes.
+		- Test data used.
+		- Screenshots if relevant.
+		- Your Name.
+- Failed – The testing failed and is not working as expected.
+	- Data Required
+		- Notes.
+		- Test Data used.
+		- Bug Number Raised.
+		- Your Name.
+- Blocked – Testing has not been started as can’t be tested due to a Bug Already Raised by a failed test.
+	- Data Required
+		- Notes.
+		- Bug Number Raised.
+		- Your Name.
+- OOS (Out of Scope) – Test has been moved to OOS as it is not in the scope of testing for this Stage of Testing.
+	- Data Required
+		- Manager who confirmed OOS.
+		- Your Name.
+
+### Raising A Bug
+
+When you find a bug, you will need to raise a bug on the Jira Service Desk.
+This bug will require multiple areas to be filled in, these are as Below:
+
+![Jira Bug Raising](images/jira/raising-bugs.PNG)
+
+### Test Data
+When testing on Staging and Prod we will require valid data and logons to access the system. These should be stored in a Google Docs that the Project Lead/Manager should have access to, These should be kept up to date. This should contain data that you need or is helpful to have when you are testing the given project. 

qualityassurance/webqualityassurancehandbook.md

@@ -0,0 +1,162 @@
+# 📗 Web Quality Assurance Handbook
+
+
+Test extensively against assumptions in Jira, at the end of the day this is what the client is paying for. Below is a list of bullet points for common individual sections of a Laravel web app, although a lot of the core concepts apply regardless of web technology used (events bus, queues etc are all common design patterns)
+
+
+It should be used as a guide to ensure a great & consistent experience for the end user.
+
+
+### Blackbox
+
+#### General
+-  All UI scales well and looks good on small form factor devices
+-  All errors are handled and UI reacts appropriately
+-  Errors are clear in meaning & reflect what happened
+-  Activity indicators are used when loading data async
+-  Empty information is handled correctly in UI (optional fields etc)
+-  Long running operations give a indication of progress if possible
+-  Breadcrumbs are used where appropriate
+
+
+#### Navbar
+-  UI reflects the current active page
+-  Icon is appropriate for the page
+
+
+#### Forms
+-  Invalid inputs correctly trigger validation errors
+-  All form inputs have associated labels
+-  Appropriate validation for different inputs (phone number, postcode)
+-  The forms are not too long & and are grouped logically
+-  The user is alerted of the form lifecycle (success, error)
+-  When modals are used in the context of updates, ensure inputs are correctly pre populated.
+-  Autofill is disabled on inputs where appropriate
+-  Inputs have correct type property ( emails have email type, phone numbers have tel type)
+
+
+#### Modals
+-  Modals are animated on both display and dismiss
+-  Modals are used where appropriate over pages
+
+
+#### Formatting
+-  Dates are formatted correctly for the appropriate audience.
+-  Monetary values are formatted correctly for the appropriate audience
+-  Phone numbers are formatted correctly for the appropriate audience
+
+
+#### Pagination
+-  UI correctly indicates current page
+-  UI shows at least 2 page tabs ahead and below the current page
+
+
+#### Login & Auth
+-  User can only access pages that require 
+-  Authentication when they are logged in
+-  Login & Logout works as expected
+-  Reset password works as expected
+
+
+#### Registration
+-  Email addresses are verified & unique (if applicable)
+-  Passwords meet minimum standards (min 8 chars)
+-  Passwords should not have maximum length restrictions (allow at least 255 characters).
+
+
+#### Emails
+-  Emails look good on small form factor devices
+-  Ensure correct subject & sender name
+-  Correct email is sent, information is conveyed appropriately
+-  Emails are received in a timely manner
+-  Emails come from the appropriate email (often the clients)
+-  Links point to the correct address
+
+
+#### Push Notifications
+-  Push notifications are received in a timely manner
+-  They show correct & relevant information
+
+
+#### Permissions & Roles
+-  Ensure permissions & roles match up to possible actions (only admins can create users etc)
+
+
+### Whitebox
+
+#### General
+-  Filenames must follow standard coding conventions (UsersController.php)
+-  Classes must follow standard coding conventions ( UsersController)
+-  Variables should follow camelCase & be descriptive (myName)
+-  All long running operations (at your discretion) are queued
+-  APIs follow REST architecture as closely as possible
+-  Auth middleware is setup & working correctly
+-  Event system is used for method side effects (Audit trail etc)
+-  Laravel Notifications are used to notify the user of system events (subscription expired, new friend request etc)
+-  Sensitive values are either hashed or encrypted (when required by law or common sense)
+-  Third party API integrations that can & will be re-used across projects should be implemented as external packages, assuming no existing open-source integration exists, to allow for independent testing and code reuse if appropriate.
+-  Ensure third party API keys (e.g. SES keys) are not present within .env.example and other relevant files outside of the production / development environments.
+-  If Travis CI is being used, ensure third party API keys are input directly into Travis CI’s website relevant to the project and make sure “Display value in build log” is not checked.
+
+
+#### Controllers
+-  Ensure each controller function does not go over 250 lines
+-  Be on the lookout for duplicated code - recommend refactoring into helper classes or models if so
+-  Ensure all requests are validated either through a validator or custom request
+-  Errors are handled correctly in try catch blocks
+-  Responses are returned in a consistent & logical format
+-  Only appropriate & relevant information is returned
+-  When returning JSON ensure the returned JSON conforms to the JSON spec (http://json-schema.org/specification.html)
+-  Appropriate status codes are set
+
+
+#### Emails
+-  Emails use the SES driver unless agreed beforehand
+-  All emails are queued up for sending
+-  Only relevant information is passed to the mailable instance
+
+
+#### Views
+-  Loading of assets (js/html) use the `asset` global helper
+-  Blade layout system is used where appropriate (@extends, @yield)
+-  Components are split out logically where appropriate, make use of Laravel’s powerful blade templating system if appropriate (clientCard, navbar etc)
+
+
+#### Service Providers
+-  Service Providers are utilised where appropriate to bind classes into the container (API interfaces etc)
+
+
+#### File Storage
+-  Files are stored on S3 unless requested by the client to be stored locally or agreed beforehand by the project manager
+-  Ensure appropriate permissions on files in applicable (sensitive documents are private, avatars are public etc)
+
+
+#### Queues
+-  Queues use Redis unless agreed beforehand by the project manager
+-  Ensure appropriate measures are in place for handling failed jobs
+
+
+#### Broadcasting
+-  Broadcasting uses Laravel Echo unless agreed beforehand by the project manager
+-  Ensure appropriate authentication & security for each channel
+
+
+#### Database
+-  All migrations use foreign keys for relations to ensure database integrity
+-  SQL data types are appropriate
+   -  Monetary values should either be stored in pence as an INTEGER or as a DECIMAL - Never a FLOAT
+   -  Long strings (descriptions) should be stored as TEXT, other string can be stored as a VARCHAR - Ensure controller validation for VARCHAR fields have a max string length of 255
+-  Tables are named appropriately with underscores in lieu of other word separators
+
+
+#### Cache
+-  Ensure appropriate values are cached where appropriate. (bonus points)
+
+
+
+
+
+
+          Langley Foxall Ltd
+	              Schott House, Drummond Rd, Stafford, ST16 3EL
+	 [email protected]