Labs Live: QA at Labs with Katrina Ohlemacher and Jon Guest
On this episode of Labs Live, Dan and Tobi welcome Katrina and Jon, Quality Engineers at Detroit Labs. They discuss the role of Quality Assurance (QA) at Labs, the myth that the QA’s job is to break things, and how QA’s role leads to superior product experiences.
Watch episodes of Labs Live and Subscribe on YouTube.
About Labs Live
Labs Live is a stream hosted by Detroit Labs’ very own Dan Ward and Tobi Adebisi, where they bring on guests from the Labs team and our clients to talk about the latest in technology, software design and development, and whatever else comes to mind. Labs Live streams live on LinkedIn and YouTube each month.
Transcript
Dan:
All right. So welcome back to Labs Live. We were on about a month ago, I think, right Tobi?
Tobi:
Yes.
Dan:
It’s been a couple Friday 15s since then, but our very large, long, official Labs Live was about a month ago. And in that episode, we had talked to Bob Walters, the COO of Quicken Loans, the COO and president of Quicken Loans, Rocket Mortgage. And it was a great conversation, learning all about the mortgage process and the role technology is going to play in the future of it, which was great. I know Tobi, you’re always excited to talk to Bob and hear about that stuff.
Today’s episode is going to be awesome. It’s going to be about QA. We’re going to talk a little bit about QA as it relates to Detroit Labs, but just kind of in general, QA. And I’m not going to talk about it. I’m going to bring our guests in, of course, to talk about that. But as I mentioned, if you are first joining, don’t forget, follow us, subscribe, to be notified, all those different things. We tried something new on LinkedIn today, a LinkedIn event. We’re going to see how that works in the future. If you have feedback about that, was it easy to find us? Was it difficult to find us? Let us know. Don’t forget to jump in if you have questions. Our guests are more than willing, they told us this, to answer those. And if not, Tobi and I will do our best. So that said, let’s bring in Katrina. Hello, Katrina.
Katrina:
Hi Dan. Hi Tobi.
Tobi:
Hello.
Dan:
And Jon. Hello, Jon.
Jon:
How are you doing?
Dan:
So we are fantastic. So Jon and Katrina are both QA. QA, quality engineers, quality… Is it quality assurance? Quality-
Katrina:
Quality assurance.
Dan:
Quality assurance. I just want to make sure I don’t mess up. You get live, sometimes you freeze. So at Detroit Labs, and we’re going to talk about that today. And so I want to kind of take a step back, and let’s understand QA as a role in general, not necessarily to Detroit Labs, but as a role in general. And I don’t know if Katrina or Jon, who wants to kick us off and level set for us a little bit.
Katrina:
Well, the way I always think about quality assurance is that my job is to make sure the product does what it’s supposed to do, doesn’t do anything expected, and delivers a seamless, awesome experience for the user. So those are the three big things that I keep in mind when I do my job every day.
Dan:
Awesome.
Jon:
Yeah, just to leap off that, I definitely echo what Katrina said. And also, I like to think about preventing issues as well. I think a lot of people think QA is about finding bugs and addressing them. It’s also about preventing them.
Dan:
I like that. And I think we’ve seen, or experienced maybe, a couple different models of QA, specifically how it takes place on a software project. One of those models, I would argue maybe is the old school way or somewhat old standard way. And that is the, do the work, hand it over to QA, over the wall, down the road, down the hall, whatever it is. But handing that over to QA. What type of challenges does that introduce?
Katrina:
In a situation like that, you’re coming into the process very late and any issues you find may be more difficult to address because there are layers and layers of code on top of it now. And when you could have caught it when it was a very small thing, now it snowballed into a very big thing and it takes more time to fix.
Jon:
Yeah. And when the process just kind of gets thrown over the wall like that, I think in a lot of cases, that old school way that you’re talking about Dan, it’s almost looked like it’s holding up the releases and holding up the process. As opposed to being involved early on and catching these things and addressing them much earlier in the process. And then also, when you’re on an integrated team, like we are at Detroit Labs, it’s at least a much more collaborative process and a team atmosphere, as opposed to a confrontational type of atmosphere, possibly, where the QA team is opposed to the development team.
Katrina:
Yeah. That’s something I get from colleagues who work at other companies, who have this kind of more old school relationship with their development teams. They’re not a part of the development team. They’re a step that comes afterwards. And if there’s a hard product deadline and they say, well, we’ll allow two weeks for QA. If QA takes more than two weeks, now QA is the enemy. And that’s something that I really didn’t like about previous jobs. And it’s something I love about working at Detroit Labs is that we are part of the development team from day one. We are watching the product grow and working very closely with the developers to make sure that a situation like that never arises.
Dan:
Yeah, I like that you moved into the, throw it over the wall is the old, somewhat traditional model, but the newer model, and certainly the model that we have at Detroit Labs, is this notion of fully integrated. And for those viewers wondering specifically what that means, it means for us, a project, if you will, has a fully integrated team. So that’s delivery lead, design, development, QA, all working, sometimes assay, all working together. One unit working with the client upfront and creating and building a solution and getting it into the marketplace. And so maybe now is an opportunity to discuss. We’ve level set what fully integrated means. Does that allow for a more agile QA process?
Jon:
Yeah. I think that a lot of times, our day involves pairing with developers, working with them very closely. And as changes are made on the fly and decisions are being made, we’re very much involved in the process and the day to day decision making. And that makes us do our job much better than if it were thrown over the wall to us.
Katrina:
And we take part in the standard agile ceremonies, like retros and stand-ups. And we’re in there with the team, in the trenches. We know everything that’s going on, and that really helps us get the work done. So we’re part of the agile process in the big A sense and in the little a sense, in that it lets us adapt to things that come up as soon as possible.
Dan:
And what does it mean to be part of that upfront process, that process where the conversations are going on with the client, the trying to understand what the challenge is. What does it mean for QA to be part of that process?
Katrina:
Well, for me, it’s helping the client get exactly what they want in the most efficient way. Sometimes because… Like I said, I’m always thinking of the user’s awesome experience at the end. If the client has a certain ask, and it may not feel like the most graceful implementation or the best idea, then we can be part of the conversation where we say, what is it that you’re trying to achieve, and how can we help you get that? And then we can use our years of collective experience as a team, including QA, to get them exactly what they need, rather than maybe what they wanted in the first place.
Jon:
Yeah. And then I’ll… Yeah. And also from my perspective, it’s also very important to get involved in simplifying things down to as simple a solution as possible, while still delivering on the client’s needs. Simplicity is a beautiful thing for user experience. And then also to reduce potential future issues. When things get started out, in an MVP, they have a very distinct set of requirements of what they want. And you never know in the end what you’re going to end up with. And I think it’s important to simplify things as much as possible early on. I like being involved in that process.
Katrina:
Yeah. That’s an important part of just the whole process of the project and QA on the project. Is being part of those early architecture decisions, looking at the way API calls are going to work, making sure that we’re not making too many so the performance is good. We’re a part of all of that.
Tobi:
So for you, as a QA, going from the past experience of being on a separate team and now being on an integrated team, how has that, like you’ve talked a little about how it helps the project, but as a QA yourself, how has that changed your career? I’m assuming positively, has helped you grow, but what are some ways that that change has affected you?
Jon:
For me, with working so closely with developers over the last, I guess four-ish years, it’s been a learning experience in that every day I understand developers’ pain points even more. That helps me work more closely with them to work through issues. Instead of saying, I found this defect and here’s the thing that we need to do to fix it, it’s more of a compassionate, empathetic interchange or exchange between the two of us, to come to some common ground of how we can get this fixed and out the door.
Katrina:
Yeah. I understand a lot more about how developers work and what chain of events might have caused an issue to happen if I happen to find it, and then I can make a suggestion. Just say, maybe it’s here. Maybe this is something that we need to look at. I’ve learned so much more about how developers, designers, delivery leads… I’ve learned a lot about the whole software development process, as opposed to being a tester sitting in their own pod among other testers.
Tobi:
That’s great. Is there anything you found challenging with this new style of working? If any?
Jon:
It can be challenging at times, as you’re trying to catch things as much as possible before they happen. It can get a little stressful in terms of trying to think of everything, so you just kind of have to let go of it. It’s not possible to consider every use case and everything that could possibly happen, but just to do the best job that we possibly can to prevent those issues from becoming.
Katrina:
That’s true. The more you’re enmeshed in the team, the more responsible you feel for the product, which in many ways is a really good thing. But when you start taking bugs personally, which is something I think all of us have done at one time or another, then it’s not great. So learning how to take that step back and recognize that it’s not always going to be perfect. That it’s my job to make it as perfect as possible, but obviously perfection is slightly out of reach. Learning that has been a big step.
Dan:
One of the things that came up, a strong word that’s come up I think time and time again when we talk about integrated teams, is empathy. And empathy towards everyone’s role being different yet similar, everyone’s role has some level of difficulty, some level of ease. Do you find that… We kind of mentioned QA in previous ways might butt heads a little bit in the old model. Do you find that empathy is strong when it’s that fully integrated unit?
Katrina:
Oh, absolutely. Because we’re all working so closely together, I really understand what the devs are going through. Like I see that this card took twice as long as we thought it would to develop this feature. So if I happen to find an issue with it, then I can say, Hey, I understand that you worked really hard on this. This looks good. This looks good. This looks good, but unfortunately, we’ve got this. So I’m able to recognize much more easily the effort and the blood, sweat, and tears that go into the work that I am interacting with.
Jon:
Yeah. It really helps foster that feeling of team. You’re truly in this together and as much as you can eliminate any of the us versus them mentality, I think the better off the team is. Developers have struggles, QAs have struggles, and the more we can work together, I think the better off we are.
Dan:
So I’ve got two questions that were submitted that if you’re comfortable, let’s touch on those. One is a little bit of a silly question from Kyle, which we expect nothing less. Not sure why we needed to get the little emoji in there, it makes it look a little more menacing. But so there’s that. I don’t know if you have any tips. Dave… So it says LinkedIn User, but it’s actually Dave. Dave said, Cinnabons work on everyone. I don’t know if that is true or not, but any tips for how to get in good with you. Maybe it’s personal, maybe it’s for all QA.
Katrina:
I think showing the same empathy that we try to show you is the best way to make sure that we don’t accidentally slip into that adversarial relationship. Heaven knows I’m trying not to do that, but it takes two.
Jon:
Yeah, like Katrina said about if a card’s taken two or three times longer to work on, we try to have empathy for that. Well, we do have empathy for that and try to be understanding when issues come up. The same thing goes with, if you know that there’s a really tough card coming through that needs to be tested, and you think of any kind of gotcha scenarios or there’s anything you’ve worked on that you stumbled upon, it’s always good to call those out and be better teammates.
Katrina:
Something I love is when developers put in their pull request notes, steps for the happy path for me to test, the way it’s supposed to work. That helps me level set what I’m supposed to be doing. And also when something is really complicated, requires a lot of integrations, doesn’t have something that’s necessarily set up on my machine, I love it when devs recognize that I may not have the bandwidth to do all that. And they offer to pair so I can watch it happen on their machine, and I can verify that the thing works, but I don’t have to go through two hours of setup to test one card. So that’s really helpful, and I get that a lot from my colleagues.
Dan:
That’s awesome. I got one serious question here from Jacob. What kinds of problems does having an integrated QA team member most frequently solve?
Jon:
One clear obvious one, and I think we’re going to talk about workflow later is just preventing any defects from making it into a demo. We demo to our clients on the regular, and it’s important to have those good, clear cut demos of what the functionality is. And again, we’ll talk more about that later, but just having someone looking at the product continuously, identifying issues as soon as possible, really helps the quality on a day to day and week to week basis.
Katrina:
I think this is probably a pretty good time to bring up something that’s important about our process here at Labs. It’s something that’s unique to us that I’ve seen so far, and that’s that QA owns the main branch of the project. So any merges into main have to go through me, and that makes sure that we have a clean main that we know we can rely on. It’s useful for demos, if we want to deploy main to a test environment that a client can look at, that means that we’re putting our best foot forward, and we know that those things work. So that’s making sure that we are not perpetuating bugs by having main be clean is something that’s really important to our process.
Jon:
Yeah. And it’s much, much easier to diagnose any issues we find too because, assuming that we find it on the PR branch, which is usually the case, it prevents it from getting into the main branch, and then we can quickly identify the [inaudible 00:21:10]. This is the code that has produced this issue and we can fix it then. The alternative to that, like on a throw it over the wall type of situation, if it’s the first release of this product, it could be any piece of code that contributed to this. And I think that really helps day to day for developers and QA to debug the issue and fix it a lot faster as well.
Katrina:
Being able to compare a feature branch to a clean main is invaluable to the process that we have here. It works so much better than other methods that I’ve used.
Jon:
Yeah. And we’re able to try different things a lot more as well, to say like, hey, what’s the difference between these two branches? And we’re able to dig a lot deeper to provide better context to the developer that might work on it as well.
Dan:
Jon, you got a nice little shout out from Alex here. So I figured I’d throw it up on the screen so he can embarrass you, which is wonderful. So I think we were going to… I want to talk about one thing real quick. And then Lauren had a really great question on LinkedIn that we’ll circle back to because I think it fits into where we’re going here. I want to talk about a myth and it’s something that, when we started Detroit Labs, software was new to me, and it was something that I heard right away from a lot of different people, and that QAs job is to break things. And I’ve heard that from QA, that oh, my job is just to break whatever the developer puts together. Is that true?
Katrina:
That’s a really easy, simple way to explain to someone who doesn’t understand QA or understand software development. It may be the thing that springs to mind first and foremost. But to be honest, I’m not making changes to the code. I’m not doing anything that wasn’t already there, so I’m not breaking it. I’m finding a problem that was there before I got there. And I think saying that you’re breaking the software, sets up again, a really adversarial relationship with developers, when in fact the best parts of my day are when I merged code that had no problems whatsoever. And I could put a comment on it that says, great job, works as expected, love you lots. And just go from there because I love watching people succeed, and that is the best part of my job.
Jon:
Yeah, a quote comes to mind something along the lines of like, it’s obviously a joke, but a QA’s job is not done when the app is broken, a QA’s job is when the developer’s broken. Which is a tongue in cheek. We don’t go by that motto at all. Because we work on integrated teams and we care about each other. And yeah, our job is to prevent issues from happening. As such, we try to, like Katrina said, our job is definitely not to break it. We want everyone to succeed. We want to prevent these issues from happening as much as possible.
Dan:
So I’m going to go to Lauren’s question because it kind of sets up where we were going to go on this, and Katrina, when we had talked earlier, you had a good way of describing this, which I’m hoping you’ll get to here. But Lauren had mentioned, we’ve been talking quite a bit about the dev-QA relationship, especially as it pertains to the integrated team, but how does QA then, in that integrated team, how does QA help improve the overall design of a product? You can look at QA through a couple of lenses, and one is through the lens of helping a client, but the other one’s through the lens of helping a user.
Katrina:
Yeah. Devs spend their time in code, whereas we spend our time with the product itself, by and large. We look at what’s been built and we watch it grow as the work is done. So by the time an app is ready to ship, I’ve spent more time with it than anybody. And I can recognize as we build things, like maybe this button is not in an intuitive place because I use this app for four hours a day, and I push the wrong button every single time. So I’ve had some really great relationships with designers, where they’ve been incredibly open to my saying, the color contrast is not maybe what it could be for people who have a visual impairment. This button has a small hit box, I keep missing it. Having that open relationship really helps me, it helps the designer, and it helps the product and the user in the end.
Dan:
I was going to say, I think the interesting thing that we had talked about is that QA really plays an integral role in the user experience of the application. Katrina, I think you had the comment, you’re the advocate of the user. Is that what it was?
Katrina:
Ultimately, we’re the advocate for the user. We are always thinking of what somebody is going to do with it. Part of what I do every day is sort of put on a persona. Like who’s somebody who’s using this app nicely, and I’m an advocate for that person. Who’s somebody who’s going to use this app maliciously, if possible. And I’m advocating against that person. Or somebody who’s not an experienced user. I’m definitely an advocate for them because I want the experience to be as easy as possible for every single person.
Jon:
Yeah. And if the design and the UX of the app is better, then let’s be honest, our job is easier and better too, because it’s easier to get around the app and do the testing that we need to as well. Yeah.
Dan:
Yeah. I’m a firm believer that user experience, while certainly initiated by a design team, design individuals, I love that user experience is very much an important part of that integrated team because everyone, at some point, is using this app, is trying to put out the very best solution, which kind of leads me to my next question. We talk about looking at QA through a couple different lenses. So QA as an advocate for the user makes complete sense, but also QA as, I don’t know if it’s an advocate of the client, or maybe a partner of the client, because at the end of the day, you’re trying to put out a solution, not stop a solution, right?
Katrina:
Jon, I think you have the most recent experience with this.
Jon:
Yeah. We’re definitely a partner with the client in that they know their pain points, they know what they want to dress, but they might not know the best way to alleviate those pain points. As an example, if the client wants to push out a change or an update to an application to solve one of those pain points, they might not be sure of the risk associated with that. And so being on an integrated team, we can tell them, okay, if you make these changes that you want, here’s your areas of risk, and here’s what we would recommend based on a release schedule or timing or anything along those lines. We’re very involved in helping with those types of things.
Katrina:
Yeah. I can’t believe we’ve made it almost half an hour in and we haven’t talked about managing risk, but that’s also a big part of what we do. Like Jon said, if the client has a big release that they would like to get out, we can say, maybe Friday is not the best day for that. Or if there’s an update to analytics, which is normally a pretty small change, and they want to maybe bundle that with an enormous new feature, we might say, maybe if we split those up into two, things would go easier for everyone. Making sure clients are aware of the risk as things go out into the wild is a big part of what we do.
Jon:
Yeah. Or just recommending rolled out releases, as an example. If a client is making some changes, but they’re minor changes and don’t need to be client facing immediately, or it’s not resolved a hard release date. We can recommend to do a rollout release, to like 1%, 5%, 10% daily, if it’s higher risk, but lower customer facing changes. Those are the kinds of things we can recommend that significantly reduce risk.
Tobi:
That’s awesome.
Dan:
That’s awesome. Tobi, were you going to jump in?
Tobi:
Yeah. It’s more like a segue actually. I was just curious for people just watching out there and just wondering how you started out being a QA, what was your journey like? How did you discover this career path?
Jon:
Yeah. So I actually worked in fitness before I was in this industry, and I got started as a SQL developer at a logistics company. And they did some restructuring and offered me a QA position. I said, sure, sounds great, and just kind of got started there. Like 24/7, 365, logistics company. So there was always things to prevent and things to work on and issues to take care of. So that’s how I got my start.
Tobi:
That’s awesome.
Katrina:
I started my career in journalism as a copy editor, which means grammar and punctuation all day, every day. So making the switch to QA after a couple of other false starts, thanks to the economic crises that we’ve had over the last, whatever years. After a couple of false starts, QA turned out to be a really good fit for me because I was already looking at fine details and looking at how small things fit in best with the whole. Like how can I work this paragraph to make it into a better story? How can I work this feature to turn it into a better product?
Tobi:
Wow. That’s fantastic. Thank you for sharing that.
Dan:
All right. So Katrina, you mentioned about 30 minutes into this, it goes fast, doesn’t it? So in the spirit of owning main here, as we get ready to wrap it up, I’ll ask each of you two things. A, did we miss anything? Anything you want to make sure everyone leaves here understanding. And then B, what do you love about QA? If you could pick one thing, maybe two, but not three, but if you could pick one thing, what do you love about QA?
Jon:
I can go first. Yeah, so especially in the integrated teams, I just love interfacing with so many different types of roles. Interfacing with the delivery leads, PMs, product owners, designers, devs, on a daily basis is just awesome. Our job can be a lot about digging deep into issues and user flows and test cases and that sort of stuff. But the best part to me is interacting with other human beings, and coming up with solutions to complex problems.
Katrina:
One thing I wish everyone knew about QA is that it’s not a luxury. It’s not optional. It is really important to the development process. It’s not there to slow anyone down. In fact, working in integrated teams, the way we do, we understand the cadence of the team. We understand the pace the client wants to set, and we’re able to help regulate that pace as the team works. So we’re not slowing anybody down. We’re not optional. QA is very important to the process. And something I love about QA, I already mentioned when my job is basically done for me. I like it when people do things really well, and I get to watch people do their jobs and be really good at their jobs. I just really like seeing competent people being competent. And I get to do that every day.
Dan:
That’s awesome. Cool. Well, thank you so much for joining us today. I’m going to move you backstage, but hang out with us as Tobi and I wrap things up here, but really appreciate you taking the time. Appreciate everything you do for Detroit Labs, everything you do for our clients. And we’ll say goodbye to Jon and Katrina, and we’ll move you backstage here.
Katrina:
Thanks Dan. Thanks Tobi.
Jon:
Bye guys.
Tobi:
Thank you.
Dan:
Oh, I accidentally cut Jon off too fast. He was saying how much he appreciated you, Tobi. I’m sorry.
Tobi:
You’re good.
Dan:
We can bring them back in and have them go on. That’ll be nice. Anyways, I think that was amazing. I think if you’ve tuned in, and especially if you’ve heard the word client a lot, obviously we are a services company that builds software for clients, but I think client can be anything. So if you’re a large development team inside of maybe a large company, your client could be business stakeholders. Your client could be a product owner somewhere. It’s very applicable across all development teams. And the fully integrated team, we’ve hit on that obviously a lot, but I think that just has so much value, and we’ve seen over the years, how much value it has. I mean, Tobi, you live through it as a developer.
Tobi:
Oh yeah. We get a lot of great relationships. It’s a different vibe from like, just us, as we’ve talked about in the whole show, just finishing something and throwing it over the wall. It’s very different and I’m glad I’ve been able to work on several teams that have that kind of model as well.
Dan:
That’s fantastic. All right. So let’s wrap things up. We’re at 35 minutes, it moves so fast, doesn’t it?
Tobi:
It does.
Dan:
We could talk for another hour, but we’ll spare everyone the time. Don’t forget, I always have to remind everybody to go to our social channels, follow, subscribe, all the different things that you should do to make sure you hear from us, hear our content. Hopefully find some value in that. Don’t forget last week’s show. We will put some links, I believe, to the shows from YouTube, LinkedIn, and then our podcast. We should remind everybody that these episodes, if you don’t have the time to stream the video, they are also in podcast form. So you can listen to the soothing sounds of Labs Live as you go about your day on audio. Tobi, any last parting words that we need to get out there that maybe I forgot?
Tobi:
Thanks for joining us. Again, it’s been a long sabbatical. It’s been a month, but it’s good to be back here. And just thankful to both Jon and Katrina for taking their time. It was a great episode, and I learned so much. And just even their journeys into becoming QAs, like using something from your past career to help you in this new career is very insightful. So thank you both for joining us, and I think they can hear us there also. Appreciate you both.
Dan:
I’m seeing thumbs up. All right, we’re going to wrap it up. We’ll see you all on Friday, where I don’t think we’ve decided, but I think I’m going to decide for us Tobi. We’re going to talk about current events, kind of like the weekend review like we did the previous week. That was a lot of fun. We’ll do that for Friday 15 or Friday 30, whatever we decide. So thanks everybody for tuning in. Don’t forget to go follow us. We appreciate you. Goodbye.