Ansarada way of thinking about Quality Assistance — Risk Assessment

What’s your first thought when you think about software’s quality?

The product which meets the customer’s requirements is identified as a qualified system and those quality features can be broken to the three main features:

• Reliability
• Maintainability
• Usability

How we can assure that the customer is happy ?

There isn’t any assurance, the team can consider all the criteria, prioritise the tasks and put their best to meet customer’s requirements.

Every team member is responsible for quality and coordinates quality activities inside the team throughout the development cycle.

Think again about what the quality process has been called. Yes quality assurance but we can see that actually there’s no assurance and everyone is trying to assist each other to put a smile on the face of the happy customer. QA needs to assist developers to find risks and edge cases.

I think now we’re on the same page to alter the title from Quality Assurance to Quality Assistance.

Now let’s get deeper to see the different layers of the Quality Assistance model.

We tend to think about quality in the earlier steps; When there is a big new feature the Product Manager and Designer put their proposal together and share it with the rest of team by creating a confluence page or arranging a meeting. Then every individual team member has an opportunity to get involved and raise his/her thoughts to increase quality.

We’re agile

At the next step tickets are created. I’m not going in to detail of creating and adding tasks under Epics etc. Initial acceptance criteria are put in the tickets, then in the grooming and sprint planning, all the team members sit together to enrich tickets by completing acceptance criteria and estimating how much work each ticket needs and the complexity of each task.

As you can see there is no difference between a QA , developer, designer, DevOps and PM; quality is everyone’s concern!

There’s always a possibility that people will miss something or don’t understand it deeply. To assist developers we have one step before start coding. When the developer picks a ticket for a complicated task with a dependency on other parts of an application, they request a Risk Assessment session with QA — we have a RA(Risk Assessment) column on our scrum board.

What’s Risk Assessment?

It is a pair session between developer and QA. Preconditions of this step are product knowledge and a feasible implementation solution for the user story. For some complicated user stories, developers may want to do a spike to finalise the technical solution before going to implement the main user story. Based on that understanding, developer and QA can identify relevant risks and edge cases that need to be considered during implementation and tested after the coding phase. For some tough questions about product and design, we need to involve PM/Design for their inputs. This section takes about 15–30 minutes depending on its complexity.

Why we need Risk Assessment?

• Build the quality awareness at first sight by preparing testing notes before coding phase
• The cheapest time to fix a bug is before it’s written (Focus on risk and edge cases in advance so that you can avoid introducing bugs while implementing the feature)
• Attain a better grasp of requirement
• Facilitates peer testing process

What is the Risk Assessment’s output?

• Testing Note (Testing notes can ‘design’ how to make your code meet business and quality expectation)
• Improvement of Acceptance Criteria (Should cover happy path)

What are discussed during this step?

In the Risk assessment step we focus on identifying risks

• What are the impacts of this change and what kind of problems could arise?
• Which risks matter most? Focus on those
• Testing advice for complex combination of conditions
• Find out about all dependencies
• All the required tests should be discussed and recorded. This could include:
• Unit test: for all new functionalities / also pay attention to update unit test if there is change in an existing functionality
• Contract test(Consumer-Driven): If we are adding a new endpoint (Provider/Consumer)
• Component test (Integration test)
• tsqlt : if any logic being added in store procedures
• E2E API test
• E2E UI test : if there is any UI change or new UI feature is being added
• Exploratory testing

Talking over all these steps equips developers with more confidence to start the task and assists them to think from different angles.