What is Quality Assurance
QA is a formal process ensuring that development and products are vetted before testing. The purpose of a formal Quality Assurance process is to identify any defects within a solution prior to it being deployed for testing. Despite a UAT stage progressing post a QA stage, the two stages work very closely together. QA can align with UAT to identify any possible issues or defects thus spilling over into the Testing stage. During a failed test, QA can be initialised to capture and identify defects so the quality can be reviewed again and deployed back to UAT when ready.
A formal QA assessment can be a repeatable process defining various aspects within QA. This includes identifying the required development standards whilst conducting a QA against these standards. It also includes consolidating required testing checks to align with UAT, and analysing completed UAT results to ensure that the solution meets the required quality standards and has no defects. This aligns with the UAT stage ensuring that defects can be caught prior to UAT, and if defects are noted during the UAT, they can be rectified accordingly.
What is a Peer Review
Although some might mistakenly assume that QA and Peer Reviews are the same, they’re not. They may be similar, but their approach and expected outcomes do differ. A Peer Review is more of an informal process where developer peers can evaluate and “review” the solution you, as a developer, have built. The idea behind a Peer Review is to get a fresh set of eyes to take a peak at your development and double check your code is optimised, standards are adhered to, and all related documentation is structured accordingly.
Similar to QA, a Peer Review should ensure that code is efficient, quality is achieved and standards are adhered to. This process also assists reviewers identify potential defects or issues within a solution prior to it moving to the next development stage. More importantly, the real purpose for a Peer Review, is to allow for developer feedback, criticism, suggestions, improvements and knowledge sharing amongst peers. This allows for further growth by aligning standards, defining quality requirements and structuring a culture amongst the group thus encouraging continues improvement following best practices defined by the team! The most common stage to conduct a Peer Review would usually occur before or during QA as well as before you, as a developer, commit or merge any code.
The Difference Between QA and Peer Reviews
Although both processes do overlap, they are ultimately different. A Quality Assurance process is a more formal and structured process that is usually carried out by a QA team. It’s a more objective process to identify requirements and possible defects within a solution. The process is usually initialised prior to a UAT deployment to try mitigate potential defects during the testing stage. Whereas with a Peer Review, this is a more informal process governed by fellow developers and or teams that is usually used before committing code. Yes, Peer Reviews may identify defects assisting the QA stage, but the more focused purpose is to be subjective and improve the solution in terms of code optimisation, development standards and other inefficiencies.
Building Your Process
Considering your applied Development Standards and the functional requirements for a project, aligning a QA or Peer Review process is not difficult at all. Using your documented standards, you can simply use these items as a checklist during a QA stage. For instance, if you have documented a set of guidelines on how to deal with naming convention, performance enhancements and accessibility standards, your QA process should note these as items in a checklist to ensure that they have been complete and adhered to during development. When applying a QA or Peer Review on a flow, you can scroll through your list and ensure that the developer has placed error handling, they have labelled actions accordingly, they have applied OData filters so that data is loaded efficiently, and most importantly, the flow serves its function in line with its requirements. The starting point is using the resources you have first, and scaling when needed.
Something you may also want to consider, is who the process applies to and how you assign both Quality Assurance Assessments and Peer Reviews. Not every company has a QA team, and sometimes fellow developers are at full capacity. Identifying what you need to validate and check as well as confirm how you wish to assign QA’s is a really good starting point.
Resources
I’m currently working on a top-secret project that will hopefully be revealed in the coming weeks. (Yes, its related to Quality Assurance 😉). However, while you wait, feel free to download a QA Checklist Template I’ve put together that helps identify what items can be checked across the Power Platform and its individual products. You can download the checklist here: QA Checklist (268 downloads )
