Ensuring Quality Code that Fits Your Business w/ Erika Chestnut of Calendly

**Dan Lines** (0:00)
There is never enough time. We're all trying to increase efficiency and delivery speed to maximize that time.
But if we're not careful, it's easy for the need for speed to damage quality. That's why we've brought in Erika Chestnut, head of QA at Calendly, to break down how the world solution for finding time ensures quality code.

**SPEAKER_2** (0:24)
This episode is sponsored by Linear B.
Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time get activity. Sign up free at linearb.io.

**Dan Lines** (0:39)
Erika, thank you for joining the pod today.

**Erika Chestnut** (0:42)
Thank you. I'm happy to be here.

**Dan Lines** (0:45)
I want to start with a really big question. How is quality strategy changing at modern companies versus how it's been done for the last decade or so?

**Erika Chestnut** (0:58)
Yeah.
I wonder if I could say it's more of a hope that quality is changing. I hope that QA organizations are taking more ownership.
They're taking more ownership of the quality conversation as a whole and not just the test step. Unfortunately, there are a lot of organizations that actually what I see is that the construct of quality the concept of quality assurance has been smushed in to the test step. It is now combined with the test step so much that there's a confusion between quality assurance and the test step in quality assurance, the function inside of quality assurance. I hope that there are more organizations that are starting to see that concern, but I see a lot of organizations that are looking and talking about quality assurance as a single test step. And that moves into why they're driving towards automation as the only thing that they need to do when it comes to quality assurance.

**Dan Lines** (1:58)
Let's dive into the details there a little bit. You're kind of saying some companies think, OK, automation is the only thing that we should be doing, and that would make us really good from a QA perspective.
But what's kind of the other side to that or what are what are most companies missing then?

**Erika Chestnut** (2:17)
Test automation is absolutely necessary. It is necessary in our DevOps, lean, get-it-out-there-fast world. However, it is a tool in the toolbox of your testers. It is something that they leverage. It's like a GUI that you use to develop. It is a tool that gets you the quality that allows you to assess that quality. And they're missing that larger conversation around the construct of quality, the ideals of quality, the standard, and how when you create those standards and you create those processes and policies, that you are creating that consistency, that continuity that results in quality.
But when you're only talking about that test step, you miss the opportunity to set the level, to set the bar, and to allow others to lead quality across the delivery lifecycle. And you're waiting.
You're waiting to test. You're waiting to write test automation, waiting to write acceptance criteria. You're waiting for testing and waiting to assure quality. And you shouldn't have to.

**Dan Lines** (3:23)
Totally makes sense.
So if we took a look at the software development lifecycle, when should quality come into play? I think you're alluding to maybe earlier than just maybe automated testing at the end. But how do you look at it from the SDLC perspective?

**Erika Chestnut** (3:44)
They should come in at the very beginning, analysis.
When you start talking about what are we going to build? Why are we going to build it? Does it make sense? Does it fit in here?
Your test team is the team that is exercising the entire system on a regular base. Go talk to them.
Find out what do you think about pushing this particular feature into the system in this particular way? What are the type of issues that you see or that you have seen when we add functionality in this area of the system? Are there dragons there? Do we typically trip over ourselves? Do we have the appropriate type of coverage? Do we see our customers complaining about areas in this system? What makes the most sense? How are our customers going to be impacted? Your test team is seeing this. If it's not just test automation and they are exercising the system, they are your customer's voice.
They are integrating. They are hopefully collaborating closely with your CX team. So they're hearing those conversations. They're seeing those issues raised. They have context, and we need to create space and recognize the value and impact that the quality team can have on these conversations. And also the opportunity that they have to drive things like documentation in those areas, workflow diagrams and personas, being able to drive those conversations and then leverage them as part of their test site.