diff --git a/README.md b/README.md index d393833..c20331b 100644 --- a/README.md +++ b/README.md @@ -22,6 +22,7 @@ We work with a number of different software platforms. Each has their own set of * 🗂 [Databases](general/databases.md) * 🛠 [DevOps](devops/devops.md) * 🔢 [Style Guides](styleguides/styleguides.md) +* 🚦 [Quality Assurance](quality-assurance/core.md) * 📖 [Open Source Projects](general/open-source.md) * ✏️ Design * [✍️ Design Tools and Resources](design/design-tools.md) diff --git a/quality-assurance/core.md b/quality-assurance/core.md new file mode 100644 index 0000000..ecc73ea --- /dev/null +++ b/quality-assurance/core.md @@ -0,0 +1,193 @@ +# 🚦 Langley Foxall Quality Assurance + +When building applications that run an entire business end-to-end - it's important that we adhere to high quality +assurance standards in order to consistently deliver a high quality software project. + +There are different parts/processes to quality assurance as a whole, and these are not limited to just manual testing and +automated testing. + +* [What makes a good web application?](#what-makes-a-good-web-application) + * [Blackbox](#blackbox) + * [Whitebox](#whitebox) +* [Processes](#processes) + * [Automated Testing](#automated-testing) + * [Manual Testing](#manual-testing) + +## What makes a good web application? +The following is a checklist of things to think about both during development of a product and during the quality +assurance phase. They should be considered guidelines, and not a strict set of requirements, as not all points will be applicable or appropriate for all applications. + +### 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 asynchronously +* 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 +* An icon that is appropriate for the page (if applicable) + +**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** +* Users can only access pages they are permitted access to. +* Authentication when they are logged in +* Login, registration (if applicable) and 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 URIs + +**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 (UserController.php) +* Classes must follow standard coding conventions (UserController) +* Variables should follow camelCase & be descriptive (myName) +* All long running operations (at your discretion) are queued +* APIs follow REST architecture as closely as possible and implement our [API Response](https://github.com/langleyfoxall/helpers-laravel#apiresponse) +* API responses hide sensitive information outside of what is absolutely necessary. +* 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. +* Log viewers are hidden behind a protected route + +**Controllers** +* 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 +* Ensure appropriate permissions on files in applicable (sensitive documents are private, avatars are public etc) + +**Queues** +* Queues use Redis unless agreed beforehand +* Ensure appropriate measures are in place for handling failed jobs + +**Broadcasting** +* Broadcasting uses Laravel Echo unless agreed beforehand +* 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 +* Large tables that are queried often are indexed in order to keep database speed up + +## Processes +### Automated Testing + +Automated testing should be implemented in a way to confirm functionality specified by the client. +To this end, automated tests should be created to confirm the project user stories and related +business logic is satisfied and correct. + +#### Unit Testing + +Our current policy is that unit tests should be used for: + +* Testing of project business logic / rules, that are able to be sufficient abstracted +* Testing of packages, including our open source work + +#### Integration, Browser & End-to-End Testing + +Integration, browser and end-to-end tests should be used for: + +* Testing of project functionality related to client specified user stories +* Testing of critical path functionality, such as the register, login, and checkout process of an +ecommerce site + +Since end-to-end tests are slower than browser tests and browser tests are slower than integration +tests, you should ideally aim to use the fastest possible test type, if appropriate. +### Manual Testing +#### 1 - Developer Testing +During the development of the project, developers will create branches as described in our git work flow documentation. +After the initial feature development - the developer should manually test their feature after writing passing +[automation tests](#automated-testing). This phase should also include a check that ensures the feature does not infringe +any of the items listed in the ["What makes a good web application?"](#what-makes-a-good-web-application) section. + +Once the feature has the thumbs up from the developer - that is when the feature can continue through our +[Git Workflow](/devops/git/workflow.html) + +The developers should log any bugs found in this phase into JIRA to improve their ratio of bugs they find VS bugs that +get through to the QA team/customer. + +#### 2 - Sprint Testing (On the master branch) +At the end of each sprint the Lead Developer on the project should arrange some time with a member of the QA team to +manually test all completed user stories in that sprint. + +They should look to give the functionality a complete test, using any available acceptance criteria provided with the +story. Testers should also ensure that the UX seems correct, that all inputs are validated correctly and data is +retained where appropriate. + +#### 3 - S2P Testing (Staging server) +Staging to production testing should be focused around the user flow of the system. + +Users should start with a fresh, clear database and work on the journey of the system end-to-end. Using the different +user types, the tests should ensure that the customers workflow is satisfied from input to output.