Become a Testing Superhero with Stacy Kirk

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Automation Podcast. We're all getting together to learn more about software testing and automation with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we're going to be talking with Stacy Kirk all about QA DevSecOps. If you don't know, Stacy is a champion of quality and process innovation in software development. She also is the founder and CEO of Quality Works Consulting Group, which is an international quality driven software consulting firm. Stacy has become an internationally known speaker. She talks about all kinds of things like bold and fearless leadership, continuous integration and quality innovation, DevOps culture and process transformation, test tools, and all kinds of awesomeness with automation as well as QA DevSecOps is what we'll be talking about today.

Steve.

Stacy also strongly believes that diversity and quality first approach are the key elements to creating great products. You don't want to miss this episode. Listen up.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Their cloud based test platform helps ensure your favorite mobile apps and websites work flawlessly on every browser, operating system and device. Get a free trial. Visit testguild.com for.

And click on the exclusive sponsor section to try it for free for 14 days. Check it out.

Hey Stacy, welcome to the Guild.

Thank you. Glad to be here.

Awesome. It's great to have you on the show. Really excited to have you. I'm hearing a lot of great things about a recent session you gave about QA DevSecOps. Before we get into it, is there anything I missed in your intro?

I think you hit most of the points. A lot of my team is in Jamaica, which a lot of people think is pretty interesting as well. So we're in Los Angeles and in Jamaica giving an option for those that like the Caribbean.

Very cool. And you know, that's what I love about you. You're also a founder of a company, Quality Works. I saw a recent interview with you that you explained why you got into quality insurance and testing. But what made you want to actually start a company around that as well?

Well, I was very fortunate to wear many hats in my career of testing. And eventually I got to the point where, you know, I'd been a director, I'd been a consultant, and I thought it would be a good opportunity for me to use my skills as a consultant to develop other consultants that had similar like mind to myself. I've always enjoyed being a software developer, being in the code, having great architectural conversations. With developers, but just wearing the hat and perspective of a tester. And so I just wasn't able to find enough consultancy or professionals that were doing something similar to me. And so I thought it was a great opportunity to start a company of my own, because definitely there was a need there for people that are able to go in, innovate, do the software development as a test, but also going beyond that and looking at process improvement as a whole.

Very cool. So, Stacey, when did you start Quality Works? How long ago?

2010. So we're in our ninth year.

Oh, wow.

Yeah, we're in our ninth year. Started in Los Angeles, and as I mentioned, we expanded internationally in 2015.

So you started in 2010. It's now almost 2020. Has anything changed? Do you still see folks struggling with testing and quality? Is that still an issue? Is there more other issues now that you see companies struggling with?

Not enough has changed. And that's one of the things that I hear often around tests and testing and innovation. We're not moving as quickly sometimes as we should. So some of the same problems that I experienced 10 years with doing consulting and when I started my company with, how do we create a framework?

We're still dealing with some of those same issues. For example, we know what framework to use, but the best practices, how do we mobilize a team? How did we deliver on our automation when we still have so many manual test tasks? All of those are still challenges for many companies, even if they are at a mature level in their test organization.

Absolutely. And I think a lot of times there's always new approaches that come out, and one of them was DevOps. DevOps has been around for a while now, but it really was kind of the rave. And then people started kind of adding different flavors to DevOps. So I don't know if you coined this term, but what is QA DevSecOps? And why do we need a different name or a different approach than normal DevOps?

Yeah, well, I put QA on the front kind of as a joke. I don't catch on per se. But what I've been asked over the years when I talk about DevOps and quality within DevOps, I'm often asked for a definition. What is DevOps? And what I mentioned in my recent speech is that you will be very hard pressed to find any definition of DevOps that does not have the word quality in it.

As we transition from DevOps to DevSecOps, Dev Test, Ops, whatever the term, you really cannot have a successful DevOps transformation. If quality is not a factor.

I had a research point that 50% of application development time is tied to testing.

Not only is it important to have quality in the definition and your process and your strategy, but. But you cannot say you have a high performing DevOps team if you do not have the best practices around your testing and quality.

So what is your definition for DevOps then? If someone asks you, oh, that's a good one.

