From 77f309721716aaa1771264ec811c19a011e1b9ec Mon Sep 17 00:00:00 2001 From: Jared Wheatley Date: Thu, 1 Nov 2018 15:43:09 +0000 Subject: [PATCH 01/20] Start of quality assurance section --- README.md | 1 + quality-assurance/core.md | 173 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 174 insertions(+) create mode 100644 quality-assurance/core.md diff --git a/README.md b/README.md index ed82887..dad44fb 100644 --- a/README.md +++ b/README.md @@ -18,3 +18,4 @@ We work with a number of different software platforms. Each has their own set of * [🖼 Windows apps](platforms/desktop/windows.md) * 🛠 [DevOps](devops/devops.md) * 🔢 [Style Guides](styleguides/styleguides.md) +* 🚦 [Quality Assurance](quality-assurance/core.md) diff --git a/quality-assurance/core.md b/quality-assurance/core.md new file mode 100644 index 0000000..ba2e29c --- /dev/null +++ b/quality-assurance/core.md @@ -0,0 +1,173 @@ +# 🚦 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) + * [Stages of Testing](#stages-of-testing) + * [Whitebox](#whitebox) + +## 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. + +### 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 +* 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. +* Log viewers are hidden behind a protected route + +**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 +* 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 +#### Browser Testing +#### Unit Testing +#### Integration Testing + +### Manual Testing +#### Stages of Testing +##### 1 - Developer 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 PR. + +This should happen before the commit to ensure that none of the above points are infringed. + +##### 2 - Sprint 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 + +##### 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, Engineer, 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. \ No newline at end of file From cb1628bcd5dd3cab7a0c326ae1c55981830ccfc8 Mon Sep 17 00:00:00 2001 From: Jared Wheatley Date: Mon, 26 Nov 2018 16:24:13 +0000 Subject: [PATCH 02/20] Further developed QA Process --- quality-assurance/core.md | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index ba2e29c..acd2267 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -143,9 +143,9 @@ appropriate (clientCard, navbar etc) ## Processes ### Automated Testing -#### Browser Testing #### Unit Testing #### Integration Testing +#### Browser Testing ### Manual Testing #### Stages of Testing @@ -154,19 +154,22 @@ This stage is for the Developers to test and ensure that there are not obvious b 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 PR. -This should happen before the commit to ensure that none of the above points are infringed. +This should happen before the PR to ensure that none of the above points are infringed. If a developer finds a bug, it +should get reported into JIRA before being fixed. This is to build up the developer's KPI's - showing that they are +finding a higher ratio of bugs than QA. ##### 2 - Sprint 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 - -##### 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 +At the end of each sprint a member of QA team will look to test the code that is pushed to the `master` branch. +This is to 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 and fixed before the code goes to `staging`. + +QA should look to test all assumptions that were marked as completed in that sprint by the developers. + +##### 3 - M2P (Production) Testing +Finally, M2P testing is large end to end tests. 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, Engineer, 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 From 2592b3f1af4b99ce730aac408dd41e1c98dabe26 Mon Sep 17 00:00:00 2001 From: Jared Wheatley Date: Tue, 11 Dec 2018 11:24:32 +0000 Subject: [PATCH 03/20] Start rewording manual testing section for initial push --- quality-assurance/core.md | 41 ++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index acd2267..9cd1569 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -11,6 +11,8 @@ automated testing. * [Whitebox](#whitebox) * [Processes](#processes) * [Stages of Testing](#stages-of-testing) + * [Automated Testing](#automated-testing) + * [Manual Testing](#manual-testing) * [Whitebox](#whitebox) ## What makes a good web application? @@ -144,22 +146,33 @@ appropriate (clientCard, navbar etc) ## Processes ### Automated Testing #### Unit Testing +Unit tests are to be utilised more so in our packages than in full products. #### Integration Testing +Integration tests are to be utilised more so in our full projects than in our packages. #### Browser Testing +TBC ### Manual Testing -#### Stages of Testing -##### 1 - Developer 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 PR. - -This should happen before the PR to ensure that none of the above points are infringed. If a developer finds a bug, it -should get reported into JIRA before being fixed. This is to build up the developer's KPI's - showing that they are -finding a higher ratio of bugs than QA. - -##### 2 - Sprint Testing -At the end of each sprint a member of QA team will look to test the code that is pushed to the `master` branch. +#### 1 - Developer Testing +During the development of the project, developers will create `feature/*` branches for all features going into the software. +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 pull request into the `master` branch should be +made. + +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 +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 + +OLD: +At the end of each sprint a member of QA team will look to test the code that is pushed to the `staging` branch. This is to 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 @@ -168,7 +181,9 @@ no matter how small or unlikely the bug appears all bugs must be reported and fi QA should look to test all assumptions that were marked as completed in that sprint by the developers. -##### 3 - M2P (Production) Testing +#### 3 - M2P (Production) Testing +--NEED TO REWORD-- + Finally, M2P testing is large end to end tests. 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, Engineer, Ect..), This will span From 9eee1ef444611c3a10e3d55ca5a081ebb0e80dbd Mon Sep 17 00:00:00 2001 From: Jordan Hall Date: Tue, 11 Dec 2018 11:47:58 +0000 Subject: [PATCH 04/20] Automated testing copy --- quality-assurance/core.md | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 9cd1569..373d03e 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -145,12 +145,28 @@ appropriate (clientCard, navbar etc) ## 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 -Unit tests are to be utilised more so in our packages than in full products. -#### Integration Testing -Integration tests are to be utilised more so in our full projects than in our packages. -#### Browser Testing -TBC + +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 From 785a84ec2ba3e2306f6474314107e25be6cb58b3 Mon Sep 17 00:00:00 2001 From: Jared Wheatley Date: Tue, 11 Dec 2018 13:32:27 +0000 Subject: [PATCH 05/20] /quality-assurance: --- quality-assurance/core.md | 41 +++++++++++++-------------------------- 1 file changed, 14 insertions(+), 27 deletions(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 373d03e..69497ee 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -6,14 +6,12 @@ assurance standards in order to consistently deliver a high quality software pro 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?) +* [What makes a good web application?](#what-makes-a-good-web-application) * [Blackbox](#blackbox) * [Whitebox](#whitebox) * [Processes](#processes) - * [Stages of Testing](#stages-of-testing) - * [Automated Testing](#automated-testing) - * [Manual Testing](#manual-testing) - * [Whitebox](#whitebox) + * [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 @@ -157,7 +155,7 @@ 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 & End-to-End Testing Integration, browser and end-to-end tests should be used for: @@ -167,13 +165,13 @@ 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. - +e ### Manual Testing #### 1 - Developer Testing During the development of the project, developers will create `feature/*` branches for all features going into the software. 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. +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 pull request into the `master` branch should be made. @@ -181,27 +179,16 @@ made. 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 +#### 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 - -OLD: -At the end of each sprint a member of QA team will look to test the code that is pushed to the `staging` branch. -This is to 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 and fixed before the code goes to `staging`. - -QA should look to test all assumptions that were marked as completed in that sprint by the developers. +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 - M2P (Production) Testing ---NEED TO REWORD-- +#### 3 - S2P Testing (Staging server) +Staging to production testing should be focused around the user flow of the system. -Finally, M2P testing is large end to end tests. 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, Engineer, 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. \ No newline at end of file +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. \ No newline at end of file From 055cd24825c2784fee705519aca55b5fa0321446 Mon Sep 17 00:00:00 2001 From: Ash Date: Tue, 11 Dec 2018 16:07:28 +0000 Subject: [PATCH 06/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 69497ee..af1d3b8 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -57,7 +57,7 @@ assurance phase. **Login & Auth** * User can only access pages that require * Authentication when they are logged in -* Login & Logout works as expected +* Login, registration (if applicable) and logout works as expected. * Reset password works as expected **Registration** @@ -191,4 +191,4 @@ retained where appropriate. 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. \ No newline at end of file +user types, the tests should ensure that the customers workflow is satisfied from input to output. From cf4301729e583d615e29ee2e8b55ad407f79301c Mon Sep 17 00:00:00 2001 From: Ash Date: Tue, 11 Dec 2018 16:07:38 +0000 Subject: [PATCH 07/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index af1d3b8..a1ec78a 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -55,7 +55,7 @@ assurance phase. * UI shows at least 2 page tabs ahead and below the current page **Login & Auth** -* User can only access pages that require +* 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 From ee86165783a107fefaaeefe7f27940704a0e314c Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:07:55 +0000 Subject: [PATCH 08/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index a1ec78a..e7572cb 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -106,7 +106,7 @@ project and make sure "Display value in build log" is not checked. * 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) +* When returning JSON ensure the returned JSON conforms to the [JSON spec](http://json-schema.org/specification.html) * Appropriate status codes are set **Emails** From 3072e8e1bb67c40a76f62ef66e9fd8f95b586a11 Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:08:02 +0000 Subject: [PATCH 09/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index e7572cb..14dfd36 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -86,7 +86,7 @@ assurance phase. * 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 +* APIs follow REST architecture as closely as possible and implement our [API Response](https://github.com/langleyfoxall/helpers-laravel#apiresponse) * 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) From 1de812076049679f1970f5d1cd95ea135345c414 Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:08:18 +0000 Subject: [PATCH 10/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 14dfd36..7546e46 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -83,7 +83,7 @@ assurance phase. ### Whitebox **General** * Filenames must follow standard coding conventions (UsersController.php) -* Classes must follow standard coding conventions (UsersController) +* 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) From 8830ee9936d2c65b91d2b7d800c2d2f0c3b1241a Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:08:28 +0000 Subject: [PATCH 11/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 7546e46..8028182 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -82,7 +82,7 @@ assurance phase. ### Whitebox **General** -* Filenames must follow standard coding conventions (UsersController.php) +* 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 From c59d910b2ab30fe3a9bc4fe92c7af3c3be1c6279 Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:08:41 +0000 Subject: [PATCH 12/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 1 - 1 file changed, 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 8028182..51d99a3 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -165,7 +165,6 @@ 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. -e ### Manual Testing #### 1 - Developer Testing During the development of the project, developers will create `feature/*` branches for all features going into the software. From c8266580540e5394329295a20557a57c857a4599 Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:42:45 +0000 Subject: [PATCH 13/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 51d99a3..9b0042c 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -29,7 +29,7 @@ assurance phase. **Navbar** * UI reflects the current active page -* Icon is appropriate for the page +* An icon that is appropriate for the page (if applicable) **Forms** * Invalid inputs correctly trigger validation errors From 214d47c1bf35cc360b967becfc9404330c2efa03 Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:42:53 +0000 Subject: [PATCH 14/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 9b0042c..3756bc7 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -71,7 +71,7 @@ assurance phase. * 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 +* Links point to the correct URIs **Push Notifications** * Push notifications are received in a timely manner From cf5355d8896c63bd9c6012fe02f0c431a79cefdd Mon Sep 17 00:00:00 2001 From: Dexter Marks-Barber Date: Tue, 11 Dec 2018 16:42:59 +0000 Subject: [PATCH 15/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 3756bc7..a2df9fe 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -39,7 +39,7 @@ assurance phase. * 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) +* Inputs have correct type property (emails have email type, phone numbers have tel type) **Modals** * Modals are animated on both display and dismiss From a562f75970ca2ab9005ad9d60eaf37fddf83a5bf Mon Sep 17 00:00:00 2001 From: Jared Wheatley Date: Tue, 11 Dec 2018 16:54:12 +0000 Subject: [PATCH 16/20] Remove class clause line --- quality-assurance/core.md | 1 - 1 file changed, 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index a2df9fe..04e0cac 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -100,7 +100,6 @@ project and make sure "Display value in build log" is not checked. * Log viewers are hidden behind a protected route **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 From 437da6c891960fdb149c9cf805b323fd5f9560ad Mon Sep 17 00:00:00 2001 From: Jordan Hall Date: Tue, 11 Dec 2018 16:54:46 +0000 Subject: [PATCH 17/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 04e0cac..0fee3e1 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -15,7 +15,7 @@ automated 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. +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** From 7969224ac5a74b7532dc44785b4c10957f89e32b Mon Sep 17 00:00:00 2001 From: Ash Date: Wed, 12 Dec 2018 14:16:22 +0000 Subject: [PATCH 18/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 1 + 1 file changed, 1 insertion(+) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 0fee3e1..89db3e7 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -87,6 +87,7 @@ assurance phase. They should be considered guidelines, and not a strict set of r * 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) From f6f8cf3efb4351b8e59dd05c063f6d92a96a2232 Mon Sep 17 00:00:00 2001 From: Jordan Hall Date: Wed, 12 Dec 2018 14:17:21 +0000 Subject: [PATCH 19/20] Update quality-assurance/core.md Co-Authored-By: wheatleyjj --- quality-assurance/core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index 89db3e7..a160221 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -167,7 +167,7 @@ Since end-to-end tests are slower than browser tests and browser tests are slowe 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 `feature/*` branches for all features going into the software. +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. From ef373204c42e35e94eef729ba8b426bcb8891ce3 Mon Sep 17 00:00:00 2001 From: Jared Wheatley Date: Thu, 20 Dec 2018 09:10:54 +0000 Subject: [PATCH 20/20] Removed duplication of Git Workflow --- quality-assurance/core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/quality-assurance/core.md b/quality-assurance/core.md index a160221..ecc73ea 100644 --- a/quality-assurance/core.md +++ b/quality-assurance/core.md @@ -172,8 +172,8 @@ After the initial feature development - the developer should manually test their [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 pull request into the `master` branch should be -made. +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.