Quality
Internal review
Before we show off our hard work to the client, it’s a good idea to have someone else take a look. We want to confirm that everything we’ve done aligns perfectly with the requirements and functions seamlessly. This means making sure we’ve met all the criteria, testing it on different browsers, and carefully checking, and critically reviewing our implementation within the Matrix. The goal here is to ensure that everything, from properly named metadata to user-friendly, editable content and properties, is exactly as it should be.
"Internal review" !== "Code review"
Before we dive in, it’s crucial to note that an “Internal Review” is not the same as a “Code Review”. However, both can be carried out by the same person. So, what sets the two apart?
In a code review, our primary focus is on the quality of the code - its efficiency and error-free operation. Sure, it’s helpful to run the reviewed branch/commit in a local environment, but unlike an Internal Review, we don’t need to concentrate on whether all aspects of the feature/fix outlined in the ticket have been executed and are ready for client presentation.
The Internal Review, on the other hand, focuses on testing the actually implemented functionality that has already been deployed in Matrix, including its usage. This testing takes place across different browsers and also involves a thorough examination of security.
This version maintains the informal and engaging style while clarifying the differences between the two types of reviews.
Why is internal review important?
Let’s dive in and take a look at why we do internal reviews and how they help us.
Quality
Quality control is like a safety net, making sure everything in our project is working just as we planned. It’s like ticking off a checklist to make sure we didn’t forget anything important. Checking that we’ve hit our goals and everything lines up with the requirements is really key. This way, we know our product ticks all the boxes and we didn’t miss any essential details or features.
Spotting mistakes early
Quality control is like our very own detective, finding and fixing mistakes before they reach the people using our product. This helps keep things running smoothly and gives users a better experience. Plus, catching mistakes early usually means they’re quicker and cheaper to fix, saving us time and money.
Avoiding negative impacts
By doing quality control, we dodge the bullet of unhappy users or clients. No one wants a buggy product, right? So, we make sure we catch those bugs early to avoid any dissatisfaction.
Internal review process
The diagram below shows the flow of the Internal Review phase.
-
Ticket Preparation: Setting the Criteria
Each ticket, especially BASE tickets, should have testable criteria established upon creation.
After completing their work and personal testing on a ticket/issue, a ticket is prepared for the Internal Review phase. The Code Developer must ensure these test criteria are clear and up-to-date. Ticket is moved to the “Squiz
- Ready for QA” column.
-
Initial Assigning Phase: Assigning the Reviewer
A different developer (or dedicated Quality Engineer) is assigned to conduct the review.
-
Testing Phase: Comprehensive Evaluation
Execution, Accessibility, Usability, and Security
The assigned tester conducts a thorough evaluation of the ticket, following set criteria, checking functionality across different browsers, ensuring UI accessibility, assessing Matrix usability, and conducting security tests.
-
Feedback: Recording the Results
After testing, the tester should document detailed comments about the testing process and the results, using a canned response in Jira when it’s makes sense.
-
Outcome Evaluation: Determining the Next Steps
Success or Setback - Back to the Developer
Regardless of whether all tests pass or not, the ticket is always reassigned back to the original developer. If successful, the developer can present the work to the client; if there were issues, the developer takes on the task of issue resolution. It’s important to remember that the testing cycle isn’t considered complete until all tests have successfully passed.
Tester’s aid: The canned response in JIRA
To ensure every nook and cranny has been inspected and all the Acceptance Criteria met, testers can lean on a handy tool - the Canned Response prepared in JIRA. This handy function provides a checklist of key areas to investigate, such as frontend, accessibility, and security. It allows you to tag the person assigned to the ticket and to list all the specifications described in the ticket. It’s like having an extra set of eyes to help you catch any slip-ups!