Well, the definition I use is it's a set of practices, philosophies and tools that you use to increase your organization's ability to, to deliver applications at high velocity and most importantly, high quality.

So you did mention 50% of folks developers spend their time testing. Is that, how do I say this, I worked on a company where they spend maybe 50% of their time testing just because they didn't know how to do it. Is it 50% of because people don't know enough about how to do testing correctly or is that just the nature of development?

Well, let me clarify. The research shows that testing takes up more than 50% of time, of 50% of application development time. So if you think of what it takes to deliver a product, not just what the developers do, you can kind of see where it can take 50% because developers will do their own testing. And if they're efficient or not efficient, it still takes some time if they're creating their unit tests. And then there is the testing effort. Manual or white box or what? Manual being functional or automation. So there's a lot to do to validate that you have a good product and get it out the door. So that's where that metric of 50% comes from. Can they do it better? Absolutely. And that's part of why DevOps is based on continuous improvement. And so we're always looking at how do we do it better. And I've been on a lot of teams that have come up with that are high performing DevOps teams and they figured it out over years how to perform well. And they've said to me, you know what I think Stacy, we can stop doing retrospectives. We're really good, we know what we're doing. And my answer is always, we can continue to be better at what we do and it gets make it a little harder. But as long as we have technology somewhere in our job description, we definitely need to continue to improve on the.

Way to improving a lot of times, once again, I worked for large enterprise companies, they always talk about quality champions, have a quality champion on a team. But I think in your presentation you mentioned rather than thinking of quality champions, we should call them heroes.

I'm just curious to know why you think that that is. What's the difference between a quality champion compared to what you're calling a hero?

Yeah, great question. Part of that QA DevSecOps title that I chose for my presentation is that QA has always had that voice for quality within the organization. But sometimes they need to be more than just the voice. And champions are normally that voice that say, hey guys, we shouldn't be releasing this. Hey guys, you should start testing earlier on the cycle. But I want QA to be more than just a voice. I want them to, to lead with their expertise and experience. I mean, it baffles me sometimes that we'll be talking about what we want to do or I'll be in meetings. There's no QA representative, I'll be there maybe as a DevOps coach and there's no QA representative. And they're talking about process improvement. And the people that have the most experience with quality and process improvement from the testing perspective aren't there. So, so using the word hero says, you know what? First, the definition of hero means that you're recognized for your strength and ability. And so part of being a QA hero or quality movement hero is you want to be recognized. And we should be recognized for our experience and our skill set that we bring. And then we have to really be bold. And when you think of a hero, you think of this extraordinary deeds of bravery. And so it's going beyond just, you know, telling people, remember quality, quality first, remember to test to standing up in meetings, say no, we're not going to do it this way. We said we're going to follow a process, let's follow it. Let's not get complacent. Let's really push, push the pendulum, push the needle forward in terms of what we want to do to be a great high performing team.

I love this mind shift of calling someone a hero because for some reason I don't know if we have complex. A lot of times when I find a QA person that's really awesome at the job, they tend to know everything. They know the front end, the back end, they know everything that's going on. Yet for some reason people, they don't feel empowered to really help drive the team to better performance. So along those that line of thinking, I think you have three hero types that I guess people can emulate. And one of them is the hulk of process. The other one's iron man of innovation and I think the other one was Wonder Woman of culture. So to help someone be empowered, then, like, what is your thought of? What is your concept of a Hulk of process? How does that help someone become a champion to a hero?

Yeah, absolutely. Well, Ironman is the most logical, especially as QA professionals or test professionals that are highly technical and do automation. We understand Ironman and Ironman being the tools person. We are the innovator that comes up with test automation. But I have many friends, I've been doing this very long time that understand the customer, the end user, they understand quality, understand process, but they were not able to make that shift over to test automation. And I get asked a lot, know what is my job going away? And the answer is, yeah.

