Quality Assurance (QA) testing is often done at the end of the software development process. On a recent episode of Dynamic Developer, I spoke with Deborah Lewis, a Lead Quality Assurance Engineer at Red Ventures, about why this is a bad idea. We also talked about the importance of QA, how QA engineers can work effectively with other teams involved in the developer process (developers, product managers, etc.) and how technologies like automation are changing software testing.
Deborah has held roles as both a scrum master and a project manager. She’s also a co-worker of mine. Deborah and I both worked for CBS Interactive, which was acquired by Red Ventures in 2020 and is the parent company of TechRepublic, ZDNet, CNET and a host of other online properties.
What makes a good QA engineer?
Bill Detwiler: Before we get to talking about what we’re really here to talk about, which is why QA is so important to the software development process and why it’s often under appreciated in that process. I’d love for you to share with the audience, your story. How you got into QA, because you had this great story. And I think it really speaks to the roundabout ways that people often get into software development or technology and how skills that are learned maybe outside of the classic developer path can be not just beneficial, but really critical to building great software.
Deborah Lewis: Sure. Yeah, I think QA is really about being methodical, paying attention to details, having a deep understanding of the product and this can apply to anything. So, I have a background in publishing, I was a proofreader and copy editor for years, and it’s really the same skillset. Trying to improve the quality, that’s the goal always. And also trying to be an advocate for your customer, whether it’s the reader of the newspaper or the user of your Web App. Trying to make sure it’s as clear, understandable, and without error as possible. Perfection is an unreachable goal, but we try to do our best.
So, I worked in publishing for quite a long time, had moved to a website as a copy editor. We had less of a need for editorial content, but had no Quality Assurance person. And I was very lucky in that one of my coworkers and my boss recognized that I had already really been doing QA. Helping test the custom CMS tools that we had. And so they offered to shift me over to the QA team. And then you can learn what agile software development cycles are. You can learn what the product is, you can learn how your team works. But the skills to find the errors are sort of some people like to get into the nitty-gritty and some people don’t.
Bill Detwiler: And I can attest to that as someone who oddly enough has a little bit of an engineering background, but then got into editorial. I will admit to this, I’ll give myself props. I think I’m a decent interviewer, and I’m decent editor, and a fairly okay kind of writer. I’m a horrible copy editor. That is not me. The skill that you have, where you have an eye for transposition of letters. If my copy editor sent me back, one email, they sent me back a hundred about from and form because stupid spell check would not pick up on context.
So, I get what you’re saying. And I think that’s really important that you bring that out to talk about that kind of, not just the skill, because anyone can be taught to look for that. But it really is a part of, I don’t want to say your DNA, but it’s part of a mindset, it’s part of what you kind of enjoy doing. It’s something to be able to have an eye for detail and enjoy picking those things up because that’s what I rely on in my copy editors today. So, you’ve got that problem solving, you’ve got that want to improve quality. But you’ve also got a tenaciousness and sort of that, like you said, the passion to be persistent and to find those details, right?
Deborah Lewis: Exactly. Yes. Because, sometimes you have to be persistent about a change that needs to be made, but you also have to have some of these soft skills about how to present a change that needs to be made and why it needs to be made without coming across as criticizing someone’s work. Because we all want to produce the best quality product we can. So, we all have the same goal and you just have to stick to your guns sometimes when something really doesn’t work, but they don’t believe you, that it doesn’t work.
Bill Detwiler: How do you do that? It fascinates me. Well, actually it doesn’t because both writing editorial is very similar to creating software. We use words, we use video. To communicate something else, software use code. I mean, I quit writing code long time ago, because again, I realized my Fortran, my Pascal, a little C, I kind of got out of it and I realized, “Hey, this isn’t kind of my thing.” And found a different medium to communicate with. But one thing that all writers and it strikes me that engineers have in common is this passion for their work. The fact that they own their work. They see their work as theirs. And that’s really interesting that if you come in with the mentality of, “You did this wrong.” Immediately people can be defensive, they can put those walls up, they can react negatively.
Now, I’m not saying that’s the right way to be. As an author I can admit I’ve done that unfortunately, and then had to go back and apologize. As an editor too, I’ve done that with people and said, “You don’t have to be the other person [amendments 00:06:25].” So, how do you do that? I’d love to hear the actual kind of, because I think that could benefit people in hearing how they deliver that kind of feedback. So, if you’re in QA, or if you’re the coder, or if you’re someone, or the graphic designer, or the project, however it is, who’s receiving that information, how to take it. Can you maybe speak to, or share some of your experiences and what’s worked and what hasn’t worked when you’re sharing that kind of information?
But then again, they may not have thought about how the user or someone else might perceive because we all get blinders on. And again, very similar to the copy edit experience, which is I wrote that this way. Oh, that wasn’t my intent at all. Well, someone who reading it might take it that way. And so, you have to be very careful. So, I understand completely. So, with that kind of in mind and with your experiences, what kind of advice would you give to people maybe who aren’t part of a dev team, like you weren’t, but want to move their career in that direction?
Deborah Lewis: I would say find opportunities where you can step in and help. Find gaps, volunteer to help out, get to know the developers, have conversations with them, join Slack channels if you use Slack or whatever your chat app is. Join the channels where the developers and engineers are, and just read what they’re doing, and learn from that. Just finding ways to help figure out what the problem is, and then help figure out how to solve it. So, it’s like a job interview, if there’s a job posting for a specific role, you want to figure out what problem are they trying to solve and how are you with your specific skillset going to help them solve it?
Bill Detwiler: That’s very good advice for this or any job actually. So, let’s get down to the issue that we are kind of here to talk most about, which is the importance of QA in the software development process. So, what makes QA so important and critical to building good software?
QA should be part of the entire software development process
Deborah Lewis: I guess the quality. I mean, we’re all trying to build quality into the product. It is everyone’s responsibility, but as you mentioned, people can get blinders on when they’re doing their portion of the work. And this extra set of eyes, this fresh set of eyes can really pinpoint things that no one had thought about. In addition, if you involve QA in the entire cycle, you’re going to have a more efficient process. You’re going to reduce your risk, so you’re going to have fewer bugs get into production. You’re going to increase your products value and provide more value to customers. I mean, quality. Quality, quality, quality.
Bill Detwiler: And since you’ve been doing this for a long time, have you seen the risks to not having a robust QA process increase?
Deborah Lewis: That is an excellent question.
Bill Detwiler: I’m just thinking about, all of the things that we rely on our software and apps for. I mean, it was always critical. I’m not sort of saying that, but it seems now to me that there is a lot more exposure, especially with privacy and security. Or just with the ability of customers to go to other apps, other software, to go to other outlets. That it’s even more important now, not that it wasn’t important in the past. But the effects of perhaps allowing buggy code or a poorly performing app to go into the wild, maybe felt much more quickly than they were in the past and the consequences can be more severe.
Deborah Lewis: You make an excellent point one I hadn’t considered from that side. But for instance, an updated redesigned version of a native app. Users are always unhappy about change typically, but this was such a drastic change that the users hadn’t been prepared for. And so, there were lots of negative reviews in the App Store. So, that’s maybe not entirely specific to QA. I mean it was a fully rethought design of the app, but it’s an example of, if you had some other input, maybe you could have pivoted somewhere in that development process or considered preparing the users by announcing ahead of time, these changes are coming. This is what it’s going to change. That’s probably the best example I can think of.
Bill Detwiler: Yeah, no, that’s perfect. I love that example because I think it hits to that point, which is if QA, and good design, and incorporating user feedback should be part of that continuous cycle of CI/CD, really. I mean, if you’re talking about how you want to ensure that kind of you’re updating, you’re fixing bugs but when you’re making changes, you’re also evaluating the information coming into you so that it helps you develop those changes. So, no, I think that’s a perfect example. And I know you and I have talked about something a little bit, which is making QA part of the process from the very beginning. Like, it can’t be, hey, I wrote this, we’re ready to ship it out the door. You’ve got a week to look at it. You got any changes for it? That doesn’t really work, does it?
Deborah Lewis: It doesn’t because, if you haven’t built QA into the process and you leave it as this last step, you’re just going to ship a poor version of your product. Because not only do you have to leave time for QA to do his job, but you have to leave time for the developers to come back and fix the things that QA finds. So, it’s just more efficient. You include us from the beginning, allow us to take part in the discussions. Since we are so intimately familiar with the product, ideally as you’re designing and developing, we can step in and say, “Oh, but what about this? There’s that connection over there.” Because we see the whole picture, but we also know all these, like annoying quirks and details about it. So, I think we’re not just QA engineers, where we’re actually helping giving product feedback, giving technical feedback. We’re sort of the jack of all trades in a way.
Bill Detwiler: You probably, do you think that the QA engineers, you think they know the product almost better than anyone else, even maybe the end users, even the coders, even the project? I mean, maybe the product managers, but I get the sense from having tested internal tools, myself over my career, have filed troubled tickets, having filed a bug tickets myself. Having tested like you CMS systems before they go out as someone who’s a user. You get a much deeper understanding of all aspects of the application or the system, as opposed to even someone who just uses a small portion of it or has those blinders on and only focuses on one small thing. It seems to me that the QA people probably know those products that they work on better than almost anybody.
Deborah Lewis: I think you’re absolutely right. I mean, if we’re really doing our job well, in my opinion, we do understand it better than anyone else because, whatever system you used to track your software development. We use JIRA you’re seeing every ticket that goes across the board. You’re not necessarily working on every ticket, but I at least being sort of a proactive person, I watch the board and I look at every ticket on the board. So, I’m aware of everything that’s happening, even if it doesn’t directly come to me. So yes, I think we do understand from all perspectives, the product. Whereas most people have one track, or tunnel, or silo that they are working on.
Bill Detwiler: I think that’s really important because it gives you a chance to see and hopefully relate to the folks sort of writing the code, how everything works together, right. And how, hey, well if you’ve made this one change, that’s also going to change this over here, which might break that. I’ll give you an example. Just last week, I had a problem with my video and coding system, engineering fixed it, it broke something else. They had to fix that. And so I’m like, why is this not working? Why did it break this
And it’s nothing on them, because I do think that it’s almost impossible to find every small interconnection sometimes, especially with things that have quick fixes or very complicated systems. Sometimes you just need to roll things out and fix the small things later. Just don’t cause a security breach, don’t cause a privacy breach with PII, don’t do something really, don’t bring the site down, don’t-How QA can build strong relationships with other software development teams
Bill Detwiler: And I’d love to kind of wrap up our conversation and I think this is a perfect kind of segue into that with, what advice would you give to folks looking for ways to improve QA within their organizations? And perhaps specifically for QA folks maybe who are looking to build those strong relationships with other people invested in the software development process like engineers, or like product managers?
Deborah Lewis: Sure. I mean, I always will say the earlier you get QA involved in the process, the better. So, that would be go toward how do you help improve the process? I think it’s really valuable to connect QA teams across the organization. They might be working on different products, but I’m sure they’re facing similar challenges or maybe have solved a problem that you are currently trying to solve. And it also fosters a sense of community and collaboration. So, I think that’s really helpful. And in terms of developing relationships with others on your team or in your organization. I think you always want to be trying to add value, in whatever shape that takes.
One thing for QA in particular. I think that people really appreciate is you need to write clear steps for how to reproduce the bug, just get a formula together and be clear every time. I also think it’s great to just always be curious, always listening, always learning. Join those Slack channels, learn what you can from other people, offer your feedback if you think you’ve got something helpful, maybe even if you don’t think it’s helpful. But join the conversation and this will raise visibility for you, for your team. It’ll help people understand what QA does and how we do it. And I think that’s it just participate.
Bill Detwiler: And I think that’s so important. And I love your example of being proactive of talking about how you monitor those Slack channels. Because it strikes me that in today’s world that you’re always having to… The days of being able to sit back and just sort of do nothing, and I won’t say do nothing, but maybe not constantly be talking about how you’re bringing value, and advocating for yourself, and advocating for the work and the value that you bring. It’s not possible in today’s kind of world, whatever you’re doing, whatever industry you’re in.
And this is on both a macro-level and a micro-level, the individual level and at the company-wide level. The department level to think about how we’re doing that. So, I love that analogy. Is it something that you think you’ve always had? I mean, is it something that you learned because as people listening to this think about, well that sounds great. How can I do that? I love those practical bits of advice, which is like clear tickets, be proactive, share the advice. Is it something that came naturally to you or did you have to learn that? And if so, how did that happen for you?
Deborah Lewis: For me personally, I think it came naturally. I’m an observer, I’m always observing what’s happening around me and sort of processing how that fits into the larger picture. I’m always asking if I can help. Well, always interested in helping whether that’s… So, I grew up with horses, so I was always asking where I could help, do you need this done? Do you need that done? When I was working in newspapers, I started out compiling the entertainment listings and then there was, I don’t recall how it came about, but I realized there was a need for a proofreader for the classifieds. So, I said, “Hey, can I do that? Hey, can I try this? Can I try that?” And I think just being a lifelong learner, just being interested, and curious, and wanting to learn. And if you take the steps to learn something, it will carry you forward into the next thing.
https://www.techrepublic.com/article/software-qa-testing-secrets-from-a-veteran-qa-engineer/