Welcome to Software Testing Unleashed, the podcast for testers, developers and software makers who live quality as an attitude. Get fresh ideas and sharp insights to grow your mindset, to learn new methods and to drive real change in how we build software. Better software and better teams for a better world. Hi, I'm Richie, software quality coach, keynote speaker and author. My guest today is Chris Armstrong. Chris has been testing since 2004 across many different industries.
He calls himself a pragmatic agilist and a quality practices geek. He advocates for inclusion, collaboration and continuous improvement. He also blogs about his thoughts and observations on testing and co-hosts the Testing Peers podcast where he and others share their experiences as test leaders. In this episode, we talked about context in the term of testing. Why is "it depends" not an excuse but the only honest answer in complex environments?
How can decisive humility, being clear about what you don't know, become a tester's superpower? And why do winners have more failures than losers? We explored how testers can ask better questions, challenge processes and tools, and grow their influence by building trust. You will hear why context is never static, how to navigate uncertainty, and how to turn challenges into opportunities for quality. And now, enjoy the episode. Hi Chris, great to have you on the show here.
Happy to be here, Richie, thank you. Yeah, it's great. It's a pleasure that you are here now in the Software Testing Unleashed and we do an episode together. You were mentioned by so many people that I should interview you, so and now you are here. So expectations are high. Set myself up for failure there. Yeah, but I think you can deal with that.
Yeah, and when we do the preparation call for this episode, we talked about what can we talk about, how can we start in, and there was one trigger word for me, which was very interesting to think about context in the relation to testers and the quality strategy and the testing strategy. So I think this is a very important topic. And I would say, what do you mean with that?
I mean, where do we start? Well, we could start anywhere. But I mean, there's a classic answer that we have when we are asked questions, which is always, it depends. Which the long, long version is it depends on the context, because I can give you an answer of what I think from history, and from experience, and from reading what something might be. But until I understand full context, I don't know what will happen. And as we live in a very
iterative way, we also don't know what may emerge that we don't know already today. So when we talk about context, it's very important to be flexible, to be pragmatic, to be as well informed as we can be today, as much as we need to be to be able to begin. We don't really exist in a world where everything is known before we start our work. And so the value of context is incredibly important, but also articulating that in a way that means that I'm not saying I'm not
doing my job. This is why this is a valuable thing. That sometimes is a harder sell than just doing the wrong thing first. Yeah, yeah. I think that this can be very overwhelming for us in the project environment. We don't know what is tomorrow. We have very complex contexts in our projects in our environments, different systems, all the AI stuff now, how can we deal with that?
Well, I think I was asked a question about what characteristics we need to have as testers in the future beyond the classic attributes of like curiosity and critical thinking. And one of the most important things for me is almost a combination of decisive humility. So I'm very strong, I'm very decisive in the fact that there's a lot that I do not know.
But knowing what to do with that, knowing where I can go to make sure that I am able to find out what I need to know, when I need to know it, I know where I need to go, what I need to read, who I need to speak to is very important. And when we look at changes that happen in our industry, oftentimes people are full of fear of the unknown. And fair enough, there's a lot of things in the unknown that we don't know. However, there is also a lot of opportunity.
And where we are concerned with things like might replace stuff or might be a threat to stuff, it's better for us to be at the forefront of that innovation, of that knowledge, of that direction. So actually treating things with cautious optimism is very, very important as well.
And that isn't easy unless you are in a position where perhaps you can back yourself up or have allies to support you because the traditional mindset is you need to have a very well-known path, know what you're going to do, know where you're going to go. And actually comfort in the unknown is kind of something that we have to become masters of. I think it was really a very important skill and not easy to develop, especially if you live in a country like I do in the German speaking area.
We are very well known for thinking about the problems and the unknown and what could be happen and so on. And I often miss this optimistic view and to say, OK, what can we do with the things we have in control now? It's not always a default mindset. I think as testers, very often we were drawn into our roles because we are good at catastrophizing, good at identifying risks and problems.
But that also doesn't do us any favors in the long run when it comes to collaborating with cross-functional teams and other people because we are seen as cost, as no people, as negatives, folks that you don't want around. And actually, that turn of mindset from failure to success, it's not easy, it's not necessarily instinctive, but that is the way that we win together rather than being diametrically opposed. Yeah, and how can we evolve, how can we grow this
mindsets. So we cannot go to the people and say you have to change your mindset now. So I think that wouldn't work. How can we help people to get this new view, this more optimistic view? So I'm still learning and it is different with every team and every group of people I have the
privilege to work with. Back to that context point, understanding what makes folks tick, what they're interested in, what they aren't interested in, what they want to spend more time in, what they want, what they're finding as a problem, like pressure points in their lives. Understanding those humans that we work with will enable us to be able to articulate what we have identified as a problem area or an issue and then present to them the opportunity. Doing that by
ourselves often is not the smartest idea. I routinely will speak with friends, colleagues, and I call it a sanity check, just to say, look, before I go and speak to this person about this thing, and sometimes I can't reveal too much context, but you know we can abstract some of that. You discuss how you have read a situation, what you would like to do, and you try and check that your approach and how you think something might go will play in the ears of somebody else.
Sometimes articulating out loud a thought process or a plan is significantly more active than whatever just spins around in our own heads. And there is trial and error, but again, that decisive humility where you say, I don't quite know all these things, but I've identified margin area for opportunity. I think this is something that, based on my understanding of this issue that we're having, there's something that we can do together to improve these things.
I think it's also very-- what you said, it's also for me like a perspective change. When I go to somebody to think what are his or her values, what does she or he needs, and to get in better relation with them and then to discuss the things I have to clarify or something like that. Yeah, I mean, ultimately, in our careers, while we might be our own main protagonist in the story, we're not in anybody else's. And we cannot succeed as an island. We need other people to succeed.
We only learn if we learn through other people. We only grow if we work with other people. So appreciating them is incredibly important. I think it was Christopher Nordstrom's program for Eurostar a couple of years ago. The theme of it was software testing is a social activity. I know he's not the first one to coin that term. But I felt that that is so true, even in this day and age with AI and other areas in our lives.
We still have social interaction at the core of what we need to be able to succeed. - And what do you think, how can we learn all this, which soft skills we need for that and how can we learn that? - Learning soft skills is harder than learning hard skills. And often we have to break down how we're doing things and I have to have a lot of self-reflection.
I did, before I was married with my wife, I went through a course on it based on a book called "The Five Love Languages" by a guy called Gary Chapman. And from that, they were saying, you're in this lovely honeymoon period together. Everything is perfect. You can't do anything wrong. But when you are married, you are financially combined. You're intertwined, dependent on each other for success and failure and everything. Your perspectives will change.
And you are two folks that are trying to combine everything. And in many ways, I was able to abstract that into the workplace and go, look, engineers are different. Flavors to customer service people, to technical writers, we're all wired very differently with socially differently motivated. Some of us get very irritated, but we're very into that. We've got introverts, extroverts and a bunch of different people.
So I made a workshop, which I run in a couple of places where it was looking at how five love languages work for us in an engineering space, abstracting from love to more sort of appreciation. Now, thankfully, Gary and someone else have written a book about making this in the workplace. So you don't have
to rely on my interpretations. You've got a professional book on these areas. But it's a way of having that sort of upfront level of understanding of different peoples, what makes them tick because there's a lot of research about focus and diffuse mode that folks have
and they get very irritated and can't get back into work. There's some people are very able to see big pictures, some are very micro picture people and without understanding those people you can't work with them and it's very easy to irritate people especially in a remote space. And we can't see so many of those social cues that we might have. But again, you can learn what some social cues are like. You can demonstrate yourself how you might like
other people to be interacting with yourself. And if we're in a position of influence, and that doesn't mean you have to be a leader or a senior or something, that could just be I'm a tester in a team and I need to advocate quality and I need to tell a bigger picture to people or bring new ideas into my space, that's a position of influence where we can
bring that in. And knowing how we want to demonstrate that to people, again, decisive humility but also cautious optimism and being able to share that with a group, maybe making sure that some folks who are less comfortable in those spaces give them time, give them space. Respect, really important and it takes longer than just the point the finger and say
this is what we will do. Yeah, that's great. I think also that the testers are very influential a role in the whole area as you said the quality advocate and we have to talk to everybody to get our information to our requirements to with Ops how and all the other stuff. So we are on a role which is very connected. And so it's also very, very important to look at this role and this interconnection with the others in this context area. So when-- but the context is not just only other people.
This is also the whole company or the project and all the technology we have there and all the processes and this stuff. How can we deal with that better? and how can we use that more? Asking a lot of questions. People say QA stands for question asker. Why not? If we don't question why something exists, what its purpose is, what the story behind it is, then we might be using the wrong technology. Maybe we've chosen this tool. Why did we choose this tool? What was the path to that tool?
What's the future look like with that tool? Is it being deprecated? Will it be supporting our future architecture? Is there a tool set available that's more broad in the market for front-end developers? Are they using Angular still, or are they using React? Those are important questions to ask. Are we making the right decisions in the industry trends? And so a lot of it isn't just resting on what we have today and understanding today's context. Understanding context is a perpetual role.
Staying still is the only thing you can do that's wrong. If you like, really, it's going forward and understanding those changes. So do we publish roadmaps of our future support? Hopefully we do. Do our do our tool vendors, do they do that? Do suppliers do that with what they've got in terms of knowing where industry trends are going? We're seeing a very strong push for AI. Great. What decision are we going to be making with regard to that?
Which which sandbox are we going to invest our time and tokens in? how is that going to apply with future regulation around GDPR, accessibility, other sort of incoming regulations. We need to know how these things intertwine because that published thing is out of date when it's published, almost always. Same is true of the way that we operate with our own strategies and standards and best practices in the workplace.
It's meeting what we know today, but it needs to be flexible, agile, if you will, to change to to whatever's coming in the future. And that, again, that's that unknown, but it's knowing how I'm going to deal with that scenario. Not every path, but this happens now. OK, I understand. This is where I go to uncover those things. It's being calm and being in a position where I can be proactive in the face of change.
It looks for me like that we testers can also look beyond the pure software quality and question also, as you said, the tools and the processes. Why are we doing this stuff? And it gets more an overall quality view that we want to propagate into the team and to other to reflect these things too. But it needs a lot of courage for us testers to go to someone who decided to buy a tool, and we ask them why did we buy this tool? It does.
And the funny thing is, when you talk to somebody and you're asking their opinions, more often than not, people actually quite like to share their opinions. The way that you frame that question, again, it comes from that failure to success kind of angle. If you came over and said, this was a garbage choice, what is going on here? And they go, well, actually, I was charge of rolling that tool out. You've already started yourself several steps backwards from
a conversation. And that takes away the respect and the sort of humility of where you're coming from in that space. And while you need to be courageous and brave, because I won't know the answer to that if I don't ask that question. And if I don't know that question, I don't have that context. And how can I apply correct solutions or suggestions? How can we do that we don't understand. And sometimes the answer is, I don't know. Because it's happened and,
you know, think something exists over here. And it is, it's a genuine concern we have with AI coming in with, how does that work? I don't know, being an answer that we will see more of. But yeah, you have to be courageous. And it's terrifying, you know, as a teenager, I was myself up inside because I had the unknown decision because not making a decision, not doing something is actually less useful than getting a rejection or a failure because you
cannot move on with an unknown. You can't build on an unknown fluid flux kind of foundation. It doesn't work. Yesterday, when you just mentioned that, yesterday I heard a quote, it was very, very touchy for me. Someone said that winners have more failures than losers, because as a winner, you try, you get into the unknown, you try to deal with this stuff and sure, there are some things that wouldn't work. But as a loser, you sit on the couch and just looking and waiting.
It's true. You know, Buzz Dykstra often pushes the quote from one of his slides that says, never trust a test that you've not seen fail. And I want to see failures 'cause then I can build trust and confidence in the testing that I'm doing. Without failures, I question pure success without any hiccups much, much more than I do from a failure that was a learning opportunity. - Yeah, yeah.
And I think now in nowadays when we talk about all the AI stuff, this is such a great opportunity because this is, for us in testing, more or less a green field. So we have to do this unknown stuff. We have to experiment what works, what not, what are quality characteristics and methods we can use. We don't know because there is a little bit of literature now and some research. But we have to deal with it in practice. And it's a very new field for us. It is.
And I 100% understand the cynicism behind that. It's in many ways symptomatic of what we felt when there was much more of an automation boom 10, 15 years ago. And it's true. That thing that we do today will change. But as we've discussed already, change happens. But being a part of that change is where the opportunity lies. There's a lot of parts of our jobs where we will roll our eyes and we will be frustrated and say, "Oh, I'm doing this today."
Well, if we are at this, like you say, this sort of foundational level in the evolution of AI in our space, what a great opportunity to see how AI can help us do that. We're gonna have to become masters of good quality, prompting, good quality GPT creations to assist us.
Otherwise, someone who doesn't appreciate our craft is going to create something that they've sold to somebody who doesn't do our job to say that we're gonna save you time, money, optimize X, Y, Z, and we will be there going, but no, I don't understand. I didn't read into this. I was just doing my job. We have to be a part of that narrative and that storytelling and driving those things forward.
Because if we don't, not only will software quality in the future fail and fall down the floor, like the lowest possible tier but also we won't know why apart from saying I told you so because everything evolves and changes. Yeah yeah yeah and I think the future will bring much more for us to deal with because we when now wipe coding and all this stuff is coming we will get a huge amount of software in the next months and years and who should test that and who should ask for quality
there. To test the test. Well what does quality look like? Even that perception is going to change. I look at what the media that my children consume and I go that's awful, it's terrible, but for them it's meeting their needs and their wants. You know, I am no longer that demographic for quite some time. You know, whoever that end person is, is going to continue to be what ultimately drives what quality is for a user, the way that we achieve that isn't something that they care about at all.
We care about it because we want to get the best things out that we take pride in for the right people. And you're right, that understanding of a holistic way of working to balance our verification, validation work, it's going to persist. But what we do day to day, wildly different. Yeah, yeah. When we come back to the to the context and when we see the last 20 minutes we talked about questioning everything. So people asking questions and technology and
tools and all this stuff. How can I as a as a tester prioritize this for me? Where to start? Because there's so many questions and so many people I can ask and so many stuff on the project. How can I focus my direction to the things that are really valuable for the project?
It's a fantastic question and one that we get asked a lot by stakeholders and managers because they're like, if you say we need all of the things and there's no boundaries, there's no constraints to what we're doing, then almost nothing could ever happen because we're always exploring forever and that wouldn't work. So the answer is really you have to begin by targeting a few things, perhaps that's with having a few hypotheses based on initial discussions.
So perhaps we have a feeling that there's some issues with release quality. OK, so we dig a bit deeper and speak to some relevant people, maybe some customer service representatives, some pipeline people who might call themselves DevOps, whatever. And we understand those bits, we speak to the testers, we try and get a little bit of a picture painted based on that hypothesis to try and work out why.
We dig into the logs, you know, don't just talk to people, there should be access to the tools and those sorts of things. And we begin to paint those things. I developed a quality engineering adoption framework and the initial premise was all about context, context, context, but without outputs that people can see and measure and understand, no one's gonna buy into the work that you're doing and the why, because they'll just hear you talking. You need to have tangible outcomes for your work.
And so that initial discovery phase, I very much painted along the lines of building up a bunch of working assumptions, things that I will need to sanity check with people to understand as we go, observations that I have, And also things like an appraisal of the tech stack that we've got, questions that we have underlying, the whys, the whats, the hows, gathering problem statements from key personnel. What is it that's going well? What is it that's a pain for you every day?
There's a good tester down the road from me in Wales called Stu Crocker, and his definition of quality is it's the removal of unnecessary friction. We have necessary friction, of course, but what is it that's getting in the way of us that doesn't need to be there? And often asking that question framed in that way, we can discuss that through pipelines that are processes, that are culture, but are also through technology, through our actual physical pipelines, physical, you know what I mean?
And by uncovering those bits by validating them with people, checking them and saying, is this right? Just like when we're running tests and just checking end to end where the blockers are and stepping through, maybe going a bit slower and stepping through each step and injecting failures into bits to sort of understand better where things are working.
We can do that when we're uncovering context within our organizations as well, but it doesn't work if you just, if I wrote a test end to end, never ever run it to understand what it was doing and just threw it in there and go, that's done, no one should have confidence in that. Which is, again, same point with AI, Gen AI sort of test, it's the exact same thing.
You have to have a plan for what you're trying to achieve, a hypothesis, a goal, acceptance criteria, if you will, and then you need to sort of step through it and validate it, get it reviewed by other people, never mark your own homework. All very important. - Yeah, yeah. Yes, some great insight. Thank you very much. Yeah, Chris, we're nearly on the end. So I thank you very much for all exploring of these questions.
I think there is a lot of content in there we can explore in further episodes, too. But it's a great overview and a new-- I think a very great inspiration that you gave to ask questions to the context, if it's people or processes or something like that. meant to say, OK, well, where is my output? How can I focus on on what is really matter for the project and for me? So thank you very much that you were here on the show and hope to see you soon also in person. Yes, I'd be happy.
Yeah, it would be great. And yeah, have a good day. Thank you very much. Thank you for having me very much.