Added Initial Quality Assurance guidelines/flow

[jaredkove]

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

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds documentation)
• Breaking change (This is a significant change)

Checklist

• I have ensured that I have used relative links where appropriate.
• I have proofread my documentation.

[dextermb]

I've picked up on a few things. What are your thoughts?

stale

[Jord-JD]

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.

[jaredkove]

Maybe we should mark a version/end of sprint branch that the QA team uses?

Thoughts? @dextermb @AlexCatch @NilesB @DivineOmega @robmilward

[AlexCatch]

@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.

[ash123456789]

I agree with @AlexCatch about testing on staging since that is essentially a development environment anyway.

[Jord-JD]

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.

[jaredkove]

@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?

[Jord-JD]

@wheatleyjj Agree with the sprint branches and/or development server idea. 👍

stale

[ash123456789]

Should we enforce usage of https://github.com/langleyfoxall/laravel-nist-password-rules?

[AlexCatch]

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.

[Jord-JD]

We could do something similar to the following.

Suggested change

	* 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.

[jaredkove]

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.

[Jord-JD]

Suggested change

	* 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.

[Jord-JD]

@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.

[Jord-JD]

Resolved the conflict for you. 👍

[NilesB]

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.