In a lot of ways, yes. You know, people are not hiring black box manual testers the way they used to anymore. If you're not a software development test and you don't have automation engineer, you're not as desirable. And so part of what I want to present is that you, even though you may not be as desirable for a testing role, you definitely are still needed in this process of delivering a high quality product. So the Incredible Hulk is the champion for process. And this means, really, you've seen some of the Hulk movies. He makes a lot of changes, right? Every time he's angry, he goes from this very quiet, brilliant scientist to this crazy extreme monster that's beating his chest and breaking things up. But when it comes to process, process is full of change. And it requires a lot of passion for someone to say, we have to fix this. And so I chose Hulk to represent this because he's evolved from every Marvel movie that he's been in. He's continuing to improve himself. He fails, he'll jump out of an airplane and be like, I hope I change into the Hulk. I may die. But he's willing to take risks and continue to experiment on himself. And that's what a hero of discipline, practices or process needs to be able to do. Take really big risk, be open to experiment and change and help the team that they're on to do the same.

Awesome. Of course, if you have heroes, you always have villains. So what do you think of some villains that could hold back the Hulk of process?

Oh, well, I think the biggest one is the fear of failure. And I tell this story that I was in a retrospective and we were addressing how we would solve a problem, and there were competing ideas on how we could solve the problem. And we were probably at about 30 minutes of debate on which way we should solve this problem. And I had to raise my hand and go, listen, two weeks. And everyone's like, what are you talking about? And I said, two weeks. You only you will be better spending two weeks trying this idea than us spending the next hour debating if it'll work or not. And so that fear of failure, of trying something and it going horribly wrong, stops a lot of companies from changing and improving. You know, if you've been doing Waterfall for 10 years or you've been doing agile the wrong way for 10 years, and you're like, well, it's better than nothing. Who knows what's on the other side of this change? I love to see when people are able to really take that leap and try something, try something new. So fear of failure, definitely. Hulk has a lot of passion, but there's in terms of process, some people stop caring. They're like, whatever, I'll just do my minimum. But you really can't get to a great organization with a team of people that only want to do their minimum. So it's about being able to fail and being okay with learning from it and continuing to experiment. But those that don't, those are our villains. People are scared to try new things, or they're just apathetic.

Stacy, I just want to go back to Ironman some characteristics again. So do all testers have to have these three heroes, or do these three heroes make up part of the team? So, like, an iron man, I think, is your innovator, automator, tool, or problem solver?

Yeah, well, you know what? If I would have had more time, I would have came up with more heroes. Luckily, my son is my head Marvel researcher, so we spent a lot of evenings where he was like, you need captain Marvel. You're missing very important characters, you know? And their article came out after I gave this about Batman, and I thought that was because, you know, nobody wanted to. He's kind of like the hero nobody wants to know.

I love the article that came out that said, this is another hero. You know, they were kind of the forgotten hero.

Sometimes. So I just picked three. But the idea of my message is that we need to have a lot of courage. We need to embrace our skills and our strengths. Not all of us are Ironman. Not all of us can just come up with new ideas every week and code them up and build them up and get them out. But we may have a way of talking with people and bringing people together that makes way more massive change in value. And so that's kind of the. From one side to the other, you know, Iron man is known as being kind of a jerk, right? He just gets stuff done. And then you have Wonder Woman who has all this empathy and is, you know, even with her lasso, can get people to tell their truth and bring people together. So part of my message is we need a lot of people to build a high quality product. And so for those that may say, you know what, I just am not getting this test automation stuff down. I just don't want them to be discouraged because there are roles that they can play that will have just as much impact. Even though I love, I'm an Iron man type of woman.

But I watch every Iron man movie, I'm like, oh, that's me. How did he figure that out? That's what I want to do.

But I also know that I change roles. And we all probably have a little bit of each type of hero in us.

Absolutely. So what are some villains then if someone takes on the Persona of Iron man during, during a project?

Well, the first one I talk about is limited resources. And I go back to the first Iron man movie, becoming the Iron man historian I've become. Going back to the original movie Iron man was the first suit was made in a cave and it was made in a cave with these terrorists with guns pointing at his head saying, you know what, I'm gonna kill you and your assistant. You don't build a missile with these limited resources. And everyone that's in test automation has probably experienced that. You have limited resources if that's time, if that's technologies. And so what I talk about is that if you are reaching, you're going to have that villain of limited resources. So do what you can. The first Iron man suit was extremely ugly. It was clunky, it didn't fly, but it was able to show a little bit of value. And from Ironman. And we will always are able to improve on our frameworks. I mean, I know my first automation was probably like a selenium IDE record.

