The Testing Show: Building Great Testing Teams
As the software delivery process matures and grows, a variety of teams are forming and becoming part of the everyday testing landscape. These teams may or may not resemble anything that many testers are familiar with.
New roles and responsibilities are coming into play, with many software testers taking on roles such as Scrum-master, Release Manager, Product Owner and other positions that would have been seen as out of the ordinary for testers a decade or so ago.
The role are blending, the responsibilities are blending, so how does a tester determine what the best course of action is and how to participate in this brave new world? Perze Ababa, Paul Grizzaffi, Matthew Heusser, Michael Larsen, Gerie Owen and Peter Varhol all gather together to consider what makes for good testing teams and good teams in general.
- “Peopleware” by Tom DeMarco and Timothy Lister
- Manifesto for Agile Software Development
- Carina Zona: Consequences of an Insightful Algorithm
- Gerald M. Weinberg, An Introduction to General Systems Thinking
- Theory of constraints
- ConTest NYC
- Responsible Automation
- SEETEST 2018
- STARWEST Software Testing Conference
- QA&TEST | Testing Conference
- Agile + DevOps East
- EuroSTAR Conferences
- How Did I Miss That Bug: Overcome Cognitive Bias in Testing
MICHAEL LARSEN: Hello and welcome to the Testing Show, Episode… 60 .
[Begin Intro Music]
This show is sponsored by QualiTest. QualiTest Software Testing and Business Assurance solutions offer an alternative by leveraging deep technology, business and industry-specific understanding to deliver solutions that align with client’s business context. Clients also comment that QualiTest’s solutions have increased their trust in the software they release. Please visit QualiTestGroup.com to test beyond the obvious!
MICHAEL LARSEN:Hello and welcome to The Testing Show. It is September. It’s almost to Fall, so for those looking to beat the heat, it might be around the corner. Thanks for joining us today, we’d like to welcome the guests who have joined us. Peter Varhol?
PETER VARHOL: Good morning, folks. Good morning, Michael.
MICHAEL LARSEN:Perze Ababa?
PERZE ABABA:Good morning, everyone.
MICHAEL LARSEN: I’d like to welcome back, once again, it’s been awhile, Mr. Paul Grizzaffii?
PAUL GRIZZAFFI: Yes, it has been awhile but I’m glad to be back. Thank you.
MICHAEL LARSEN: Welcome back a new regular, Ms. Gerie Owen?
GERIE OWEN: Hello. Glad to be here.
MICHAEL LARSEN: I’m Michael Larsen. I am your show producer, editor, guy behind the scenes who cracks the whip, so to speak but let’s go ahead and turn it over to our Master of Ceremonies, Mr. Matt Heusser… who can introduce himself.
MATTHEW HEUSSER: Thanks, Michael. Hi, everybody, I’m Matt. This week, we want to talk about something a little bit different that I think is important and that’s building great teams. One of the trends that I have seen is that the testers are blurring into the teams. We used to have a separate distinct Director of Test and we had test managers. Now testers are just contributing team members. The role is completely blurred. So in that world, how do you build an effective team and what does an effective tram need? I think that’s the theme for today. Before we dive in I wanted to do something different. Instead of a news items I wanted to recommend a book that is timeless, that made a huge impact on me and that’s “Peopleware” by Dimarco and Lister. So I’ll give one example from the book that I really, really like. A lot of people say Weinberg & Lister is dated. There’s a little bit of truth in that, I mean, in Peopleware, they’re talking about the interruption of the ringing phone. The physical phone on your desk. Now we have cell phones and Slack and Skype and IM and Gmail and GTalk. I would argue that either we are going to do the spade work and read the old literature about software development or we are going to continue to reinvent it ourselves. So my favorite chapter here I want to tell you about and then we’ll get to the main topic, they call “The Gelled Team”. The manager has a dinner party. Everybody comes and they are all talking, for maybe an hour. The manager says “oops, I forgot to get the food.” The team has to figure out what they’re going to cook. The team has to go to the grocery store. One person volunteers to make the salad. Someone else is going to make spaghetti. Someone else is going to make the sauce. Someone else is going to get the breadsticks. It all just sort of magically comes together at the end. At the end of that, they are more of a team than when they started. I thought it was a beautiful illustration. The other one I really like is “The Sick Team Member” who comes in to finish the demo for the prototype for the customer. The manager goes to the store and buys some chicken soup. He says “With all your busy management stuff, how did you find the time to do this? You’ve got management stuff to do?” She says, “This is management.” Both of those stories really hit me. So much that, when the Agile Manifesto came out I thought, “wow, one body read “Peopleware”. That’s pretty cool.” This book is 25-30 years old now, it’s amazing. So that’s my contribution, sort of, to teaming and teams. I should probably talk about yours. Gerie, do you want to get us started? Is teaming important and how do you build an effective team for testing roles and activities?
GERIE OWEN: Sure. Building your team is critical, because if you don’t have that solid bae, if you don’t have that mix of skills, the mix of personalities, your team’s going to fail. I think that you need to focus on not only the skill sets but the personalities to make sure that the people not only work together but are able to challenge each other.
PETER VARHOL: And Gerie, to add to that, you’re not just talking technical skills, you’re talking people skills also. You’re talking interactive skills. You’re talking, I’d say, “softer skills”.
GERIE OWEN: Absolutely. Especially with the test teams now. It’s the whole team and Matt mentioned this. It’s all changing. We’re becoming part of the bigger team. We’re becoming part of the DevOps teams, part of the Scrum teams, the Agile teams. We as testers are the champions of quality and communication is probably one of the most important skills that our testers have.
PETER VARHOL: Yet its something that we have to communicate and share with the rest of the team members also, correct?
GERIE OWEN: Absolutely.
PETER VARHOL: I look at this myself in two ways, Gerie. I look at this as a “getting the right technical skills for a particular team and making those skills work together. I’m not so sure that a team that onset have the personalities, that doesn’t mesh correctly. I’m not sure that they are going to fail, but they’re certainly not going to be a high performing team. How do we get the most out of those skills and interactions so that, at the end of this they can lock at each other and say, “wow, I don’t think any single one of us was capable of that.” I think that, however, as a team we came together and did more than we could do as individuals.
PERZE ABABA: You know, I think one of the most challenging things when we look for a member of any given team is finding someone who really has the passion for the things that they are trying to do, because skills we can teach. Things that they can learn on the job or at least get them to a point where they can be valuable to the team. Having that passion as compared to another tam member that just shows up for the job, it’s a complete different dichotomy around how a given team member is going to perform over time. The challenge then is “How to we as hiring managers interview for that behavior in the short amount of time that we have?” Especially with the turnover in skill and talent nowadays, it’s really pretty high.
PETER VARHOL: So Perze, how do you think that you identify passion as a part of, I’ll say an interview process or a part of selecting someone as a member of your team?
PERZE ABABA: It’s a question that I’m continuously asking myself. I interviewed this one guy pretty recently and in the course of the conversation what really came out was “I’ll pretty much do what the team needs. I actually have the mental capabilities to be able to learn what needs to be done and do it in that amount of time. It’s very rare to find candidates like that who could say “I f you need me to test, I’ll test. If you need me to perform coder reviews, I’ll perform code reviews, because I do have the necessary skills for that.
PETER VARHOL: OK, I’d like to also point out another, not necessarily an individual skill as part of teams, and I know this word gets overused somewhat these days but I think a team needs to be diverse. Diverse in terms of gender, of background, of race, of creed, or whatever it might be, because if you get everybody who’s the same.If you’re like just everybody else on your team, you’re not a software team, you’re a boys club. So instead of having that sort of club type atmosphere where you’re building software for people that are just like you, you need to understand who your audience is, who your intended user is, and you need a team make up that is representative of your user community.
PAUL GRIZZAFFI: I agree, especially with some of the reading I’ve been doing and some of the people I’ve been associating with lately. And then some of the other things that we start seeing in the technical articles, particularly around AI, where the AI’ aren’t recognizing all of the individuals as you would expect because the people that programmed and test it weren’t diverse enough to have the knowledge to say, “hey, what if a person is of this particular demographic vs this other demographic. How is this system going to respond? Is it going to respond at all? I think that is actually going to help us understand more concretely that we need these kind of multi dimensional cross pointed teams.
MICHAEL LARSEN: Yeah, definitely, let me put in my plug at this point in time to say for anyone who hasn’t seen it. I know I’ve talked about this multiple times over the life of this podcast but its still one of my favorite talks and that’s Carina C Zona’s [mkl: “Consequences of an Insightful Algorithm”] “The dangers of a well intentioned algorithm”. It’s a great talk and it definitely deals with theft that when you have teams that don’t understand what other people are working with or what they’re reality is, they just never thought to even think about it, you get certain situations that just don’t work very well.
MATTHEW HEUSSER: I think that’s manifested a couple of different ways. I think there was a Facial recognition software that worked great for White, Anglo-Saxon Protestant types and fell all over anybody that was Asian, Native American, African American, that sort of thing. I wanted to go back for a minute to something the Perze said, which is right out of Peopleware, which, in that book, they say that people’s personalities are established but the time they are early adults. So when you hire and you say, “oh, this person has this great technical skill, they’re just a little rough around the edges, they’re not really a team player”, it will be extremely hard to help them. That’s just a claim in the book. The conclusion is, the success or failure of the project is usually marked the day the project begins by the quality of the people. Which makes getting the right people on the bus extremely important. The right people will become a team and there are some other situational factors. You can set people up to compete and you can destroy good natured human… genuine competition, like cut throat information hiding. I’ve seen it happen. You could emphasize for instance the testers are against the developers, even though we’re supposed to be a product team, we’re still on the test team and we report to the test manager and we emphasize that. There success is not necessarily ours. Those are two ways to screw that up.
PAUL GRIZZAFFI: So, Matt, yes and no on smoothing out the rough edges. I would say on average that’s probably right but I think the people that really buy in and really understand that, “hey, if you want to excel at this particular career, you’re going to have to make some changes in your approach and things like that. I’m certainly a case of that. I still have my rough edges and I tend to enjoy some of them at certain times. I’ve learned when it is appropriate to have them and when it is not. I think that has made me able to do the consulting job that I am in now, is that I can kind of understand when I ned to put the circus back in the box and when I need to let certain of the animals out.
MATTHEW HEUSSER: Yeah, I think you hav to think of that from a project perspective. Twenty-two year old Matt had not developed certain skills and he wasn’t going to get them in the next six months if you put him on a project. Whereas, if you took a lot at long term career Matt, with time and enough coaching, I’m a different person that I was when I was twenty. I would interpret that with a short term perspective. Not a long term. Know what I mean?
PAUL GRIZZAFFI: Absolutely, if we are looking at a short term perspective I’m totally on board with that.
PETER VARHOL: So, Paul, from what you’ve just been describing, and I’d like to throw this out not just to you but to everyone… all of us have either been a part of or have built some great teams. I think all of us have been on some not so great teams. Is there any one characteristic that you think separates a great team from one that is not necessarily a high performing team?
GERIE OWEN: I think the high performing team is going to be the team that is willing to motivate each other. When you have a lot of contributors that see the bigger picture rather than seeing their individual piece, when they understand what the business goal is, they will work together toward one goal rather than toward their individual goals.
PAUL GRIZZAFFI: I tend to agree. Having a common thing to achieve or a common hurdle to overcome, if you have the common hurdle and the ability to compromise and do things that are appropriate, I think those are the teams that are going to ind up being more high performing but not to the exclusion of having the right skills to actually accomplish it as well. You can have a team of people who absolutely are on the same page toe deliver building a website but if they don’t know how to code, obviously they are going to struggle and may not make that business goal.
GERIE OWEN: That’s why I think that you need to make sure you have not only the right personalities but also the right skill set…
PAUL GRIZZAFFI: Absolutely.
GERIE OWEN: The complimentary skillsets in a team to succeed.
PAUL GRIZZAFFI: And I think that’s the key word there: “complimentary”. If you have a bunch of people that can all do the same thing that’s great, but when you need to do something different, you’re kind of screwed.
MICHAEL LARSEN: We definitely run into that. In an almost thirty year career I’ve had exactly one super behemoth company that I worked for where I had a lot of testers that I was on a team with. Since that time I’ve mostly worked with much smaller teams, maybe had a couple of testers or even just me being the tester. It actually has been better where I’ve had smaller teams but not where it’s all just on my shoulders. Right now the test team that I work with has three testers and a test manager. In addition to that we have different jobs as well. I’m the Release Manager. I’m also the Scrum Master. Other members of our team do different things as well. Nobody on our team is just a software tester, in the sense that, “I just test. That’s all that I do”, and I think that’s helped us. Instead of us just saying “Ive got my little box”, we have to deal with broader realities. With that model, with being able to have that broader view and with our hands in more things, our testing is actually more respected than it would be when it was just, “we have a group of testers and the only thing they are doing is testing the software”. Because we’ve had to branch out and do more things, it has allowed us to be more focused on the quality of software do deliver but also realize that everybody’s involved with it and we’re less afraid of stepping on people’s toes. As Scrum Master, it’s my job to step on toes [laughter].
GERIE OWEN: I think that’s a really good point because I think for the future of testing, nobody’s going to be just a tester. You’re going to need to be involved in release management, scrum leader, even developer, security, and I think that the sooner testers accept that they need to broaden their horizons, the more successful they are going to be.
PETER VARHOL: Michael, you seem to have alluded to this but how important is it to get that stakeholder buy-in? People who are not necessarily core members of the team but have either a stake in the process or the end result? How important to bring together that larger team, under the big tent, so to speak?
MICHAEL LARSEN: Interesting you should mention that. We’re going through a transition in that regard right now. The company that I work for, Socialtext, is owned by another company called PeopleFluent and PeopleFluent recently got acquired by a company in the UK called LTG. In the process of doing that a lot of things have been changing. Things that we used to do one way that we used to feel really comfortable about, we’ve now had to to a more intense buy in process. We’ve shifted over to doing two week sprints. It’s given us a chance to… I guess the way that I would say this is that a lot of stuff that would reconsidered “gold cladding” before, we’ve had to step back and go “yeah, that’s great. Is it really helping us get th where we need to be?” We’ve ha d to actually modify this to more of a “what does our product owner and what do the stakeholders really need? How are we actually addressing that?” So the conversations have definitely changed. We’ve definitely gotten into a better rhythm of how to do that. What was really interesting was our product owner would come in and say “you know, you don’t have very many sev2 bugs in here, whereas compared to other teams they have many more.” The first thought was “Really? That’s a problem?” I was confused about it at first but I understood over time what they meant to say. To be able to deliver, to iterate effectively, sometimes you have to be willing to say “yes, we found issues and yes, some of them might even be somewhat serious but for us to actually make progress and to hit our goal, we have to accept the fact that we have those, we know about them, they’ve been reported, we’re going to have to prioritize them and we’re going to hav to take care of them but for the immediate moment, we need to keep moving”. Whereas before, with a one piece flow process, if we found a problem, everything stopped, we fixed it and then we got it back on, which meant we had great product but it took forever to get it out the door.
PETER VARHOL: OK, Matt, I know you’ve built a number of teams for a wide variety of purposes. If you could pick one characteristic of why you select somebody or how you put together that team that made them successful, what might that be?
MATTHEW HEUSSER: The point on diversity is important because you don’t want to have a monoculture, so I don’t want to say “everyone needs to be this way”. There’s a trait called agreeability and being disagreeable does not make you a bad person. You could be an excellent trial lawyer and love to fight and be very good at your job and lead an excellent legal team and be a disagreeable person. When you get too many disagreeable people in one room, you can’t get anything done. This is especially important in software testing. Michael and I have both been on the Board of Directors for the Association for Software Testing. The people the get elected to the board are the best known if not some of the best critical thinkers. Professional people that stand up and say “that’s never going to work”. But if they are agreeable, you can have the debate and then you can put your ego aside and say “this is where the majority of the team wants to go, I’m going to support it”. If it’s disagreeable to an extreme, they’ll just say, “You’re an idiot. You’re wrong.” They’ll disagree and, maybe, they’ll take the argument out in public. That’s just not particularly helpful. So I want to have a nix of people, but I would say you’ve got to be able to say, “OK, the decision has been made. I’m going to support it”, and preferably keep the argument in private if they can. I’ve been guilty of a little bit of the “you won’t believe what Sally said” kind of behavior over the years. It’s when they really make a campaign of it and try to take it in public and make a big deal of it and they’re still trying to influence the outcome. Even if they say “this is the reason why I had to leave the company”, thats one thing but if they’re still trying to influence the outcome when the decision has already been made, all that does is slow down progress.
PETER VARHOL: I think we refer to that as “backbiting”.
MATTHEW HEUSSER: Really long answer to a simple question.
PAUL GRIZZAFFI: I agree and I think that’s the core of what I said. When you’ve got the diverse team but willing to compromise for the good of the team, for the good of the product, and for the good of the organization, I’m totally on board, there, Matt.
GERIE OWEN: I tend to agree, I think that…
MATTHEW HEUSSER: You’re so wrong, Paul. Paul, you’re wrong.
PETER VARHOL: [laughter]
PAUL GRIZZAFFI: Oh, I know. I’m told that constantly.
MICHAEL LARSEN: [laughter]
PETER VARHOL: Matt’s just trying to be agreeable… but you know something, Matt? The majority of us believe that Pauls is right on with what he is saying. How do you feel about that?
MATTHEW HEUSSER: I guess I can support it.
MICHAEL LARSEN: [laughter]
MATTHEW HEUSSER: I think we’ve taken this as far as we can go I think.
PETER VARHOL: [laughter]
MICHAEL LARSEN: [laughter]
PAUL GRIZZAFFI: [laughter]
GERIE OWEN: You know, a team can have a great group of people who are agreeable, who have the right skill set, who have the right complimentary skills, but if they don’t have the proper leadership, these teams are going to run into trouble because they need to be represented. They need somebody that will go to bat for them. That’s critical to a team’s success.
PETER VARHOL: How important do you think it is for a team leader to go to bat for the team?
PERZE ABABA: I had this manager who always makes it a habit to give little rewards here and there to the team that we had and you realize that team that we had at that time was really good at what we were because he enables those things. So you have a manager, itself, that makes sure that there is a ground that you can stand on, that you can walk on. This may be true for a lot of traditional teams. Once you switch into a different type of team structure like Agile or a different type of methodology, that knits the whole team that goes to bat for each other. The whole point is, you know that someone has your back, whether that person is a test lead or the Scrum master or a person within the team, because if you know that if you are allowed to fail and learn from that failure, then your team as a whole has the ability to develop great habits so that you can deliver effectively without having that fear of failure.
PETER VARHOL: How important is it to be an advocate of your team to senior management? Not only to defend the team but also just to promote what the team is doing to help senior management try to understand how the team is contributing to the business goals?
GERIE OWEN: Oh I think that’s so important, especially when you get into distributed teams. Your offshore teams. Your offsite teams. They are out of sight and out of mind. It’s the team lead’s responsibility to make sure that they are heard, that they are counted and that their accomplishment are recognized.
PAUL GRIZZAFFI: I agree.
PETER VARHOL: So yow do you do that, Gerie?
GERIE OWEN: Some of the best ways is to get good communication equipment. Sometimes it’s very difficult to hear people offshore when they are speaking. Bringing them into the conversations, sending emails touting your team’s accomplishments.
PAUL GRIZZAFFI: I agree. It’s absolutely critical, especially because eventually, there’s going to be the dreaded time of the year or semi-yearly evaluations, where you hav to put your accomplishments down. Your manager’s probably going to have to defend you or promote you… not promote as in a higher level but promote you to the rest of the management team and explain as to why you should have this particular ranking, why you should be eligible for this percentage of raise. The manager, the leader needs to be able to manage up and express out all those types of information. Another thing that I think is critical is corporate support, specifically from the talent acquisition team. If The recruiting, onboarding and interviewing process at the corporate level is not supportive of you bringing in the types of individuals that you need, you are going to fail building that team. Even if you wind up doing the legwork yourself… I’ve been in organizations like this where we’ve worked with the talent acquisition team in a very healthy way and at other times it’s been a very adversarial way anti was very difficult to get positions filled with appropriate people like that.
MATTHEW HEUSSER: I was going to comment on this idea that you needa manager that protects their people, which I think is often true in, at least Corporate America if not most developed nations. There are exceptions. If you have a very laissez faire company, that is, “We don’t care what you do, as long as we get these metrics back”, which could be sales numbers if you work at Amazon, it could be page views, whatever your goal is. Then you can have sort of an emerging leader happen, where they are not blessed and they do not have a titlle. They are not the manager, they’re just who everybody follows. That works as long as you don’t hav too many people like that and too much fighting for that role. That person has sort of a humble, modest attitude where they don’t care. So I’ve seen environments where you don’t really need that sort of protection. I’ve seen especially in smaller companies, founder run companies, where there’s nothing to protect people from. In the larger organizations that tend to have the sort of difference between performance, what you need to do to help the company and then what you need to do to succeed personally, the wider that gap is, the more you need that sort of umbrella role. I think it depends. Most of the time it’s probably a fair assertion.
Before we go, I want to throw out “what makes testing different?” A lot of the things that we said could apply to a development team. They could apply to an IT team. They could apply to a team of doctors or lawyers. What is it within testing that makes this more challenging or what are the opportunities within testing?
PERZE ABABA: Putting all soft skills and the socio-logical side of these things aside, one of the biggest challenges when it comes to the mindset of testing is how you look at a system. It’s difficult enough to find architects and developers who can employ general systems thinking, or even use the theory of constraints to look at a problem and identify what issues to fix or address. Same exact thing for testing. It’s knowledge work that is a sub-team of a greater knowledge work. To be able to support whatever goals that the team needs to deliver, testers can be the people that adhere to a very specific set of confirmation biases and say “hey, the test criteria os good and we can go” or you an look at something much wider where exploratory testing comes in and make it a better feedback mechanism into the team so that we have a better understand of the quality of our system. That really makes it a lot more difficult to build because testing is a skill. It’s not something that you can go to school for. It’s something that you go to school in the school of hard knocks. That makes it a little bit more difficult difficult to put in front of anything else.
MICHAEL LARSEN: To piggyback on that, Perze. The other thing that I would suggest that also makes testing a little more challenging than some other organizations is, if you are dealing with a role when you have your hands in making something that physically gets into the hands of somebody else, thats a very tangible thing. “hey, that particular car that’s out in the market, I helped build that.” Whereas if you’re the one saying “I put together some metro interface to evaluate how that hinge works”, it’s hard for people to wrap their heads around that. Testing suffers from what I sometimes refer to as the “one level removed” syndrome in the sense that we can’t actually say “we made X amount of extra money because we did this” or “here’s the tangible proof that this is done the way that it is supposed to be done”. I think that is one of the trickier historical elements; how to testers prove there worth in world where the actual tangible is given much more credence.
GERIE OWEN: Testing is like any other discipline. You have to measure. You look at the number of defects post -production or your defect removal efficiency vs. the ones that are reported during the test process, you are going to se that value o what you saved. Yeah, some organizations in some verticals, you can go ahead and do testing in production. I saw a DevOps presentation where they do al of their testing in production. Yet there also a lot of verticals where you absolutely cannot do that. Anything safety critical, medically critical, thats where the testing has to be right. And yes, you can measure. I mean. If people die, then you know you’ve failed. You absolutely need to be doing your measurement.
MATTHEW HEUSSER: OK, any other thoughts on what makes testing teams different from regular development teams?
GERIE OWEN: Testing teams are actually champions of your organizations reputation.
MATTHEW HEUSSER: I really like the positive way you presented that, Gerie. It’s far to easy for testers to still have that “It’s never going to work. I’m going to break your stuff. You don’t understand.” Absolutely it’s a call for criticism, but I am going to offer you feedback that is going to help us make better decisions and is going to help us make a better product. I think that is. more agreeable way to put it.
PAUL GRIZZAFFI: And I think, going to go back to something that Michael said earlier around the multiple hats that testers are beginning to wear, whether or not that’s a good or bad thing, it’s a thing thats happening. It’s probably something that we should embrace. I think what happens is, when you look at it and say, “why is a testing team different?” A testing team usually grows to wear different hats, whereas other teams typically do not. Development teams, especially on a team of any sot of size, you know when you get past two or three people and you’ve got a larger organization, a larger company. The developers tend to develop. Maybe they write a little bit of test automation, maybe some unit tests or something, but they’re very seldom the ones that are the scrum masters. They’re very seldom the ones who acting as the B.A. type of role. And again, for better or for worse that’s what I have seen on average. That’s a very broad paintbrush so anybody out there that’s in dev and actually wears multiple hats, don’t “@“ me [laughter]. Just on average it’s what I see when I talk to different organizations. It’s an opportunity for us to embrace and we should take advantage of being in that position both for our careers and for the good our teams and our organizations and our companies.
GERIE OWEN: Absolutely!
MATTHEW HEUSSER: Thanks, Paul. I think that’s a great way to put a close on it. Paul hasn’t been on the show for awhile. What have you been up to? Where can people learn Moree about what you are working on?
PAUL GRIZZAFFI: Well, I have not been on the show for awhile because I’ve been on a lot of billing clients and the meetings and between the meetings and dropping of the kids it’s just been unfortunate timing. Mostly I’ve been doing consulting, I’ve got a backlog of writing that I’ve got to get to. I will be at some conferences for the rest of the year. You can see me at STPcon, you can see me at TestBash in San Francisco,and I will be giving two presentations at ConTest in New York. If you’re interested in any of that and seeing what I’m up to you can go to my blog, Responsible Automation and go to “Upcoming Events” and I’ll have all my upcoming events there.
MATTHEW HEUSSER: Thanks, Paul. Appreciate that. Most of the folks know about me. Now Michael, you’re going to be at PNSQC later in the fall this year?
MICHAEL LARSEN: That is correct. Yes, I will be at PNSQC and I am doing two presentations. I’m an invited speaker for my topic that I’m going to be covering regarding Accessibility and Inclusive Design. A topic near and dear to my heart. The second part I’m doing with a friend, Bill Opal, and we’re putting together ‘When You Absolutely Must Build a Test Framework From Scratch” taking into account all of the things that you need to consider when you actually use the words “Test Framework” that oftentimes gets overlooked [laughter].
MATTHEW HEUSSER: We should do a show on that because there’s so much implied there and everyone things they know what they mean and if you dig into it they all disagree. Fantastic. And that’s October 8-10 in Portland, Oregon. Anyone else have anything big they want to talk about?
PETER VARHOL: So I’m at the end of September, about a month from now I’m at SEETEST. That’s the Southeast European Testing Conference in Belgrade, Serbia. Followed the following week by STARWest in Anaheim at Disneyland. I will be at QA&TEST in Bilbao, Spain in the middle of October and Agile + DevOps East in Orlando and wrapping things up for the year at Eurostar in the Hague, Netherlands.
PERZE ABABA: I’l try to top that… I’ve got nothing, so [laughter] if you guys need to say hi to me, I’ll be at Twitter, LinkedIn so please, reach out.
GERIE OWEN: I will be at most of the same conferences as Peter and again, if you want to save money, I have two webinars coming up. I’ll be doing “How Did I Miss That Bug?” In early October, October 10th with EuroStar. I will also be doing “Does DevOps Need Continuous Testing and Automation Test Optimization?” That will be doing a joint webinar with SauceLabs. And when we’re talking about building great test teams, Qualitest has multiple engagement models that can bring you test teams that meet your needs and your budget.
MATTHEW HEUSSER: Thanks, Gerie. All right everybody, thanks for being on the show. We’ll be here again next month, same bat time, same bat station. Thanks everybody.
PETER VARHOL: Thank you, Matt.
GERIE OWEN: Thanks
PAUL GRIZZAFFI: Thanks, everyone!
MICHAEL LARSEN: That concludes this episode of The Testing Show. We also want to encourage you, our listeners, to give us a rating and a review on Apple Podcasts. Those ratings and reviews help raise the visibility of the show and let more people find us.
Also, we want to invite you to come join us on The Testing Show Slack Channel as a way to communicate about the show, talk to us about what you like and what you’d like to hear, and also to help us shape future shows. Please email us at TheTestingShow(at)QualitestGroup(dot)com and we will send you an invite to join the group.
The Testing Show is produced and edited by Michael Larsen, Moderated by Matt Heusser, with frequent contributions from Perze Ababa, Jessica Ingrassellino and Justin Rohrman as well as our many featured guests who bring the topics and expertise to make the show happen.
Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to BE a guest on the podcast, please email us at TheTestingShow(at)qualitestgroup(dot)com.
Thanks for listening and we will see you again in October 2018.
[END OF TRANSCRIPT]