💡Quality Insight: The Developers are the Customers

Last week, I attended the webinar “Using Cypress and GitHub Actions to Build an Automation Pipeline”, hosted by Cypress with guest speaker Carter Capocaccia. As I’m currently working to get the test suite into the CI/CD pipeline, I was excited to watch Carter outline his process during the demonstration.

What I didn’t expect was a new way to think about developers.

Thinking back…

In previous roles, there was a definitive line drawn between developers and QA. I was on a QA team and over there was the Developer team. The devs would throw things over the QA wall. The QA’s wrote up the bugs they found and threw the bugs back to the devs. Lots of throwing. In the end, if a bug went out to production, the QA’s would be blamed. They were the last ones that had touched that version of the application.

Not an ideal work environment.

As I continued to grow in my career, take on new roles, and on board with new teams, the separation between QA and Devs diminished. I worked with developers who wouldn’t let me take the blame for a bug that went out. It was the team’s responsibility. We all missed it. We are all on the same side. This was a healing time and helped define the types of work cultures I wanted to work in moving forward.

Back to the webinar…

Listening to Carter speak, I nodded my head in agreement as he defined what Quality Automation should do:

• Integrate with your development lifecycle

• Provide actionable feedback

• Inspire confident decision-making

The next slide, however, caught me by surprise:

Ask yourself, are your developers your customers? If not, why not?

I paused. Are the developers my customers? In my role now, I’m not doing a large portion of the manual testing. My role is to build quality practices into the business and to build automation that does what Carter described: Integrate into the development lifecycle, provide actionable feedback, and inspire confident decision-making. As I’m building, who are the developers to me, beyond just my teammates?

Truthfully, I am still sitting with his question. A part of me feels nervous at what feels like a dividing line: Me, a developer, building a product that my customers (the rest of the development team) can trust to get the feedback they need and take the needed action on the code they submitted. Eventually, it won’t be only me writing automation scripts for our team. With the right pieces in place, the rest of the engineering team will work with Cypress to build out automation that gives us all the information we need when it comes to deployment.

So, are the developers my customers? Maybe. And, I am my own customer. I care about what I build, its usefulness, its reliability, its strength, and its transferability. I want to create automation that I can easily pick up and create scripts with and build with tools that all of us enjoy using.

Because eventually, the tools I pick, and the scripts I build, don’t just affect the engineering team. If what we build is good, the developers can trust it, the extended teams can make decisions by it, the company can get excited on release days, and the clients using the application can work without interruption.

It’s the kind of ripple effect that extends beyond me and the developers I’m working with. It affects all of us.

So, are the developers my customers? I still don’t know. But, I’m thinking about it. It’s a fabulous idea to think about.

What are your thoughts?

Till next time…

This post was written with the following music playing in the background:
Mecca of Ancient Astronomy by Teravibe