Actually I have automated scripts way older than that. But I don't want to tell my age. But you know, the first record and playback was like, oh, this is terrible, you know. But seeing that evolution over the last 15 years is what's really impressive. But at the same time, you don't want to create the other villain is over tooling. You just don't want to create a tool for everything. And I don't know if you've experienced people. I had this one developer, he was my villain, I'll say. And Every time you came with a problem, he's like, oh, I can build an app for that. And I think, I think we could just have a meeting. No, I, you know, I would say people. I say, you know, a couple people aren't coming into the office or missing this meeting. He's like, I think we could create a time management system for that. Maybe we should just talk to their leads.

So that can actually end up being a villain because you waste so much time on tools when there could be an easier solution.

So, speaking of age, I'll have to admit one of my favorite heroes of all time that I fell in love with in the 70s was Wonder Woman, Lynda Carter. So that's the other role you have as Wonder Woman, hero of people and culture. Can you just talk about, tell us a little bit more about that?

Yeah, I love Wonder Woman. Yes, Lynda Carter was. I could not wait to watch Lynda Carter. And I'm six foot tall and I think she's six foot. So I just. Oh, man. This is my goal.

The biggest problem with DevOps transformation really never comes down to we didn't have enough tools. It never comes down to we didn't have enough process. It always comes down to culture. And it comes down to does this team have the cultural wherewithal, the fit to deal with what it takes to be great at delivering software or products? And so Wonder Woman, I end with her, but she really is kind of that foundational type of hero that we need to be successful. It's really, even though we talk, we're in technology and we're all tech people, at the end of the day, we're people and we deal with work. When we're working, we deal with fear and getting nervous and where's our job and how's it going to change and how's this going to impact me? And so Wonder Woman, in my opinion, was just a loving hero. Right. She seemed so selfless. She seemed, you know, I mentioned her lasso. She's the kind of person or the kind of hero that you want to talk to that you feel open to say, I don't like this and I'm scared. And so that's the type of hero that will include people, be diplomatic, but also protective.

Awesome. And some villains. I guess Wonder Woman would be people that don't want to collaborate or they don't want to change.

Yeah, absolutely. And I may have stretched a little bit. I mean, not all of us have lassos that we can tied on our co workers and be like you tell me what you did with that last belt, I know you changed some code. Yeah, I don't know if we all have our can get to the truth on everything, but.

Absolutely. Hero of people and culture. Our Wonder Woman is looking at villains like sabotage, fear. I mean, I've seen people that have done things to sabotage themselves from being successful within an agile team and I can't believe why. But some people are so nervous about change and collaboration that they're willing to shoot themselves in the foot. And so really we have to kind of combat that with a lot of empathy, a lot of communication, a lot of explaining things in a way that makes sense to them. And that's hard. It takes someone that will stop and listen. You know, I've had, I've heard executives say, I don't care what everyone says, they're going to just do it. And that's it. That's that top down approach. You need some top down, you know, influences, but you also need those people on the ground that are able to say, listen, if we collaborate, we are going to do five times better. And that's what research says, that if you have a collaborative culture, you're going to be five and a half times more productive. So giving them numbers, giving them metrics and measures that mean something to them will combat those villains of fear and collaboration.

So once a team has their head around these Personas that you came up with for heroes and quality is everyone's responsibility, how can we drive quality throughout the software development life cycle? I think you had like six steps to, to really help and bake in the areas for a QA LED type of devsecops. I guess the first one was use a story or partner with product.

Yeah, yeah, absolutely. So the first step is of course we normally have requirements, we have our user stores and user stories are also an area where there's a lot of need for improvement. And there's new frameworks like acceptance test driven development that get the entire team involved in developing better user stories. Product understands the perspective of the customer, but testers also understand a wide range and diversity of users and end users. And so being able to understand that from the beginning and implement that with within the user stories is just going to allow the process to be even more efficient. And so that, that may be the Wonder Woman of culture or the wonder of culture hero that really gets to the depth of what the customer wants. But we still have many other areas around stories, definition of done, automated acceptance criteria, all critical areas when it comes to helping the Product team create great stories.

