Who’s Michael Larsen? Who’s Michael Larsen?
Really? You need to get out more!
He’s the lead tester at Sidereel. Michael Larsen has been testing software in Silicon Valley since Heavy Metal Bands had big hair. A former musician (one of those big hairs, was, well… him), Michael started testing at Cisco around the time they went public, and has the stock options to prove it.
He’s been testing ever since, but that’s not all. The show producer for This Week in Software Testing, Michael is also the lead organizer for Weekend Testers Americas, a recognized blogger at Testhead.com, a black-belt in the Miagi-Do School of Software Testing, a member of the board of directors for the Association for Software Testing, and a lead instructor in its Black-Box Software Testing program, Michael is quickly becoming one of the most recognized names in software quality.
Michael Larsen will answer your questions.
Question: Assessing the performance of software testers is known to be difficult. As a coach (or leader?), how do you assess your own skills, peQuestion On a related note – Do you coach the devs in testing? Do you teach them how to do exploratory testing or teach them how to write better tests for their code? – Phil Kirkham, Atomic Object, Bracknell, United Kingdom andGrandRapids, USA
Michael I always start (or try to start) from the idea that someone I am coaching could teach me something new. We can easily come to the conclusion that our ideas are the best because, well, they are ours and we’ve been at this for (fill in the blank) years. However, there’s a real opportunity to see testing from a different perspective, especially when we are working with someone we have never worked with before. Sure, I can teach principles that others may not know, but when I have a tester look at something and ask a question that I wouldn’t have thought to ask, that makes me stand up and consider new avenues. I also try my best to be aware of where a tester is coming from, or where they have been in their careers, and to leverage the skills they have learned in other endeavors. Customer service representatives, as an example, are often gifted with the talent of being able to talk people off of ledges, and to calm down very irate customers. They also learn to take the measure of a situation quickly, and can focus on the pain points customers face. In short, we don’t know everything, and there’s a lot we can learn from a lot of different people.
Question: What do you do when you have no one else to support your idea and are forced to follow a process just because “it has been working well” or “it if ain’t broke, don’t fix it”? – Ajay Balamurugadas, Bengaluru, India
Michael: I’m not a fan of “follow a process just because it’s always been done this way”, and I frequently will ask “why are we doing things in this manner? How did we get here?” There may be very good reasons as to why the organization in question tests in a particular way. I also try to see if I can take an area and ask them to “give me the benefit of the doubt” for a little while. This way, I can show them some of the ways that I would prefer to test, and compare them to their processes and approaches. This way, I get a chance to have the organization consider my ideas and see if they could be swayed to try something different. I’ve also found that making small, incremental changes over time are easier to sell than to try to rip everything out by the roots and start with something totally different. I should also say that I have seen the more rigid and dogmatic attitudes with larger companies. Smaller organizations have been more willing to experiment and try different approaches.
Question: Is the leg all healed up? If so, are you still skateboarding? More seriously, you do so much for the testing community. What motivates you to do so much writing, interviewing, and contributing to conferences and webcasts? How do you find the time to do these things?
Michael: The leg is getting better, thanks for asking. For those curious, back in August of 2011 I broke through my right tibia near the ankle and my right fibula near the knee. It was the result of a skateboarding accident coming home from work on my skateboard. It’s been ten months and I have most of the range of motion back, though I have some work to do to get back to full flexibility. I’m also dealing with some numbness along where the plate was put in, but otherwise, it’s progressing nicely. I have hopped on the board a couple of times to push around and work through range of motion, but I have promised my wife that I would not do any more “street skating”. If I skate now, it’s in more controlled environments such as a skate park or open area. As far as writing and presenting, I think it’s a way to challenge my own ideas and see what new aspects I can learn. My blog was the first approach to this, and I discovered that, when you put your ideas out there, you can get some great feedback and consider ideas you might not have considered before. I find that exciting, and I enjoy the interaction with other people that helps make it possible. That, and frankly, I find writing and presenting to be fun. In a way, it gives me a chance to be creative and to help keep alive a lot of the skills I learned as a musical performer. As to finding the time, when you are having fun with something, it’s not difficult to find the time to make it happen. When it isn’t fun, then it can be a much bigger challenge. I decided that, if I get to the point where doing the writing and presenting becomes a drag, I’d step back from doing it. So far, thankfully, that hasn’t happened.
Question: As a lone tester you might have to do security, performance, usability as well as ‘normal’ functional testing – do you worry about being a jack of all trades but master of none? – Phil Kirkham, Atomic Object, Bracknell, United Kingdom and GrandRapids, USA
Michael: I worry about that a great deal. It means that I can’t really be a specialist, but that I have to address the needs at any given time. Because of that, I do feel like I have a lake’s worth of knowledge, but that it only goes about a foot deep in most places. That puts the pressure on me to do what I can to keep up to date on different disciplines and try my best to do a bit of each of the testing disciplines over the course of a project. It also means I have to agree to let others handle some of the testing details I just won’t be able to do or don’t have the resources to do. At Sidereel, that means that our Product Manager helps me with a lot of the Acceptance Test confirmation. I go through and explore areas, confirm a variety of issues, and advocate for issues to be fixed, but she also does a fair amount of testing so that we can accept the stories.
Question: On a related note – Do you coach the devs in testing? Do you teach them how to do exploratory testing or teach them how to write better tests for their code? – Phil Kirkham, Atomic Object, Bracknell, United Kingdom and GrandRapids, USA
Michael: I have had this opportunity, and it’s been fun to see some developer’s reactions. I remember one time a couple of years back when I was finding a lot of bugs for a particular release, and the developer came in and asked me where in the world I was finding these issues? I told him that I remembered reading James Whittaker’s book “How to Break Software.” The first “attack” mentioned in the book was to go through the code, look for every error statement, and do whatever it took to make those errors appear at least once. In this instance, it proved to be a gold mine of issues just waiting to be discovered. A couple of years after this, I got an email from this developer. He had started a new job, and he said that he remembered my “see every error once” attack and used it to refactor code he was working on, and sure enough, it turned out to be a gold mine of issues for him as well. He thanked me for introducing that approach to him. There have been other times, but that’s one of the most memorable.
Question: When dealing with the creation of test scripts, it’s no doubt that the best testers will be the ones who have a thorough understanding of the underlying code base. With that in mind, how much of the tests should be handled by the test engineers and how much should be handled by the developers themselves?
Michael: If you are working in an environment that is heavily focused on Test Driven Development, there is a lot of scripted “checking” already happening. While this is certainly helpful, it is only as good as the assumptions that the developers make when they design the code. They can be very good tests, but they may have a limitation as to what they actually cover. We as testers need to see if we can go beyond what the developers are doing, or at least try to approach our tests from a different angle. I like to use tools like the Heuristic Test Strategy Mode or Elizabeth Hendrickson’s Test Heuristic Cheat Sheet. I actually have a coffee mug that Elizabeth gave me that has all of these cheat ideas printed across it. It stands as a reminder every day that there’s some angle I may not be thinking of. These questions can help testers develop solid ideas even when they don’t have access to the underlying code. If we do have access, so much the better.
Question: What has changed in the past few years in how you do things and where do you think the winds of change are blowing? – Keith Hinkle, Grand Rapids, Michigan, USA
Michael: Working with an Agile team has been the biggest change for me. Up until 2011, I had been involved with primarily traditional test approaches. The products I had been working on depended on “shrink wrapped” media and usually had long release cycles (sometimes stretching into years between releases). Working with an environment that “ships” its code weekly, or more, is a big change. Additionally, getting the chance to focus on my own automation project has been a great (albeit frustrating at times) experience. As to what I think the future holds, I think we are going to see the traditional “guardian of quality” attitudes about testers (both within our ranks and externally) change. I think that we have a real opportunity to share the benefits of contextdriven testing and exploratory testing. To do that, we need to be more direct and demonstrate what those approaches offer in concrete ways. Testing on different platforms has become more prevalent. Mobile is especially challenging the way that software is being tested. Everyone has to adapt and learn several new tricks. I also see a real partnership developing between testers and developers where there is more of a blurring the edges of what we respectively do. Personally, I think that is exciting.
Question: As the lone tester on a test team how do you manage your immediate boss/ line manager who is most likely not a tester, has never been a tester, and if you are unlucky does not believe testing adds sufficient value to be recognized as an individual discipline? – Stephen Janaway, Fleet, Hampshire, United Kingdom
Michael: The best recommendation I can make is to take the time to show that you are finding things and are informing the development team of the state of their applications. I use the metaphor of being a “beat reporter” a lot, but I think it’s an apt one because it describes our job in the best way. For too long we have sold the notion of testing as though we are some super strong sentry guard with a big shield and that somehow we are going to stop all bugs that come our way. First, it’s unrealistic, because there are situations that our testing will never be able to replicate, or it will be in a state that we didn’t consider to test, and thus our credibility as a shield goes way down. Second, I think it’s important to show the development team and our managers that we are offering them a service, and that service is to provide them with the best information possible to make decisions. I believe if we frame it in that manner, and we are up front and honest with our abilities as well as our limitations, we stand a much better chance at forging understanding with our managers, even if they don’t understand the nuances of testing. While we provide that information, it would also be wise to take a little time to demonstrate and explain our testing processes. Better yet, try to encourage your manager to sit in with you for a brief pairing session, and let them test for a bit with you. Often, when we show people what we do and lift the veil just a little bit, they can see that what we are doing does require thought, energy and persistence, and they might even develop a better appreciation for it.
Question: How does one stay motivated as the only tester in the team? What drives you and how do you cope without another tester to bounce ideas off? – Stephen Janaway, Fleet, Hampshire, United Kingdom
Michael: Honestly, it isn’t easy, and there are times when I have to say that I fight through feelings of “indifference”. The biggest danger in this is that I don’t have anyone who can point out when I’m going into that mode. When someone does notice, it’s usually someone in an executive position, and then it’s a real problem. To keep motivated, I have to know that I can either step out of a role I am in or get away from what I’m doing for a time. To explore another avenue or do something totally different for a bit helps. In some ways, having a chance to work with an automation framework helps me to get out of the zone when I’m burnt on testing, and when I get a little burnt on automation, that’s a good time to shift gears and go exploring again. Having a variety of books to thumb through helps, as does sharing ideas with other testers in whatever capacity I can. Weekend Testing actually fills a big void here; it’s great to get a chance to get together with other testers and sometimes try out ideas that I’d otherwise be poking at on my own. Between Weekend Testing sessions, I read a number of blogs that cover a variety of topics, and I get into the mix with other testers on Twitter and debate topics when they come up. Still, the point is that, without another tester on the team, I have to reach for inspiration outside of the team. I’m OK with that.
Question: You do weekend testers, you are on the board of the Association for Software Testing, you speak, you write, and you have a full-time job as a tester. How do you balance all these things with your family and personal life? – Anna Royzman, Quality Manager, Liquidnet, New York City
Michael: I ask myself the same question. Depending on when you talk to me, my answers may vary from “very well” to “not so great”. I do confess that I have a tendency to get “over involved” in a variety of things. It’s just part of my nature, I don’t really “dabble” in things. I’m either all in or I’m not involved. There are some things that I do that help me manage what I do. It may sound corny, but I believe strongly in the idea of knowing how to optimize your energy rhythms. Bear with me here. I’ve found that my brain engages in an optimal manner at different times of the day, so if I want to leverage that opportunity, I try my best to schedule around their ups and downs. I do a lot of my writing and hard problem solving early in the morning. I don’t do it every morning, but about three times a week, I get up as early as I reasonably can when I want to read up on something or practice some new techniques or write a paper proposal. It also has the benefit that everyone else in the house is still asleep. Having said all that, I do recognize the signs of burn-out, and I give myself “mini vacations” every few weeks. Sometimes you just want to sit down with the kids and watch movies or go find a new restaurant that they might like, or just take a “get up and go” day in the car with the whole family and leave everything else behind. As I’m writing this, I’m getting ready to head off for several days with my son and our Scout Troop for Summer Camping in the mountains of Northern California. I’m greatly looking forward to being “off the grid” for awhile.
About the Author
Matt Heusser A consulting software tester and software process naturalist, Matt has spent the past 12 years or so developing, testing, and leading in dev/testing of computer software. Beyond the work itself, Matt has had notable roles as a part-time instructor in Information Systems at Calvin College, a contributing editor to Software Test & Performance Magazine, the lead organizer for the 2008 Workshop On Technical Debt, and most recently as Senior Editor for the “How To Reduce The Cost Of Software Testing” book project.