Software Testing Martial Arts
Welcome to Episode 96 of TestTalks. In this episode, we'll discuss the book Software Testing as a Martial Art with author David Greenlees who will explain how to defend ourselves against some of the toughest testing bugs.
Have you ever felt completely defeated after realizing a defect you should have found was released to your customer? Do you find yourself wishing you had some sweet Kung Fu testing moves you could summon to put the hurt on software ninja-type bugs? In this episode you’ll discover how to adapt your testing technique to any software situation and fight back!
Listen to the Audio
In this episode, you'll discover:
- How to tackle modern ninja-like bugs.
- What does software testing have to do with martial arts.
- Why you should ask Why?
- Tips to improve your software testing efforts
- What are testers' biggest challenges are and how to overcome them.
- Much, much more!
[tweet_box design=”box_2″]With martial arts like #testing You need to react quickly & call on past experience.~@DMGreenlees http://www.testtalks.com/96 [/tweet_box]
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 are some of your favorite testing technique for karate chopping bugs? 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.
How to Get Promoted on the Show and Increase your Kama
Subscribe to the show in iTunes and give us a rating and review. Make sure you put your real name and website in the text of the review itself. We will definitely mention you on this show.
We are also on Stitcher.com so if you prefer Stitcher, please subscribe there.
Read the Full Transcript
| Joe: | Hey, David. Welcome to Test Talks.
|
| David: | Hey, Joe. Thanks for having me. I really appreciate it.
|
| Joe: | Awesome. It's great to have you on the show. Today, I like to talk about your new book the Software Testing as a Martial Art: There is no One Style. Why did you write the Software Testing as a Martial Art book?
|
| David: | Well, that takes me back to somewhere around about 2011, I think it was. Basically, I'd got to know Peter Calvari who is a wonderful author in his own right who writes fantasy novels. He was a previous colleague of mine back in a consultancy I was working for in Australia. I published an article, one of the first articles I'd written for an online software testing magazine. My boss at the time it centered around to the staff of the consultancy I was working for and sent some wonderful feedback to me and let me know that he was also a writer and sent a preview of his first novel actually. I got to reading that, really enjoyed it and became actually a part of his review team for that novel, his second novel, and then part of his third novel as well. I guess he was sort of my inspiration.
|
| At the time, I was I guess a little bit naïve. I didn't realize that you didn't have to be a full-time author in order to write a book, and he showed me that.
| |
| I've loved martial arts for as long as I can remember and also I had a few conversations with a couple of martial artist software testers who had sort of inspired some thoughts around some Bruce Lee quotes and how they could be, I guess, shared with what we can learn in software testing.
| |
| I started writing blog posts. Before I posted them, I actually thought this could turn into something a little bit bigger. I guess it just went from there. It took me about three years total duration. Obviously, I wasn't writing that whole time but with big gaps in between. It was a long process. It was one of those things … I guess you keep … As you're writing and as you're working, you keep learning more, and more, and more. I could probably just keep on writing. There comes a time when you have to publish, and so about three years was that time for me.
| |
| Joe: | Awesome. It's kind of like testing that, as you just said, you have to publish. There comes a time where you just have to release the software. It's a good analogy. Something similar. Did you find any analogies between releasing the book and releasing software at some point?
|
| David: | Yes. I guess I had a bunch of software testers as my review team. That was actually quite good because as I'm sure you're aware software testers can be quite finicky when they're reviewing other people's work. I can't imagine there's too many grammatical or spelling errors in the published version because of that, but it was good having their advice. Also, I guess they prompted ideas in which some of them led to another paragraph and some of them led to a new chapter of the book completely. Like I said, I think I could probably … In a year's time, I could probably produce another version, another edition with a whole bunch of other lessons that I've learned as well. I guess that team of reviewers helped me get to a point where I felt comfortable that it was ready to be consumed by wider audience.
|
| Obviously the way Leanpub works … It's fantastic that you can just upload a new version whenever you want to. Anyone who's bought the book can just get that latest version. I don't feel as though I'm hamstrung in that way. I guess it's a little bit like releasing code in Facebook. They can just push out another version in the next hour. I can do the same thing with my book, so it's pretty low risk in that respect.
| |
| Joe: | I know this is available on Leanpub, but is it also available on Amazon Kindle yet? Or will it be?
|
| David: | I haven't yet. I needed to … I wrote the entire book in Microsoft Word, which was fantastic for me while I was writing it, but has meant that it's not all that fantastic for me to convert it to e-pub and all the other, Moby, and all the other versions that are available. At the moment, Leanpub was the best choice because it allowed a straight PDF upload. I am in the process of converting it to e-pub and other formats. Hopefully, … I think I can get it onto Lulu.com which leads to Amazon, I believe. I need to do a bit more research on that, but yes I'll want to get other formats out there, and then also into other online sources as well.
|
| Joe: | Awesome. I just want to talk about the title about the book. I don't know if it's controversial. I'm not into martial arts, but I had a manager that was into martial arts and one of his pet peeves was when anyone put black belt in front of something. Like, black belt six sigma. He would just go crazy about it. What does software testing have to do with martial arts?
|
| David: | I guess it really depends on the reader and their experience. What I've tried to do in the book is to highlight as much as possible, especially for people that perhaps don't have a background in martial arts. You could say that it has absolutely nothing to do with martial arts, but for me personally and for others that have read the book as well, who have studied martial arts, there can be a lot. There can be good lessons and there can be bad lessons. I guess picking up on the fact that you mentioned a black belt, I have a black belt in tae kwon do. It took me around about six years to get that black belt. No disrespect at all to the establishment where I got that black belt, and my grand master is a wonderful man, but in that whole six years of getting that black belt, we trained no contact whatsoever.
|
| Basically, into my black belt in tae kwon do, which can mean a great many things to a great many people, without ever actually being hit or kicked or anything like that. It was basically just a test of my own technique through forms, we call them in tae kwon do. To actually then go out into the street and hopefully I never have to, but face a horrible situation or I need to protect my family or so on, I don't think that that black belt, and even better comments, would actually do me all that much good on the street. I guess from that … Tying that back into software testing, I spent a lot of my early days working for a big government department back in Australia and we had a lot of consultants come in and teach us about best practice for software testing and following this process and that process. You quickly work out that the written process sounds wonderful, but in reality when you actually need to use it, it nine times out of ten doesn't work because your whole work environment doesn't fit that process.
| |
| To link that back to my black belt, if I was in an arduous situation on the street which called for tae kwon do techniques, I might be fine, but nine times out of ten, it's not going to call for that on the street. I needed to branch out and learn different techniques, different martial arts and it was exactly the same sort of thing for my software testing. I need to branch out learn different techniques and experience different contexts and basically do it on experience.
| |
| Joe: | I just assume martial arts is almost like meditation. You have to be very aware of yourself, what you're doing, and your surroundings. Does that help you as you're testing stuff? A lot of times as you're testing stuff, or like you said, maybe you need to use a different technique for a certain problem that is different than you would use for another one.
|
| David: | Yeah, definitely. You need to … Obviously, it depends on the situation, but in software testing, especially traditionally, we're the last people to see a particular product and we're the ones that are squashed closest to the deadline. You need to be quick and, like you said, you need to recognize when something's not working so you can change your approach quickly. Then hopefully, you can find that valuable information that you and your stakeholders are searching for. I guess it's a very similar thing when you are, say sparring for instance. You might be good at a certain set of techniques, but your opponent may actually be completely aware of those and be throwing you all sorts of different things that you're not used to. You need to be able to branch out. You need to call on different experiences and you need to do it very, very quickly in a sparring situation, otherwise the match will be over and you may possibly get hurt.
|
| I guess, there's different risks involved with martial arts and software testing, but the analogy is, once again, the same. You need to react quickly and, I keep saying it, calling on past experience. I think learning theoretical things about software testing is great, but practical experience is the thing that shines through, especially for me. It's a wonderful part of being a consultant. You get to experience a lot of different environments, different approaches, and you can work out what worked for you in the past, what didn't, and what you can try heading into the future.
| |
| Joe: | Awesome. You're have a chapter called Be Like Water. I'm just thinking of all these cool sound effects I'm going to add in later on. Anyway. In there, you describe a water test case. What do you mean? What's this concept of water and how does it apply to software testing?
|
| David: | I guess the lead-in to that chapter is one of my favorite quotes from Bruce Lee. I say favorite, but I can't read it out word for word without looking it. Basically, the concept is be like water. In other words, be flexible. You put water into a teapot, it becomes the teapot. I'm sure people can look up the quote if they need to. Many years of my early testing career, like I said, was built on best practice, something that I don't believe exists in software testing. We were taught step by step, procedural test cases. Step one, log in. The expected result is that you successfully log in. Step two, click on this link. Expected result is that you navigated to wherever that link's supposed to go. Many, many, many hours spent writing these test cases that either ended up being incorrect or were executed once and never looked at again. I guess what I'm referring to as a water test case is something that remains flexible. A step by step, procedural test case, if the product changes even slightly the test case will need to change or you'll need to throw it out.
|
| Either way, you either don't use it or you need to come back and rework on it. I'd much prefer what I refer to as a water test case which is potentially a test idea. It could be one line. It could be a paragraph depending on what suits your context. Something that is a prompter for the tester to actually engage their brain and learn about the product as they're testing. Instead of that, step by step, log in, expected results, et cetera et cetera, you could basically just have a test idea of test fee pay in the online banking system. You could add more to it if there's specific billing codes that you need to test or whatever it might be. You're leaving the test case wide open. You're leaving it to the tester to be flexible so that they're not blinded by the steps in a test case. So that they have the flexibility in sight and also in thinking as well.
| |
| Joe: | Awesome. It's a great point about flexibility. I think sometimes a lot of people have a misunderstanding of what a tester does and they think it's actually the opposite of flexible. They think it's someone that has a checklist and like nope you didn't follow this, this, and this. I'm a quality gate, you don't get through. It sounds like that's not what testing really is, in your experience.
|
| David: | I guess I've had the advantage, or it could be disadvantage. I see it as an advantage of having those years of experience with doing it in that quite traditional sense. Basically, seeing where the pit falls are. I talk about it in the book. Also, I'm currently reading a novel called The Invisible Gorilla. I'm sure most of the people that are going to be listening to your talk or the podcast would know about The Invisible Gorilla YouTube video. Basically, it's cops and flak. I think in recent times about how relevant it is. I find it extremely relevant. Inattention blindness, I think, is real. I've seen it before. I've seen testers skip straight past quite obvious bugs because they were so focused on the steps in a test case. That's basically … The mind can only focus on so much at a certain time. This has been proven in psychology research for years now. Giving that tester the flexibility and sight so that they can explore the software rather than be stuck on particular steps in a test case, I've found, personally in my experience, adds a lot more value.
|
| Joe: | Here's my zen question. You actually have a chapter on this. Why is why important?
|
| David: | What I might do, I'll actually refer to another piece in the book. Basically, I talk about an interview question that I used. Testing the light switch. I first heard this on another testing podcast actually. I think it was Eric Jacobson mentioned testing the light switch when he's interviewing candidates. Basically, I tried this very recently for a suite of candidates that I was interviewing. I think there was about twenty of them. When they went to … When they came and sat down in the room and we did the usual tell me about yourself type questions and I asked them to test the light switch. There's so many different places this sort of test can go. I guess what I was really wanting from every single person in there was the first question was why. That's all I really wanted to hear from them because after that I could take it wherever I wanted to take it. Unfortunately, there was only a couple that sort of led in that direction.
|
| I guess, for me, the importance of it is, testing is all about information. We need to gather information so that particular people, our stakeholders, whoever they may be can make a decision about whether we're ready to go live with whatever product it is that we're testing. Now, we can gather all sorts of information about a product. We all know about exhaustive testing, how it's not possible. We could test for years and years and years, collecting piles and piles and piles of information. We could do that and in the end find out that we still didn't get the type of information that our stakeholders need. Asking why first up, for me, helps me find out exactly what kind of information they're after so that we can get it quicker. Say I said to you, test the light switch. You said to me, why. I'll say, I just need to know whether the actual switch moves up and down. Straightaway, you stand up, you go test it, and it's done.
| |
| If you didn't do that, we could spend days and days and days of you trying to test the light switch and perhaps never actually getting me the piece of information I needed to have, which you could have gotten me in less than thirty seconds. That's why I prompt and tell all my new testers to always focus on why. Why are you testing something? What kind of information is required? Who requires it? How quickly do they require it?
| |
| Joe: | Awesome. I think this actually reminds me of a concept of abstract versus actually experimenting. I know like Greek philosophers were all into thinking about things, but they never actually experimented. That was the great seventeenth century revolution in science was people started experimenting. That's almost what it sounds like with ‘Why?' Rather than spend months conceiving what a perfect thing may be or a perfect test, actually try some things and experiment.
|
| David: | Yes, definitely. I guess that's another thing I've noticed too in my early career. Whenever I went to software testing training courses, it was all very much theoretical. Death by dot point in powerpoint presentations. We'd talk a lot, talk, talk talk. The instructor would also talk, talk, talk. What strikes me as funny now is looking back, not once was there ever a computer in the room. Never did we use a device. I was thinking now, how do you go to a software testing training course and not actually test anything. Even testing a piece of paper, we didn't do anything like that. In more recent times, the more courses I go to, now it's definitely more hands-on, experimental exercises. I think perhaps as an industry we're finally realizing that practical experience trumps the theoretical. Obviously, don't get me wrong. Theoretical is important. I think the practical is more important.
|
| Joe: | Awesome. I don't know if this is a martial arts concept, but I think of weakness as my biggest advantage. What I mean by that is, I'm really not that smart so I need to do things hands-on to learn. It's almost like my biggest weakness actually makes me better because I'm experimenting hands-on to learn something.
|
| David: | That's a good concept. I guess for me that's … In martial arts it's never been much of an issue for me because one thing I really enjoy doing in martial arts is doing a new technique. I guess … I think sparring, for me, is probably the most important part in martial arts because you're not focused so much on trying to get your jab in a perfect technique against a bag. Instead, you're trying to get your jab in a perfect technique against a moving target which is constantly changing height, shape, and how good they are as well.
|
| Once again, it comes back to that practicality of actually facing a real life situation. While I try and read a lot of software testing books and so on out there, what I try and do once I've read those books is to actually pick up on some of the techniques and actually take them to my work, or just practice them at home as well. When I'm faced in a situation in the future instead of thinking I've read that in a book somewhere, I wonder if that'll work, I'll have actually got some practical experience at that technique and I'll know better whether it will or it won't work for me.
| |
| Joe: | Just like you mentioned, in martial arts, you usually have an opponent. What do you think is a software tester's biggest opponent or challenge?
|
| David: | Wow, that's a very broad question. I'll have to say it depends on the context of course. I'll talk from my personal experience. I think the biggest challenge or the biggest opponent in my software testing is myself Joe, to be honest with you. It sort of reminds me of this whole testers must code debate, if I'll call it a debate. Now, I'll be the first to admit, I don't have a lot of coding experience. I've tried to learn. We've spoken briefly about my lack of automation. For me, the hardest part has been how to teach myself. Self-education, I guess, has been my biggest opponent. I think I've done a reasonable job. I spent the first eight years of my testing career not self-educating at all on software testing. I used to go to work, do my job, and go home. In more recent times, I've started picking up books, like I mentioned. I've started practicing, taking challenges from other software testers in the community. I think I'm doing quite well, but it's still …
|
| That self-education is still my biggest opponent. Probably the learning to code thing has been something that I've struggled with quite a lot over the years. I've started courses on code academy and I get to that certain point where I need to jump off the cliff, and I just don't do it. I find something else pops up in my life that's more important. I think in more recent times, I've come to a level of comfort in the fact that I'm never going to be a brilliant coder. I hope that if I'm faced with that real life situation, or that real legitimate problem that needs to be solved by coding, that I'll have enough energy to push myself in that direction and I'll be able to get myself through that problem.
| |
| Joe: | Awesome. I don't know if this is a martial arts concept, I think of it more as wrestling, when you have tag teams. I think of software teams or development teams the same way. You may have someone that's stronger than something than what you have and that's good. People have different skills. You don't want everyone to have the same skills. Your biggest weakness, you may have someone on your team that fills that weakness and you actually fill their weakness so it's almost like a team effort.
|
| David: | I completely agree. I think I've been pretty lucky in that respect. I guess I've done a lot of functional, GUI testing in the past where automation, while it was probably possible, was never going to provide us any quick wins. Functional, manual testing, if I can put it that way for the audience, was always something that I had to do instead. I've been lucky that I have been part of teams where the experience has been pretty diverse. If I do struggle with something, I can quite easily call on someone else.
|
| Something that I'll probably caution people on is don't always just hand off the task that you're not good at or that you find difficult. Perhaps, pair with the person who is better at something than you are. See if there is something that you can learn from them. Otherwise, you're just going to continue to not learn. Then, unfortunately, you might be faced with a situation one day where you don't have a team member that's experienced in that and you're going to get stuck. While it's good to have that diversity in a team, try and learn as much as possible from that diversity while you're a part of it.
| |
| Joe: | You mentioned it took you six years to get your black belt. You've obviously been training for a lot longer than that. Are there any books or resources that you'd recommend to a tester to help guide them to be a black belt software tester?
|
| David: | Black belt software tester. I think Jerry Wineberg, obviously, is a very prolific author in all of software development. Perfect Software and Other Illusions of Testing is an absolutely brilliant book. It's a light book. It's not long. It's content is absolutely outstanding. That helped me a lot. Obviously, I'd have to mention my favorite, the first software testing book I ever read, which was Lessons Learned in Software Testing. That was Bach, Pettichord, and Kaner. That really was the turning point in my software testing career. I'd spent, like I mentioned, eight years working in a very traditional, factory-style software testing organization. Once I'd read that book, the lessons in that book just said so much to me. It was like I was reading the last eight years of my life when I read that book. It prompted the change. It prompted me to want to get out there and experience different environments and different approaches, like I mentioned before. That's definitely a brilliant book, very much worth reading. More recently, I've been reading a lot more books on psychology as well. I've mentioned The Invisible Gorilla. I'm only halfway through that. I find that to be an absolutely brilliant book as well.
|
| Joe: | I just want to mention. In your book, software testing is a martial art. You actually list a bunch of different resources also that people can learn about. It's too bad you don't have the Amazon links in here, because I actually ordered on of your recommendations, Wineberg on Writing, which I never heard of before.
|
| David: | That was a massive inspiration for me. Obviously, not from a software testing point of view, but definitely from a writing point of view. The Feldstein method of writing that Jerry talks about in that book, I still follow today. It's helped me a lot. Hopefully, you enjoy that.
|
| Joe: | Okay, David. Before we go, is there one piece of actual advice you can give someone to improve their testing kung fu and let us know the best way to contact you.
|
| David: | What I would suggest, something that I think has helped me a lot in my software testing career, is perhaps don't focus just on software testing. Study and research psychology, human behavior, and in particular emotional intelligence. Software testing is a human activity. We're lucky, and I say we're lucky because this is part of software testing that I really enjoy, to deal with a great many stakeholders in what we do. We're not necessarily sitting in a corner, punching out code. We're not basically just off to one side where … We're the messengers. We're gathering the information. We're helping light the way of the project. In order to do that we need to deliver a lot of unfortunate bad information to stakeholders that sometimes think their products are absolutely brilliant, but perhaps they aren't so brilliant.
|
| The way that we deliver that information is so, so very important. We can't just hand over the bad news and say here you go, your product sucks. We actually need to be a little bit more intelligent than that. I think emotional intelligence and aspects of that help a great deal if we can pick up on how that information needs to be delivered in the best way not to offend anybody and to hopefully help us actually sell that information and get the changes in the product that we think should be in there to make the product better, to help the company make more money, or whatever it is that you're trying to achieve personally and also for your organization. Think outside software testing. Don't just focus purely on software testing. There's a lot of other industries and sciences and so on out there that we can study that will actually help us with our software testing.
| |
| For contact, @DMGreenlees on twitter. I have a couple of different websites. Dmg.name is probably the best one to go to because it links to my other websites and there's contact information on those websites as well.
|
Comments are closed.