Cameron: The title of your presentation is "Seven Keys to Navigating Your Agile Testing Transition," and I had spoken with Bob Galen a couple months ago. He's at STARCANADA now, and he actually mentioned that there are more than seven keys currently. But could you just briefly elaborate and kind of go over one of those keys?
Mary: Yeah, I mean, Bob started this presentation out when we left iContact. He started with seven and ended up with fourteen, I think. I think there's a lot of myths—you kind of go with the whole myth/fact about the transition. The biggest thing is, I think for me, around automations. Bob and I are looking at doing some stuff around kind of defining the agile testing framework. The biggest myth is that everything has to be automated from day one. It's not that it does, but what we talk about with the transition is you have to have a plan, and you have to have a road map, and you have to have an understanding of where you want to get to and doggedly work at that transition and that automation, whether it's for building the framework or figuring out what stores that you want to automate first and then getting people trained, whatever it is; coming up with a nice technical depth backlog around automation and then just start tackling it. A lot of times people are afraid to even go there. Their QA skill sets aren't where they need to be, or whatever, but at the end of the day you definitely have to have automation to go fast, and it's not an easy thing to do, but it's paramount to get where you want to be.
Cameron: The tutorial also says that after attending, delegates will have a better view of their team's strengths, weaknesses, and areas for improvement. What are some common strengths and weaknesses that are often misdiagnosed or overlooked?
Mary: What's interesting is when you transition from waterfall testing to agile testing, people often think the actual craft of software testing kind of goes out the door—that you don't need your standards and your templates, that you don't need your test plans anymore or you don't need to write test cases. It's like the whole lean, no-documentation thing. Well, that's actually a very big strength of the core QA that you are bringing along from waterfall to agile, and so the myth of "I'm going to go from documenting everything to documenting nothing" is really not true. You need to take the strengths of the QA that you have, which is the fundamental craft of the QA, and basically use those but in a lighter form. So I still have a QA standard operations procedure document in agile, but that is for "Hey, Mr. New Guy that just came in off the street, here is how you do your job, day one." Some people are like, "Wow, that's a big document. That's a waterfall document." Well, yeah, it is, but at the same point in time there's still got to be consistencies across QA on ten different Scrum teams, and that defines what the businesses of things are. Standards are very important in consistency.
A lot of times what's happening from a testing perspective and agile is it's always matrix, right? Some teams will have a QA—according to development—I feel like the people that care more about quality have people reporting to a matrix, a QA manager, or director, like I am, because of the craft of QA. I very much say we still have to do test cases. My minimum two standards are you still have to write test cases in agile, and you still have to write some type of a test plan. It doesn't have to be a big, forty-page dialogue you did in waterfall, but give me an Excel spreadsheet of the things and all the stores that you're going to test and ideas of how you're going to test it. So, you're still thinking about the plan of how you get all this work done. To promote straight myth and straight perspective: We still have the craft of QA; we still have the things from a software testing perspective that we didn't in waterfall that we still need to do going forward.
The weaknesses side is obviously a lot around the automation. While other QA engineers in the past decided they didn't want to be developers and that's why they went into testing, we have to upscale our QA engineers to have them be more technical. And there's a lot of tools coming out, from tools like SpecFlow and Cucumber, that will help the QA members on the team gradually move into the automation arena. At least have this happen in the test cases and then have somebody automate it, but once you get some of that framework in the learnings understood, then the actual automation cases, if they're somewhat willing, it's easy for them to learn. But you have to upscale; you have to take the time to train your QA people to get them to want to learn the automation piece of it. There will always be those QA that say, "Heck, no! I'm not going to automate," and that's OK. If they are subject matter experts, it's their main expertise—you still need those people to permit exploratory perspective. Exploratory testing doesn't go out; it's just a nice complement for the technical. We still have to have some of the team upscale to be more technical.
Cameron: So you talked about test automation there, but you also have a strong interest in agile testing methodologies. What about agile in particular is so appealing to you?
Mary: In waterfall days, QA was responsible for, Is it a process problem or is it a test problem? So do we dismiss it from a testing perspective, or is there a cross where the requirement's bad? To me, my job is in the same lens. So, is it an agile process problem, or is it a not-testing-the-right-thing problem? For me, I realized early on when I took my ScrumMaster's and I got into this—Scrum came out and I thought, "Oh, heck, there goes all the middle managers. Everybody is going to be self-empowered, self-organized as teams; my job's going away." And so I went and got my ScrumMaster's search and certification and thought, "This is great. I actually enjoy this. I actually enjoy ScrumMastering. This could be a second profession." But then I realized that people still have to do performance reviews. But then I started to more passionately learn the agile, Scrum, kanban, SP practices because I realized that this will help me figure out, Does my QA team have a process problem or do they have a test problem? Learning both sides has allowed me to build stronger agile teams. Most of the time I'm teaching this around agile coaching. When I was at Deutsche Bank I was major QA manager over at sixteen on six Scrum teams, and it was almost all process issues there, and that was the lens that they allowed me to have. That's the lens that I feel like here from an agile perspective, as well as at ChannelAdvisor, where, Did I come into a place that has process problems or quality problems? That's why I've gotten passionate about it—it helps me do my job better.
Cameron: What advice would you give to new adopters of Scrum and agile?
Mary: You know, it's a team sport. That's another reason I got into agile. I played college basketball, and I loved working in teams. It's a team sport, so if you have a bunch of track runners as your employees, then you might want to think about this before you do it, because you need a team of football players, or basketball players, or people that want to work on teams. There are some people that kind of really just don't want to work on teams. So, you have to have people that have a good attitude, good aptitude, and can communicate well, and want to build a good team and want to work on that team. That's always my advice: When you cut over to this transition, you want to make sure you have the personnel to do it, and if you don't, you have to be OK with people voting that person off the island, is what I say. You know, one bad egg will kill a Scrum team, and so you have to figure out a way to get the right attitudes, the aptitudes, the people that have the right communication—people that want to work together on those teams.
Cameron: You have a teammate in presenting your presentation in Bob Galen. What's it like working with Bob?
Mary: Bob's amazing. He is an awesome mentor. He's wanted to do this. He's constantly pushing me to make myself better, and he's just got a lot of great experience in this business. I really hope people will come out and listen—listen to what Bob has to say and read some of the books that he's written, which are also very enlightening. Think about what the message is that he's trying to give out, because at the end of the day he talks a lot about culture and making things, empowering people and being a servant leader, and that's kind of the person he is. That's the way he managed me when I worked with him at iContact, and he's just overall a great communicator, too, so you can actually understand what he's trying to convey. I really ask people to come and listen because he's really a great communicator about agile testing and agile in general.
Cameron: Now, is there anything else you'd like to say to the attendees of STAREAST before they attend the conference and before they attend your presentation?
Mary: Just come with an open mind. I think a lot of people come to these things with some preconceived notions of things, so come with an open mind and listen to what you have to hear. Challenge us. I mean, my favorite thing is when people go to conferences and say, "What you said won't work and here's why," and I'm like, "Yeah, I can see your opinion." It also helps me and us get better. Come with an open mind—please collaborate with us. Don't be the guy in the back of the classroom that doesn't say anything, and you'll get a lot better of an experience out of it.
Cameron: And like you said, "It only takes one bad egg to ruin the bunch."
Mary: That's right.
Cameron: All right. Once again, this is Mary Thorn. She will be speaking at STAREAST 2014, which is May 4 through May 9. She's speaking a presentation called "Seven Keys to Navigating Your Agile Testing Transition." Thank you so much, Mary.
Mary: Thanks, Cameron. Bye.
Mary Thorn is a director of QA at ChannelAdvisor in Morrisville, North Carolina. She has a broad testing background that spans automation, data warehouses, and web-based systems in a wide variety of technologies and testing techniques. During her more than fifteen years of experience in health care, HR, agriculture, and SaaS-based products, Mary has held manager and contributor-level positions in software development organizations. She has a strong interest in agile testing methodologies and direct experience leading agile teams through Scrum adoption and beyond.