Lean Software Testing
Welcome to Episode 61 of the TestTalks podcast. In this episode, we discuss the how to reduce risk with Lean Software Testing with the author of How to Reduce the Cost of Software Testing , Matt Heusser.
Lets face it: software development is risky. What is software risk, you might ask? As Matt putts it, “We can look at the risk of building the wrong thing that is not going to be fit for use. That’s product risk. We can look at the risk that are injected that from theory, we read it out of a book, a process that we tried to make happen on the team doesn’t really work for us, and that’s process risk. Of course, there’s a software buggy risk.”
But how to do we help reduce these risk that fits in with our company’s unique software development process? Matt shares some Context-Driven ways to help guide us around some of the most common risk that he’s seen in his consulting career as the founder of Excelon Development.
Listen to the Audio
In this episode, you’ll discover:
- How to ask the right questions to uncover risk in your software development process .
- Why there are no “best practices”.
- What is context-driven testing and how it can help you?
- Tips to improve your testing efforts
- Measurement dysfunction and what to do about it.
#ContextDriven I’m going to own my own process. I’m not going to just do what I’m told like I’m working a assembly line @mheusser #TestTalksClick to tweet
Join the Conversation
My favorite part of doing these podcasts is participating in the conversations they provoke. Each week, I pull out one question that I like to get your thoughts on.
This week, it is this:
Question: What do you say to a manager who screams “KNOW YOUR ROLE. BE YOUR ROLE” ? Share your answer in the comments below.
Want to Test Talk?
If you have a question, comment, thought or concern, you can do so by clicking here. I’d love to hear from you.
Subscribe to the Podcast
If you enjoyed this podcast, please subscribe via iTunes. Click Here to Subscribe via RSS (non-iTunes feed)
Increase your Kama
If you like what you hear on TestTalks go to iTunes, subscribe, give us a rating and hopefully a five star review. If you’re cool enough to do that I will give you a personal shot-out on an upcoming episode!
Read the Full Transcript
Joe: Hey, Matt. Welcome to Test Talks.
Matt: I’m pleased to be here. Thanks.
Joe: Awesome. It’s an honor to have you on the show. Before we get started, could you just tell us a little bit more about yourself?
Matt: That’s a long story. I’ll try to tell it tightly. I’ve been in technology for my entire adult life. I got a math degree with a concentration in computer science in 1997, and on the Tuesday after Labor Day weekend, I started working as a programmer. I worked in an organization that didn’t have any testers. I remember my first annual review, they asked us, “How are you doing at various things?” One of them was, “What could you improve?” I said, “I can’t have a lot of bugs,” and my supervisor said, “Ah, bugs are going to happen.”
I wasn’t really happy with that and most of the story of what I’ve done since is trying to do better. I went to school that night. I got my master’s in CIS because I didn’t have that tester safety net, then found out that there were these things called “testers” that could provide services to help reduce risk and getting exciting about that. I did project management for a while to work on the metagame to improve the skills of the team. I was a test lead for a while, and in 2011, I took my little consulting company full-time and have been doing consulting in the area of risk management ever since.
Joe: Is this how risk management relates to software engineering or projects? Could you tell us a little bit more about what that means by risk management?
Matt: Yeah. I think you could say my whole career is a dance around risk management, and there’s a lot of risks involved in software, so I’ve spent a lot of time doing testing. That’s probably where my reputation is the most in terms of finding the defects that matter to the people that matter under time constraints and conditions of ambiguity. That’s probably where I spend most of my time.
The book is “How to Reduce the Cost of Software Testing”, which is like I know is the most boring title ever. It’s a collection of essays. I think I wrote four or five of them when I was the senior editor for the piece. If I had to do it over again, I’d call it “Lean Software Testing” because if you look at all those essays, and took your head and squint, that’s really what comes through, and that was in 20 … I think it’s published in 2011.
I didn’t really define “Lean Software Testing” as a method until 2014, so there was a lot of spinning around and learning that was happening, and a lot of that was, “Let’s give a name for these things that I’m already doing on projects that work,” but risk management is all across the board now.
We can look at the risk that the … We’ll build the wrong thing that is not going to be fit for use. That’s product risk. We can look at the risk that are injected that from theory, we read it out of a book, a process that we tried to make happen on the team doesn’t really work for us, and that’s process risk. Of course, there’s a software buggy risk. I think all those are interesting, and I’m excited about all of them. You could think of my career as a dance around risk. I wouldn’t disagree too much.
Joe: If someone is getting involved in software testing, do you recommend that the first thing they focus on are the areas in their application that could cause the most risk? Is that how you would maybe boil it down to something really simple, or is that just making it … Oversimplification?
Matt: If I didn’t know anything else and had to give a context-free answer, that’s probably fair. Yeah. I would say what’s needed by your team right now, figure it out and do that, which is another context-free answer. I know, but we have to dig in to the … What problems are the teams dealing with? What kind of software are you trying to build? What are the consequences of being late versus what are the consequences of delivering the wrong thing? You come up with a solution. I’ve got methods and I teach methods that can be applied on any kind of project to improve a specific thing. We want to improve repeatability. We want to improve reliability. Even then, you have to pick which thing you want to try to improve.
Joe: You just asked a bunch of good questions like about a project to help a tester know what to test, so I think that’s a critical skill that a tester or anyone needs to have when they work on software development. Do you have any tips around how someone can get better at asking the right questions when they’re testing software?
Matt: That’s a really great question. If you go to context-driven-testing.com, context-driven-testing.com, that … There’s the principles of the Context Driven School, which I belong to, and I’ve officially sent the email, I think going on 10 years ago now, saying, “I’d like to be associated with this school.” Context-Driven Testing basically says that the context of the project defines what’s success is.
A manager from Boeing working on avionics who was injected into a video game project for the iPhone and a manager from that same video game project who quit and started working for Boeing, they would each bring with themselves experiences and ideas that were not good for their new environment, so I would … If someone said, “I want to get good testing,” I think context is important. “I want to understand how to get better at it.” I would say seep yourself, indulge in the context-driven software testing literature.”
Go to Google, and type in “context-driven software testing how do I do it”, and see what comes back. I could probably come up with a sound bite, probably come up with a couple of things, a little nugget if you give me a little bit of time, but there’s a lot to observe there.
Joe: Yeah. Just having that link, I think it would be a great resource, and I’ll have it in the show notes, so that’s awesome.
Matt: Yeah, yeah. Offhand, another thing to look to is … it needs work, but I think the ideas that … “The Lean Software Testing Canvas” is another one you could look to. It asks questions like, “How long does it take us to deploy? How many times do we want it released? What is good enough for the customer?” Those sorts of questions can be helpful.
Joe: Awesome, so I guess my next question is … I guess I’m easily confused by … I hear all these terms a lot like, “I’m a context-driven tester,” or, “I’m an agile tester,” or, “I do domain-driven testing or lean software testing.” What is context-driven? Is context-driven something a tester can do in any given kind of software methodology, or is it a software type of methodology that someone would apply to a project?
Matt: It’s really strange. If you go to … Let me see if I can find it. Context-driven-testing.com. The principles of the Context-Driven School are any practice depends on its context. There are good practices in context, but there are no best practices. Projects unfold over time in ways that are often not predictable. Product is a solution. If the problem isn’t solved, the product doesn’t work. Then, these tell you how to do testing.
Saying “I’m a context-driven tester,” all that’s saying in my opinion … Maybe two things. One is, “I’m not going to be … I’m going to own my own process. I’m not going to just go in and just do what I’m told like I’m working an assembly line like I’m at McDonald’s. I’m high-skilled, probably well-compensated, hired for my expertise, and I’m going to go in, and figure out what the factors are in the project, and do the things that I think is going to be most valuable. Depending on management, I might negotiate what that is. Of course, they might not like that, and they might want me to change, but I, I’m not going to be the victim of the process,” is the first piece.
Any of the other things mean, rapid, agile, all of the other kinds of testing, a context-driven tester could pick, and choose, and use what he thinks makes sense. If the whole team is aligned around agile, he might say, “I’m in an agile organization, so I’m adapting to that context.” I think that’s okay, but it still has some autonomy there.
The other piece of the Context-Driven School that people often miss is this idea that people working together are the most important part of any project’s context. I guess the only part of the Context-Driven Manifesto that isn’t derived from pure logic that is saying it’s humanistic, people matter. You give good people a bad process, they’ll fix it. You give bad people a good process, they will screw it up, so people matter. People trump process.
Joe: I’m just trying to think of my projects I’ve worked on, so we work on a medical device, FDA type of thing, and so the context there, the way I test that is going to be different than I would test a … If I’m testing a Groupon, and that’s okay because I think sometimes … Is context-driven also mean that no agile thou shall do this, this, and this, but that may not apply to what I’m doing exactly to what someone else may be doing at another company, and it’s up to me to think through all the differences that may be different in my situation, and then tell management or to educate people on to why we should be doing something different for our particular project?
Matt: That’s it. Yeah, that’s a huge part of it. I think you got it there. Now, for an FDA … There’s some research on this. If you google “Four Schools of Software Testing Bret Pettichord”, maybe you can put it on the show notes, he actually came up with the Agile School, the Factory School, the Analytical School. The context-driven person says, “I’m going to be responsible around process and figure out what makes sense to me.”
There are what we call “exemplars”. Context-driven people tend to lean toward exploratory testing and Session-Based Test Management, and there’s a bunch of these little things that we tend to think about, which I find fascinating. I think it’s a really good thing. As the test tools have gotten better, as WinRunner gave away to Selenium, context-driven people have started to explore and play with the tools more.
I think that’s good because it says that, “Hey, their context is changing. The tools are better. Let’s start using them,” and we’re not as married to dogma as you might be if you were told what the best practice was and you stuck with it, but we give this affinity for exploring. This is the tool in our hip pocket for most context-driven testers most of the time.
One thing that I’ve seen happen on regulated projects is we come in, and we’re told, “Thou shalt define all test cases. Print them out, and sign them with a physical pen when you have completed the test run. Therefore, you must.” It would be a weak context-driven to say, “Okay. I guess this is the context. I got to do the thing.” Right? It’s different than games, so it’s fine. At least, when you go over to the game shop, and they say, “How do you test?”, you’d say, “Well, I examine the rules.” The game shop, I don’t have to do that by law. I won’t.
There’s been a few people … Stephen Jones is one, James Bach is another, who actually, in those environments, said, “Can you show me the regulation that requires me to do this? Can I read it? What does it say?” “Oh, it doesn’t actually say that. It just says we have to have a process, and follow it, and provide evidence that the test occurred, and we chose to implement that through the signature.” “Yeah … No, that’s not a good use of my time,” and then negotiated a process that would provide the evidence a customer needed while minimizing the time spent documenting because most of us actually like to test and want to spend our time actually doing testing.
That’s a strong context-driven answer, and sometimes, the answer is, “Nope, here’s the law. This is the customer. This is the spec they gave us. If you want to keep working there, you’re going to do that.” But I’m amazed at what people have been able, including some of my own work, to negotiate going in with that sort of context-driven attitude.
Joe: That just blow my mind. I’m about to go off on a rant. I worked for projects. Once again, like I said, I worked for FDA. I’m going to ask, “Okay. Why are we doing this?” “Well, the FDA might ask for it.” “But can you show me?” I’ve asked that, “Can you show me a list of what they’re looking for?” “Oh, they can ask for anything, so we need to cover everything,” and so we start to … This is really weird. We start just doing things to work for our process that may not even be cared about by the FDA, but we’re doing just because we’re so afraid that if the FDA comes in and says, “No, you can’t sell your software now,” we’re going to put our company in jeopardy, so it’s one of those weird kind of things to try to pinpoint exactly what you actually need to do in that situation.
Matt: Yeah. I worked with an architect years ago, and he actually had a strategy, and we were audited. We were HIPAA compliant, health care, but not FDA. He said, “If you go through an audit and …” It was SAS 70 was the audit. “You go through an audit and you passed with flying colors, that means you probably did more than you were asked to do, and if you don’t see business value from your extra documentation, the extra work above and beyond what you needed to do to pass is waste, so why would you do it? So what you should do is get a few severity, lowest minimal errors on any audit that you can fix within 90 days with no consequence. If you don’t get any errors, the auditors say, ‘Yup, you’re good,’ then you’ve introduced waste on to the project.”
There may be projects where you don’t care about that. Say, you’re working for an aspect of the federal government, then it’s just, “Hey, we just get to build more hours this way.” That would cause me some emotional trauma. The projects that I’ve been on had been free market projects where if we introduced waste, we make less profit, and everybody gets a smaller bonus and smaller raises.
Joe: Now, that’s a great point. I know you work and collaborate with a lot of teams, a lot of companies, so how do you make it so that teams aren’t playing with numbers?
Matt: Certainly, measurement dysfunction is a real problem. I think Goodhart’s law is when any measure becomes a target, you’re in trouble. If we start saying … I don’t know. We’re going to pay a bonus for the testers by how many bugs that you find, what you find is that the testers go for the easy and shallow bugs over the hard and the hard, but important ones. Right?
You find a bunch of bugs in the spelling of the About page and each typo is a file bug. I’ve heard people say, “Oh, [I’m in a sure 00:14:55] organization, that won’t happen,” but the reality is, is when you tie in incentive to a reward to a measurement, you’re going to get more the measurement, and that might not actually be what you actually wanted which is productivity.
In a particular example, I would think it’s pretty easy to sidestep. I mean, depending on your role. I would say, “Well, we found bugs. These are the bugs. Do you want us to ship or not ship? It’s your choice.” In one situation I was in, I actually asked out loud, “Do you want me to just stop filing if you want me to not find them because I’m really good at not finding them? I could leave today and just not find them.”
Your job as the tester is to find the bugs. What management wants to do with that is their job, so just find the bugs. “So what? We found seven bugs. Do you want to ship or not? It’s up to you. Do you want to fix them and delay shipment? It’s up to you. Why is that an issue with test?”
Joe: That’s right. I guess maybe it’s an older mindset that the QAs are quality gate almost, but in this response, you’re saying, “Here are the bugs. Leave it up to the business to decide. Is this worth shipping or not?” I guess.
Matt: Right. One thing you can say there is, “Woo, woo. Can we talk about my role? My job is to provide information to decision-makers about the status of the software under test. I can’t prevent the bugs. They’re there, and I found them. Do you want me to not find them?” When you express it that way, there’s two possibilities. One is the person will say, “Oh, of course. You’re enabling me to make good decisions, and I need to know what’s going on. That’s what you’re there for. Please tell me.” Right? Which I think I’ve been fortunate to always have.
Sometimes, they say it reluctantly. Sometimes, they say it embarrassed. Sometimes, they say, “Man, you’re putting me on an awkward position, but yeah, I’d rather know.” That’s fine. I understand. I hear things that some managers said, “I don’t want to know. I want to just ship it because I want to get my bonus when it goes out on Friday.” I don’t think I’ve ever been in that position, or if I was, people knew that would be a problem for them, so they didn’t tell me. Then, we can just all go home, and go, and not do anything.
When we start thinking of testing as this, the checkbox, “Can you check, so we can go to production?”, that causes real problems. Why test at all? I can find no bugs like the intro, the prelude. I forget what the foreword … The first word in the book “How to Reduce the Cost of Software Testing” is “Of course, we can reduce the cost of software testing by not testing at all. Let the customers find the bugs.” That’s not what this book is about. This book is about reducing the cost of testing without introducing risk. That’s what I’m really interested in, so I try to sidestep on role. If the sidestep on role doesn’t work, I need to seriously consider if that’s the company for me.
Joe: Right. That’s great advice, great insight. It’s going to sound like I’m jumping all over the place, but I just want to revisit something.
Matt: Please, this is fun.
Joe: When you talked about context-driven earlier, you mentioned that one of the main tools in your toolbox is exploratory-type testing. For someone that, like I said, is really new or have a misunderstanding of exploratory testing … Some people think exploratory testing, they just think it’s totally unstructured, just piddling with an application without any guidance. How would you explain what exploratory testing is?
Matt: It really depends on the problems that I’m trying to solve. If someone hands me a CD or a URL and says, “We want to go live in an hour. Can you check it really quick?”, and it’s a very simple form application, if you sat behind me and watched what I did, it might look to you like unstructured work. It might look to you like I’m just doing stuff. “What? He’s just doing … That’s weird. He just keeps looking around.” Much like if you watched a master, grandmaster at chess and didn’t really understand the game, you might have a similar thought.
Yes, there’s a lot happening. There’s a lot. It’s complex. There’s a lot of modeling. We’re having the modeling, and the execution of the tests, and the reporting, and the learning about the software. They’re all happening … You might say in parallel. You might say simultaneously, or at least they’re trading one off after the other. You do something, you learn about it. Based on what you learn, you conduct a different test.
To someone who isn’t trained in that, it looks unstructured. I would say that they’re just not trained at that. As the amount of time that you spend gets larger and you’ve stopped saying an hour, but instead start saying, “This is going to be a 10-sprint project, and a sprint is two weeks long. We want to do some sort of final checking every two weeks before we … Before the demo, and then we’re going to break the work into small stories. You need to come up with a strategy that you may need to be able to explain a document and defend to be able to talk and think about how you are doing testing.”
That will probably be significantly more lightweight than what we were talking about 20 years ago with regards to testing, and it will let you actually explore. It will give you the freedom to go where you think the risks are for this release. You can look at things like the change lock, the features that were released, interviews with the programmers, interviewers with the customers to figure out, “What are the absolute we have to see? What matters to them? How are they going to use it?” It’s in production. You can look at the logs for how the software is actually being used to come up with the best use of that Friday before release, and that looks very different than, “Take the requirements. For every requirement, the system shall write a test, make the sure the user can.” Right?
Matt: I would argue that if you’re good at risk modeling, there’s a couple of great … The Heuristic Test Strategy Model has a half-dozen different ways to look at all the risks on a project. If you look at that in a systematic way, you go through all the risks on the project, you identify which risks you want to do something about. You figure out the kind of thing that you could to do about it. You stand that up against the consequences. If those things break, you sort that, and you go through that until you run out of time for the amount of time you’re willing to invest.
That’s a whole lot more responsible. That’s better testing than this kind of requirement-based testing that someone would argue is … I don’t know what they call that. Requirement-based testing. They think that’s better because documents, I guess.
Joe: Yup, better traceability probably. If the FDA came in and said, “Where is your test? That test is requirement,” they need to have the tracing thing. “We have this test. That traces to it, and this test.” They sat doing all these weird mappings, I think.
Matt: There’s a tool called “Session-Based Test Management” that was invented to provide you that kind of back-tracing. What you get out of that is you get session reports, you get metrics on the number of sessions you’re accomplishing per day, and what requirements those trace back to, and you get bug reports, and those have been … I understand that those have been found to be sufficient evidence for a class 3 audit of an FDA medical device. That’s how I would answer that question like yeah, there are things context-driven people have invented to provide that documentation.
Joe: Sweet. Along the same lines, in the book that you contributed to “Agile Testing: Learning Journeys for the Whole Team”, I think you have a section where you talked about session and charters.
Matt: Mm-hmm (affirmative).
Joe: Is that the same type of session that you just mentioned?
Matt: Yeah, and I should be very clear there. Session-Based Test Management, to my knowledge, was invented by the Bach Brothers. It’s James and Jon Bach. James contributed to the Context-Driven Testing Manifesto. He’s one of the co-authors. I didn’t make it up. It’s not my idea. It’s a way of structuring the work to provide the evidence, and provide metrics and measurements for management. I think that you can get surprisingly far these days like that was invented before agile … Before extreme programming was popular. It might even been invented before extreme programming. If you just do story-based testing, and you document what you tested for every story, you get traceability for free.
Joe: I’ve been hearing a lot about how companies are shifting left. Do you think developers could do testing, or how do you see a tester’s role changing in that type of environment?
Matt: Yeah. I teach a class called “Lean Software Test”, “Lean Software Delivery”. It started out in testing, and then we’ve expanded it to cover the whole delivery cycle. It’s very compatible with this Shift Left idea. If I were to articulate Shift Left, it would be, “Gee, testers find a lot of bugs at the end. What if we got involved earlier in making … Building the software right, so that it was higher-quality before it got to final test?”
In Lean, the term that I use for that … The common term for that is “first-time quality”. That is the first time we do the project management, we pick the right stories. The first time we do the analysis, the stories are defined well. The first time we develop the code, all of the obvious … It should just work. Sort of things have been done, so that when we get to final test, we can flow through very quickly, so we don’t have to stop and file a bug report because login doesn’t work, right, or the whole thing is wrong.
That’s first-time quality, and Shift Left is very compatible with that because it’s saying, “Get involved with the testers earlier in the cycle, so that we can improve first-time quality. Ask the questions, the hard questions.” Seeing your testers are familiar with this where we find a bug, and we go to the developer, and he says, “No, it’s supposed to do that,” and we go find the product owner, and he says, “I never thought of it that way,” and we have a whole another conversation, he got to build it again.
If the developer had just known what he was supposed to build in the first place, we could have eliminated an entire “find it, document it, argue about it, fix it, retest loop”, and I think Shift Left is trying to do that. We’ve been trying to do that for 30 years, but there was a conference in the ‘70s. Bill Hetzel wrote his book, the first book on testing. It might have been the ‘60s. Chapel Hill Conference. I think there were probably ideas in there to Shift Left.
What I think has happened in the last 15 years, which is really good, is that we’ve popularized the ideas that are practical for how to do it besides have reviews and argue about things because that just turned out to be a big waste. Tester in development and unit tests are just a fantastic way for programmers to improve code quality before it gets to a human exploring.
On top of that, I would say whether you call it “Acceptance Test-Driven Development” or you call it “Behavior-Driven Development”, you call it “Specification by Example”, whatever you want to call it, this idea of breaking the work down into small chunks, and then having developer, tester, graphic designer, product owner get together, and talk about what it’s going to look like, and build a shared understanding before the code is written to prevent that stupid argument, I think that’s a really good thing. If you want to call that “Shift Left”, that’s great.
Joe: Are there any books or resources you’ll recommend to testers to help them with software testing?
Matt: Oh, so much. I mentioned James Bach before. He did a lot of pioneering work. His website, satisfice.com, he has a blog off there. He has his Heuristic Test Strategy Model and his slides for his class, “Rapid Software Testing”, are available for free if I recall correctly. Lee Copeland has a book on test design. It’s really, really good. It’s a shallow coverage of a bunch of test techniques. It’s a fun read, so that might be something to look at. Dr. Kaner’s got a site called “testingeducation.org”, and a lot of that material … I think maybe all of it is online there for free download. You just don’t get a proctored instructor, and you don’t get the community sharing.
I publish something once or twice a month for CIO.com. You could go read those. Those are mostly high-level manager … Their thinking about the software development process. I think it’s important for testers to be able to communicate up to customers to be not just stuck in our cubes, and I click the thing and write the bug report, but instead, position ourselves as advisors when possible.
Joe: Excellent resources. Could you tell us a little bit more about your consulting company?
Matt: Yeah. We started in 2011 with me doing on-site, full-time, long-term six-month contracts doing testing and helping others do it, and I still do a little bit of that. We have other people on the team now that do a lot of that, so we do actual testing. We do consulting and training, so it’s very common. I want to work with a larger organization. They bring me in for a day or two, three. I interview people.
There’s often a strategic objective like, “We want to get into test tool, and we want to reduce our time for regression testing.” “We’re having this particular problem. Can you help us?” “Too many bugs are getting to production.” Whatever the problem is, they’ll write an assessment, and at the bottom of that, it will have ways we could work together, and then we talk about what makes sense as a follow-up. “Should I be on-site one week a month for six months? Should we do some training?”
Common training class that I offer is my Lean Software Delivery, Lean Software Test courses. Those are from one to three days. The one-day version is typically focused on the Lean tools, which are ways to identify waste in the software process and to measure our performance in a predictable way that doesn’t cause dysfunction, and then see performance go up. That typically leads to more releases more often with less time testing and hire first-time quality, the doing of testing through contracting, the consulting, the training, and we do a little bit of placement and a little bit of writing for software companies actually. That’s pretty much all our offerings.
Joe: Awesome. Are you going to be speaking? Any conferences coming up that people can catch you?
Matt: Yeah, sure. My company is organizing TestRetreat: Grand Rapids, August 1st in Grand Rapids, Michigan. Then, I won’t be speaking. TestRetreat is an open space on conference. We create the schedule the morning of. I will propose sessions there, and it’s going to depend on who’s the audience is. If the audience is very senior, we’ll be proposing sessions on Lean, and I’m running some exercises that are my cutting-edge new stuff that I’m developing. If it’s more junior, I’ll be proposing what is context-driven or introduction to context. “How can I learn?” kind of stuff. Introduction to Quick Text. A lot of those sessions turn out to be conversations, not traditional presentations, and that’s fine.
After TestRetreat, on Monday, I’ll be on the program chair for Cast, the Conference for the Association for Software Testing. After that conference, I fly out Wednesday night to go to D.C. for the Agile Conference, Agile 2015, where I’m the track chair for the Enterprise Track. In fall, I think I’m going to Agile Vancouver to do a day of Lean, and then I’m going to go to Kitchener, Waterloo probably to do some training at their conference. I’ll be in Potsdam, Germany in November for Agile Testing Days. I think that’s most of them, so it’s going to be a busy fall.
Joe: Matt, before we go, is there one piece of actual advice you can give someone to improve their testing efforts, and let us know the best way to find or contact you?
Matt: My website is XNDEV.com, and I’m M-H-E-U-S-S-E-R … It looks like “mheusser” on Twitter. One piece of advice? See, it’s like we’re going to best practices, right? We’re going back to what’s the one thing that everyone should know, and the whole context-driven thing is … It really depends. I would say what does my team need right now, what … And there’s a couple of ways, so I’ll tell us a little story, the true story.
I was working for a larger company, and a manager was on a rampage, and he would write, “KNOW YOUR ROLE. BE YOUR ROLE,” on the whiteboard at big letters. I think there were some political things going on at the time, but I would take a marker, and this is a whiteboard. I’d just take a marker, and I would write in little letters beneath it, “Figure out what needs to be done for the team right now and do that.” In other words, focus less on role than on filling the gaps.
I think if you do that, you’re never going to have to worry about having a job because it’s a gap. If people see it, we will lay off when the time comes, and the ax man comes, and people will say, “What can we do? Like who can we cut? Well, we can’t cut Sally because without her, thing, thing, thing, thing, thing, thing, thing.” That’s the position of scarcity. That’s the position of “Who I’m worried about to lay off?” If that’s where you’re at, that’s a good way to start. If you’re not there and you’re like, “Hey, I could get any job I want. I have skills,” then figure out what’s the next thing for you and start doing that. I guess that’s advice, but my answer is it depends.
One more thing I just heard this week. I think it’s real and actionable. If you find yourself in an interview where you’re asked a very specific question that seems to you to be odd, and they want a very specific answer like, “What’s the difference between smoke testing and stress testing?” Right? And there are terms that are … Those are defined terms. Maybe like, “Give me an example of gray box testing,” where like you know there’s no real definition for that, right?
There’s no agreed-upon definition for gray box testing, and you start to say, “Well, it depends. When I hear that, I think this. What do you think?” and you’re not getting a response. You’re getting like stone-cold like, “No, just tell us the answer.” Right? “There’s one answer, it’s our answer,” and it doesn’t really have anything to do with testing. It doesn’t really have anything to do with … Right? It’s not really about the job. It’s about memorizing a list of terms that you might or might not have access to.
When you try your ducking-groove move where you say, “Well, I might know it by a different name,” it doesn’t work. Remember, interview works two ways. They might be failing your interview. It might not be you. It might be them, and don’t do something that gets you the job you don’t want to have, so there’s the second piece.
So much of what we do in life is driven by scarcity and fear, right? I’ve been in that place when I was younger. “Look, man. I just want a job. I’ll take … You just give me a job.” When I look back at … “What was the outcome of that interaction? Was I happy with that? How was I motivated by fear? Did I really not believe that if I didn’t get this job, something better would come along later?” Again, maybe you’re in that environment. Maybe you are really that … There are probably people listening to this podcast that work in countries that don’t have a social safety net that are different, but if it works, I’m sitting here today. Operating out of fear hasn’t done me any favors.