Added Initial Quality Assurance guidelines/flow #94
Conversation
Automated testing copy
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
jaredkove
requested review from
ash123456789,
dextermb,
DivineOmega,
NilesB and
robmilward
| 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) |
There was a problem hiding this comment.
A possible problem count occur here if QA is testing on the master branch, and development continues on with development of the next sprint in the mean time.
There was a problem hiding this comment.
Maybe we should mark a version/end of sprint branch that the QA team uses?
Thoughts? @dextermb @AlexCatch @NilesB @DivineOmega @robmilward
There was a problem hiding this comment.
@wheatleyjj What about testing on staging? We should be aiming to push a version to staging at the end of any sprint so it makes sense to do QA on that branch.
There was a problem hiding this comment.
I agree with @AlexCatch about testing on staging since that is essentially a development environment anyway.
There was a problem hiding this comment.
I've worked on projects previously with this kind of QA process in place.
At the start of a sprint, a sprint-1 branch would be created. After the sprint is over, QA would begin testing on sprint-1. At the same time a sprint-2 branch would be created (from sprint-1) to allow developers to continue development immediately.
Once QA was happy with sprint-1 it would be merged into mater, and the process would repeat.
There was a problem hiding this comment.
@ash123456789 @AlexCatch I think that testing on the customers environment would cause annoyances to the client if they're using it regularly.
Ways around this are sprint branches as I and @DivineOmega suggested or having a development environment - but that comes with another layer of grief. I'm also thinking experienced QA testers will have good knowledge of automation tests so would be able to look into both the Blackbox/Whitebox sections of this document more easily if they have it running locally.
Thumbs up if you agree?
There was a problem hiding this comment.
@wheatleyjj Agree with the sprint branches and/or development server idea. 👍
Co-Authored-By: wheatleyjj <[email protected]>
|
|
||
| **Registration** | ||
| * Email addresses are verified & unique (if applicable) | ||
| * Passwords meet minimum standards (min 8 chars) |
There was a problem hiding this comment.
Should we enforce usage of https://github.com/langleyfoxall/laravel-nist-password-rules?
There was a problem hiding this comment.
I never wrote this for explicitly Laravel - it's just a general web assurance guide to ensure that the projects we write for Web, irregardless of technology, all follow the same basic principles, the steps outlined can be applied to any web stack.
There was a problem hiding this comment.
We could do something similar to the following.
| * Passwords meet minimum standards (min 8 chars) | |
| * Passwords meet minimum standards, as defined by [NIST Special Publication 800-63B section 5](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5). If using Laravel, ensure the [Laravel NIST Password Rules](https://github.com/langleyfoxall/laravel-nist-password-rules) is integrated. |
There was a problem hiding this comment.
I'm against blanket enforcing the NIST rules due to their complexities and it would cause a significant barrier to entry for social apps (registration processes) and uptake to those platforms.
For that reason I think a lower level as a minimum (8 Chars) is enough, but its preferable in our enterprise software to opt for NIST specification.
There was a problem hiding this comment.
| * Passwords meet minimum standards (min 8 chars) | |
| * For enterprise software, passwords should preferably meet standards defined by [NIST Special Publication 800-63B section 5](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5). If using Laravel, ensure the [Laravel NIST Password Rules](https://github.com/langleyfoxall/laravel-nist-password-rules) is integrated. |
@wheatleyjj New suggestion based on your feedback.
Co-Authored-By: wheatleyjj <[email protected]>
Co-Authored-By: wheatleyjj <[email protected]>
|
@jaredkove Would you be able to resolve conflicts here and handle the unresolved conversation(s)? I think it would be great to get this PR merged in. There is a lot of useful information here. |
|
Resolved the conflict for you. 👍 |
| * Passwords should not have maximum length restrictions (allow at least 255 characters). | ||
|
|
||
| **Emails** | ||
| * Emails look good on small form factor devices |
There was a problem hiding this comment.
Might be worth mentioning ensuring the HTML and CSS in the email works on the popular clients if custom HTML and CSS is being written. There are good resources such as this guide which lets you search by email clients.
I've combined a few different documents created by us to make up how the flow for QA should look. The idea is to now figure out how we can attain this level of QA on ongoing products whilst we hire in some actual QA resource that knows their stuff.
Description
There are a few sections to this QA document, one being "What makes a good web application?" that goes into detail about blackbox and whitebox testing.
Then there is the process that highlights how we should be QAing our products during their lifecycle. There might be the need to outline process for AFTER the initial development process but we can outline that when it gets to it.
Types of changes
Checklist