Shift-Left of Quality: How is it Equally Important as Shift-Left in Testing?

Here is an introduction to Shift-Left of Quality for the benefit of our readers. Let’s get started.

An overview of the differences between the concept of shift-left in testing and quality is explained in detail in this tutorial.

We have heard a lot of people talking about the concept of “Shift-left in Testing”.

Well, we all understand what it is, but for the benefit of those who are new to this term or concept, let me explain it in simple terms.

Shift – Left Of Quality

Shift-left is an approach to software testing or system testing in which testing is performed earlier in the cycle.

Particularly in an agile world, teams are being asked to implement shift-left testing so that the defects can be caught much earlier in the cycle, fixed and software that can be delivered quickly to the client.

Recommended Read=> Shift-left Testing Approach

We have seen many companies adopt a culture of shift-left testing, but we still get to see a lot of defects that creep through our nets. Why does this happen?

This is where Shift-Left of Quality comes into the picture.

Shift-Left of Quality

I believe that most of us know the basic difference between Testing & Quality. Testing is all about identifying or uncovering the defects in the functionality and Quality is about meeting the users’ requirements.

It is also referred to as the “fit for purpose”.

Please take a look at the example below.

You can pound a nail into a wooden plank with a screwdriver, as shown above, then why do you still need a hammer? We can also pound a nail with a small rock or even a screwdriver, but will it meet the requirements of the user? Now that’s where quality comes into the picture.

According to a recent survey in one of the most popular websites, it is said that 56% of the defects are found in the requirements and 27% of them are associated with the design.

This means that 85% of the defects in total are related to requirements and design.

Why do we see these many bugs when we have great tools and test strategies in place?

The way I see the “shift-left in testing” is the application of tools, techniques, and strategies to get things faster and more efficient. “Shift-left in quality” is all about the application of some common sense. Yes, you heard it right!!

This concept is not really new. It has been there for ages in the form of verification of requirements. But how many of us really do this in today’s world?

Also, do you think quality has taken a back seat in this mechanical world of agile and automation? Well, I would say so.

So what is Shift-left in quality in a simple sentence?

Shift-left of Quality is all about applying our thinking on the lines of “fit for purpose” while we define and review the requirements.

Requirements Validation

Given below is a list of Examples, picked from the web

The above set of classifications can be attributed to the process of requirements validation – which is a process of confirming the completeness and correctness of requirements.

Many a time, we tend to ignore the non-functional requirements which are related to performance, security, load etc.

For example, if a requirement says that the page should be loaded when the user clicks on the register button. This can be good from a functionality point of view, but do you think there has to be an element of performance added to it?

Obviously, the answer should be a big YES. Because the requirement should also tell us the time that it should take to load the page.

Now, we have understood what makes a good requirement? Let me ask you another question – Why is it so difficult to get the requirements right?

How often have the stakeholders in your organization signed off on the requirements just because there was not enough time available to have a detailed look at them?

There’s also an ISO Standard on software quality requirements from ISO, and in contrast to requirements, testing is often neglected which in turn leads to errors and a significant drop in the product quality. This has to be changed.

How many of us are really sincere towards the Definition of Ready while defining the requirements?

I use the word sincere here because we have to be. This is the starting point of everything. If we can get the requirements right, then imagine the time that you would really spend designing a solution or testing it. This, in turn, will lead to both internal and external failures to cost drastically.

Another problem that I have noticed is that we don’t look at the dependencies on other modules or other dependent upstream/downstream teams while reviewing the requirements. This will lead to rework and is of utter waste.

Requirements Engineering Process

There has to be a requirements engineering process, which has to happen when the stories are added to the backlog before the grooming or the sprint planning happens.

The required engineering process is to have a complete package of all the below steps:

Step #1: Requirements Elicitation

Work with your customers to learn about the domain of the application and the other services that the system should provide. Involve the stakeholders who will use the product and not just the representatives who will purchase the product.

Step #2: Requirements Analysis

Classify the requirements into functional and non-functional categories. Must have clear prioritization and document them in a detailed manner.

Step #3: Requirements Validation

Validate them thoroughly as per the checklist mentioned above. Get buy-in on the scope of the requirements from all stakeholders.

Step #4: Managing Requirements

This is about managing the requirements, so you don’t allow the scope creep to happen. We must analyze how frequently the requirements are changing and why? Also see if the changes are too much for the team to absorb?

Conclusion

We can conclude this tutorial as “Shift-Left in Quality is equally as important as Shift-Left in Testing”

Also, let’s not ignore that, time spent on validating the requirements leads to a significant reduction in the number of defects noticed in the later phases.

“Shift-left of Quality and Testing” – both these methodologies, when combined, can lead to a much better product and better customer satisfaction.

About the author: This article is written by Aditya S. He is working for S&P as a Senior QA Manager. He has over 12 years of experience in Testing and Management.

Hope this tutorial enriched your knowledge on the concept of Shift-Left of Quality. Do you think we have missed out on something informative about Shift-Left of Quality? Feel free to express them in the comments section below! We would love to hear from you.