Meet the Teams Responsible for Quality

Learning Objectives 

After completing this unit, you’ll be able to:

• Explain how and why quality is a shared responsibility.
• Explain the different groups and stakeholders involved in quality.
• Describe how different stakeholders contribute to quality at each phase of the software development lifecycle.

Who Is Responsible for Quality? 

To some, quality is synonymous with testing, but the truth is that it’s so much more. Of course, while testing is a key component of quality, it also involves solving problems, setting priorities, offering and receiving feedback, and, most importantly, delivering value to the end user. All of these activities are best accomplished through a team approach. 

By team, we mean everyone involved at any phase of the project. There are many stakeholders involved in delivering software to users, and each of them has an important role in ensuring the quality of that software. Therefore, quality is a shared responsibility.

Before digging into the details of the team, let’s take a moment to recognize that the precise titles for jobs related to quality can vary greatly depending on factors such as industry, company size, team dynamics, individuals’ strengths, and more. To keep it simple, we will refer to the generic stakeholder groups—Development, Operations, and Business—and leave the specifics to your unique context. 

Note, though, that for each group, the responsibilities can vary, and some roles (such as Salesforce Designer) fit in more than one group. 

Now let’s check out these stakeholder groups and their roles in quality. 

Development

The traditional area for development (or its nickname dev) includes coding the features according to requirements set by all stakeholders. 

Operations

As software changes are released more frequently, there’s an urgent need for quality to keep pace. Cue testing and security to cover operations (or ops) to provide input on quality activities before developing code and then monitor the product and features once they are built. 

Business

Business representatives bridge many areas, including engineering, product, marketing, sales and, of course, the customer. While they might not directly write code or fix bugs, they are integral to the management of the project’s time, resources, and planning. 

Diversifying the perspectives involved in the software development lifecycle (SDLC) with a mix of these stakeholders improves overall quality. The composition of a team depends on its context, including its mindsets about quality, the methodology it uses, and the specializations of the individuals involved. 

Regardless of team structure, notice that quality is listed as a responsibility for each group. This includes not only activities that contribute to quality but also actions that contribute to a culture of it. We’ll discuss the quality activities for each role across the SDLC in a minute, but first let’s talk about the role of testing in the cycle.

Shifting Left

The SDLC is made up of five phases: requirements, design, development, testing, and deployment. As you see, testing is a separate phase in the cycle, so that’s obviously where all testing happens, right? Well, yes but also no. 

Let us clarify! While testing is its own distinct and essential phase, it is also important to test from the beginning through the end (and beyond!) of the SDLC. This idea of testing earlier in the cycle is known as shifting left.

Moving testing earlier in the SDLC helps teams keep pace with faster developments. Waiting too late in the cycle to start testing can waste time, bottleneck work in progress and cause small problems to grow into major issues. 

The sooner a team is able to start testing, the smoother the process will be. Starting earlier, though, means expanding the original conception of quality as just testing and its stakeholders as just testers. 

Let’s take a closer look at each phase. 

Responsibilities Across the SDLC

The Cycle Continues

Deployment is the final phase of the SDLC, but not necessarily the end of the journey. The cycle continues even after features have been deployed. 

• In retrospectives, stakeholders meet to debrief their work throughout the process and identify challenges and opportunities for future work. For teams, these review sessions are a key component of continuous improvement.
• Testing is also an ongoing activity that occurs throughout the development cycle, but also needs to continue after it. This helps teams not only deliver the product with confidence but also maintain its quality for end users.

As you can see, quality is best achieved with a team approach. In the next unit, we see how to create a culture of quality on your team. 

Resources 

• Trailhead: Salesforce Designer: Quick Look
• Trailhead: Salesforce Developer: Quick Look
• Trailhead: Salesforce Architect: Quick Look
• Trailhead: Salesforce Admin: Quick Look
• Trailhead: Salesforce Consultant: Quick Look
• Trailhead: Salesforce Business Analyst: Quick Look
• Trailhead: Cybersecurity Role: Quick Look