Awesome. So out of the six, what's the next one? I think it's a measure. Like, are there anything that teams should help measure to help make sure they're on track with their DevSecOps type process?

Yeah, we have our measures that we're used to, which are velocity and defect count. Those are pretty standard and have been around for a long time. One of the couple of other areas that I think are critical is understanding the measurements from our customers and our end users. And that can be hard depending on who your end user will be. But I personally feel like you can't measure quality with the number of defects or the amount of test cases that are passed. There was a time when I did that and there was times when I had teams that would do that. But I had a unique opportunity to lead all of operations, which was development, testing and customer support and maintenance, operational support. And it just gave me a.

Opened my eyes to what we as a development and test team felt was quality versus what was really value added to the customer. And so understanding the customer side is critical. And then also understanding measurements from the operations side, we often are including in DevOps, we're including operations, we're letting them know, hey, this is what's coming. We're including you. So you know how to support this, but not often do you. We come back and say, hey, operations, how can we help you? How can we get the feedback that you have of what's going on in production and incorporate that back into our retrospectives, incorporate that back into our process and how we develop?

Stacy, one of these that I think all teams, well, teams I used to work on had struggle with was security. They had it on their definition of done, but no one really knew what to do with it. Is that something someone could do to help be a hero is help push more security efforts or security initiatives within their teams?

Oh, yeah, absolutely.

I still find that security is not as mature as it should be in the DevSecop process. And as you are right, it's there, but it's just there with the list of iddies, scalability.

Security, all of those. Just like, make sure those are done. It's like one line and a definition of done and normally it's ignored.

I think what I found is the villain of fear comes in play as well for developers, for developers. Like, you know what, I have so much else that I'm doing. I got to add this in. I don't even, you know, how do I get this started from the testing perspective? It's very similar. Where do I start? How do I know I'm doing enough? And the thing with security that my team and I have found is.

There'S probably never enough. There's probably never enough security testing, just like there's probably not. There could always be more testing. In general.

I mentioned that DevOps DevSecOps is about iterative improvement. Start small, start with something that you can say, this is definitely a security test. It's small. It could be OWASP top 10 exploit. We're just going to do one exploit, but it's one and then you can go to two and then you can get to 10 and then you can do more application scanning, testing and you can continue to evolve it over time as opposed to saying, whoa, this is huge mountain we're not ready to climb. You can't climb a mountain unless you take a step. So I encourage people to take one step at a time. An article that I read in preparation and said it beautifully that hackers.

They look for low hanging fruit. They're targets of opportunity, not choice. Most of them don't go, hey you know what, I want to hack Facebook. That sounds great. Instead they go, let me see which site has not taken care of the top 10 vulnerabilities. And so most web applications, they still have those exploits. And so if we can even do those small, we may not think are the most sophisticated type of test. It still adds a lot of value to our company.

Okay Stacey, before we go, is there one piece of actual advice you can give someone to help improve their DevSecop efforts and let us know the best way to find contact you or learn more about quality works.

My number one piece advice is be a hero. You will need bravery. You will be scared. But step past that fear, you will fail. But it's okay. That's how you learn the most. So take that step. DevSecOps absolutely needs more heroes. They need people to be brave enough to really push the envelope. And I can be reached. My twitter handle is QueenOfAgileQA. I can be reached there. QualityWorks website is qualityworkscg.com c as in consulting and gsingroup.com and I'd love to hear and get feedback as we continue to look for new ways to improve quality testing.

Thank you Stacey for your testing awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com a like automation 280 and while you're there, make sure to click on the try it for free today link under the Exclusive Sponsor section to learn all about source Labs, awesome products and services. And if you want even more tips, tools, techniques and best practices to make you a Automation testing Hero in 2020, you cannot miss the 4th annual Automation Guild, an online conference 100% dedicated to helping you succeed with all things automation testing related to. Learn more and register for this awesome conference. Head on over to automationguild.com so that's it for this episode of the Test Guild Automation Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.