The Testing Show: A Career In Testing

The Testing Show: A Career In Testing

Have you thought about what brought you to your testing career thus far lately? If you are looking to get into testing where do you even start? That’s the topic of today’s show, where Matthew Heusser and Michael Larsen talk with Lanette Creamer, Elle Gee, Sangeetha Gururaj, and Jessica Ingrassellino about the ins, the outs and the often times sideways about careers in testing as well as the fact that we can do better with building up and helping new developers learn.

itunesrss

Panelists:


References:

 


Any questions or suggested topics?
Let us know!


Transcript:

Michael Larsen: Hello and welcome to The Testing Show. It is September, 2019 glad you could join us. I’m Michael Larsen, your show producer and I’d like to also welcome our Everyday MC, Mr Matt Heusser.

Matthew Heusser: Hello

Michael Larsen: At this time we’ve got a great group of guests and we are going to be discussing the option of a career in testing. What does it actually mean? So with that, let’s go ahead and welcome our guests this time. I’d like to welcome Jessica Ingrassellino.

Jess Ingrassell: Hello.

Michael Larsen: We’d also like to welcome, and it’s been awhile since she’s been on a podcast with us. Lanette Creamer.

Lanette Creamer: Hello.

Michael Larsen: And a first timer on the podcast. Sangeetha Gururaj

Sangeetha G: Yes. Hello.

Michael Larsen: Did I do that Okay?

Sangeetha G: Yes you did.

Michael Larsen: Yes. Thank you. And we’d also like to welcome back to the show Elle Gee.

Elle Gee: Hi, thanks for having me back on the podcast.

Michael Larsen: And with that I’m going to turn over our time to Matt. Let’s get the show on the road.

Matthew Heusser: Thanks Michael. We got a ton to cover today. So let’s first get to know our guests. So Elle and Sangeetha are both Qualitest staff. Elle’s in the west coast USA and Sangeetha in India. I don’t know them well enough yet. So let’s start with this. Elle, how’d you get into testing?

Elle Gee: I got into testing by accident like most of the people that I know really. I was working in a policy role in a business unit in a small country town in Australia and my boss came out and said they need testers. Elle, you break everything. Would you like to go? I went, “Okay”. And I’ve been testing ever since. I loved the idea of going into the meat of an application and testing small bits and pieces and saying what works and what didn’t. Sure enough, I really am good at breaking things.

Matthew Heusser: And you’ve been here ever since, I guess how long have you been with Qualitest?

Elle Gee: I’ve been with Qualitest for five years. I started, with Qualitest in 2014. Qualitest was the company that brought me from my home in Australia. Qualitest was an absolute perfect way for me to take a lifetime of testing in a whole new direction. Coming from a background where my testing focused on government applications, policy-based applications and state implementation, Qualitest, opened doors for me that allowed me to test in a wealth of new areas, medical devices, applications, web apps, mobile phone apps I could never have imagined before I came to the Qualitest, just how wide the testing industry was and how lucky I would be to be able to play in so many playgrounds.

Matthew Heusser: Glad to have you here. What’s your story, Sangeetha?
Sangeetha G: So I’m more into people and talent, so I am the HR human resources. I think I’d been hiring more than 1000 testers so far in my last 10-12 years of overall work experience. Of course, I represent the most dynamic employment market of the world, India Qualitest. I have been from past five months though it does feel like more than five years, but then that’s how life has been. I have had a career where I’ve managed over 2000 employees in a company which has a combination of developers and testers. I have actually seen the career journey of the tester from being known as probably an easier thing to do or compared to development to today being the most niche and difficult thing compared to the other roles. So I have seen the entire journey of how the testing role has taken from an India perspective.

Matthew Heusser: Great. And while we’re talking to you, I was wondering, it’s again sort of that HR focus and you’re hiring a massive scale number of people compared to how many I hire. What piece of advice would you give to someone who wanted to start a career in testing?

Sangeetha G: So someone shouldn’t start earlier in testing because they think it’s going to be easier because it won’t, it’s quite a demanding career. Functional knowledge domain expertise, and the combination of the skills make it more niche. So if you’re going to choose a career in testing, you should be passionate about it. You know, we have to think outside of the box and say that, hey this is not perfect. I can find something wrong in this. That fashion is what will make a career in testing very successful for him. Also, you should not follow it as a career. Probably, you should follow it as a skill development and that has always worked because when I interview I can understand how a successful tester has become successful because he’s pursued it in terms of knowledge, pursued it to develop expertise and not only experience. That’s what makes it different and that’s how they should choose and then it makes them successful.

Matthew Heusser: So I’m going to take that and turn it sideways. I recently took a personality quiz for Briggs Meyers. I’m an INFP and it said that I’ve got a lot of passion but that I probably don’t have the discipline for the professional careers. So that meant engineering, law, or medicine, like I wasn’t going to sit down and memorize a bunch of biology facts about different kinds of flowers so that I could get into med school so that I can be a doctor so that I can go to residency so that I can practice because I want to do the work. I want to do it now. Lazy in that way, but I also will do a ton of self education. For someone who has that attitude. Is testing a good career choice? Why or why not?

Michael Larsen: I have a take on this. So a number of years ago I had the benefit of putting together and helping put together a curriculum for our presidential program initiative. We’re going on almost 10 years now. When this was done was a program called Summer QAmp, Summer Q, A, m, p, and one of the key things that we did as what we called the lesson zero in that development was the idea that if you really wanted to be a software tester, you needed to be able to think like a scientist. And the very first thing we mentioned was understanding of the scientific method. Being able to utilize that and want to utilize that. Now that doesn’t necessarily mean that you have to memorize a zillion and one facts, but it does mean that you need to be willing to say, hey, I have a hypothesis and I want to see if it’s true or not.

Michael Larsen: By doing that, by going through the rigor – and I’m going to use air quotes, “rigor” here – of putting together experiments and being interested in tinkering with those experiments and looking at the data that you get and making interpretations of whether that data holds up the hypothesis or doesn’t. That process of being a scientist is appealing to a lot of people and if that is something that appeals to you, then software testing gives you an opportunity to be a scientist, not just every day but every minute, if you’re creative enough and you have that drive to want to push the boundaries on things. If you think like a scientist you might be really good at testing.

Matthew Heusser: So we’re talking about experiments and self-education, particularly on your own. I know Lanette is going to be giving a Selenium Conference talk shortly about learning to code. So could you speak to that maybe in terms of the personal motivations, the efforts, the failures, the trials and tribulations like learning to code. We both don’t want people to be intimidated and also like it’s going to be a lot of work.

Lanette Creamer: Well for me, it’s been over a year since I started formally working through trying to teach myself web development and JavaScript and I was interested in growing my JavaScript skills because of a product I was working on where we supported JavaScript on both iOS and the Mac as a way to test across platforms, so I wanted to be able to test that part of the application on multiple platforms. But what was interesting in learning development was we literally spent less than one hour of one class out of nine months on testing. We made one expect statement and that’s all that was covered in testing in my development education. Everything else like TDD and pair programming, I’ve since been teaching myself because it’s really not covered. There’s such a conceptual divorce between testing and development. It’s really not surprising that developers don’t know what we do when you see how new developers are trained. It’s still shocking to me that basic testing principles are not covered. Part of what I’m doing with the Selenium Conference talk, I’m giving a talk about nurturing new developers. The whole point of the talk is if we want to welcome newer developers on our team, if we want to have them be successful, what is helpful and what is harmful? How can we integrate them into the team, the welcoming, and also support their learning. I consider myself a tester and a developer and I’m adding more things to that. By focusing on other skills, I’m not leaving testing, I’m just building on my foundation as a tester.

Sangeetha G: I think it all comes down to going that extra mile into solve to an extraordinary result and to engineer something of better quality. So testing is not just testing anymore. You know it’s a quality journey. That’s how we talk about it.

Matthew Heusser: I don’t know if Lanette would agree. Learning to code is not hard. It just takes a lot of time. You have to commit time. You have to keep going. You have to do it again and again and again. You have to practice. It’s not an incredibly cognitively complex task. It’s just going to take time. So Jess hasn’t had a chance to speak yet. You’re the director of quality for salesforce.org?

Jess Ingrassell: That’s for the nonprofit and education clouds? Yes.

Matthew Heusser: Okay. There’s been a rebranding, I guess.

Jess Ingrassell: We were procured by salesforce.com so we once operate it as a separate entity. Now we are fully absorbed by the dot.com. That happened over summer, so with that I’ve taken charge of the nonprofit and the education clouds.

Matthew Heusser: Vou’ve been in that role for a few years now. You’ve bounced around software testing before that, doing a lot of interesting things. You were writing test tooling at bit.ly, so you’ve seen various different approaches to testing careers and managed your own. I’m interested in this learning to code or not, especially if you already have a testing gig. Is that the way things are headed?

Jess Ingrassell: I really think it depends. For my specific team Currently we have people whose job is solely exploratory testing and feature level testing at the business level. We have people on the team who do both coding and exploratory testing because they’re interested in doing both. And we have a dedicated automation team. So as we grow there continue to be opportunities for all the different skill sets. I think it depends on the company. I think it depends on the business needs of the company or the business unit. And I think it also depends on where the company is relative to the approach that they’re taking to development. My very first testing job, I was the only tester, it was about six developers on the team, so it wasn’t crazy, but we were on a month release cadence. So regressions were a nightmare that would take me six or seven hours. But because we were an audio advertising company, we couldn’t perform testing until after eight or nine o’clock eastern time. So I would spend my time testing from nine until two or three in the morning. And I just thought there has to be a way around this. And then when somebody told me, yeah, you can learn to code, I was just like, oh, there’s an answer. So I got on to Coursera and I took a python class and it didn’t apply as Lynette was saying, it didn’t apply to the testing aspect so much, but what it did do was teach me basic code skills and basic python skills. And then as a result of that, gaining those basic skills, I was able to get some entry level SDET roles. So I worked for work market, know.me, bit.ly doing that type of work up until I got to salesforce. So I spent four or five years doing coding work because I picked it up because I hated regression. (laughter) It’s not the most glamorous story about how to learn to code, but there it is.

Lanette Creamer: Hey, Matt, I wanted to just tell you real quick that I don’t agree that learning to code isn’t that difficult.

Jess Ingrassell: Um, I’m also there with, that (laughter).

Lanette Creamer: It is the most difficult thing emotionally I’ve done, I’ve never taken a class that made me cry as much as my class did. And it doesn’t have to be as hard as it is. It’s awful because there’s a lot of gatekeeping and there’s a lot of problematic attitudes. It’s harder than it needs to be for many reasons. The tooling’s a nightmare, especially in JavaScript. It’s just like a whole pile of weazels. You stack them up, strap them together and you hope for the best. It’s Janky and it doesn’t need to be like this. You got to be emotionally resilient. I don’t want to mislead anyone into thinking that because they’re struggling and it’s emotionally hard, they’re doing something wrong. You’re not. The tools are hard and we have to help each other through this learning process and that’s what’s bringing me out to Selenium Conference to talk about being a new developer. We make it sound easier than what it is. It’s not just learning your basic coding skills. It’s the whole tooling stack and all the problems that come with that.

Matthew Heusser: That’s true. It’s worth mentioning that I really agree with that. I have a master’s degree in CS and Undergrad in math and I was a programmer for 10 years and whenever I learned a new stack… I learned Rails. It wouldn’t work and I think we’d spend hours searching stack overflow for a problem that didn’t fix it and then finally I would figure out that there’s a global variable that you need to set for that version of Rails that magically all of it did. I only just learned through conversation with the rails death when I went and talked to people about this. The response I got was any true Rails Dev would know you need to set that flag. These two versions don’t work together. In my experience it’s been that once to stack is built, contributing to it is relatively easy and straightforward but like building the stack on your own in your house of all the different components? The same thing is true with Jenkins, and CI/|CD, building the system out of open source tools that don’t play well together where specific versions are required. That is hard. So getting that first piece of functionality done, your story doesn’t surprise me. Michael had a comment he wanted to make.

Michael Larsen: Yeah, I definitely feel with this, I’m very much with Lanette and Jess. A development manager that I worked with a number of years ago. We talked about this. They made a really good metaphor that I appreciated. He said, coding itself is not difficult in the sense that it’s a skill that you can acquire, but saying that coding is not difficult is like saying that carving wood is not difficult. I mean, you put a chisel to a piece of wood, you tap it with a hammer, and you make incisions while you’re carving wood. Yes, true. But the devil is in the details and the nuance and to be able to be a good woodcarver and somebody who can do really good, polished, and worthwhile work that others will find desirable, that does take time. It takes effort, skill. It takes a daily regimen of practice that you might spend years honing to be able to have enough body of knowledge and enough muscle memory, literally. And that’s the key here is the muscle memory to be able to do what you’re doing. I think I’ve learned 10 programming languages over the almost 30 years that I’ve been involved in software testing in some way, shape or form. But I wouldn’t call myself a master at any of those languages because the truth of the matter is I don’t spend every day working with those things. But there are certain things that I do spend a lot of time with because of necessity. A perfect example is I live in the bash shell or on a unix shell. And so if anybody were to ask what’s the programming language I’m most effective with or familiar with? I unabashedly say… Sorry, bad pun… But I say bash. While it may not be the most efficient way to do things, like from a programming language perspective, I do a lot with it and because I do a lot with it, I know as much about bash as some of our more experienced Dev Ops people do, more readily than say, “Oh hey, we’re going make the shift over to c sharp and .net core. You’ll need to, you know, move up on that”. Some of the basics are already going to be available to me there. If statements and while statements and certain global syntax things, that’s not going to be hard to master in a different language, but there’s a bunch of stuff that is specific that you’re just going to have to put the time in. And I would also say if the company expects you to kind of learn this on your own and do all the work that’s really pressing, don’t be surprised if it’s going to take you a very long time to get to the point to where you’re going to be competent.

Matthew Heusser: I mean that’s fair. My perspective, I went to school for it. I have a different background than most. I appreciate the moderating terms. How about we talk about testing in India and the Indian job market. At one point there was a joke that in Bangalore you could just ride the elevator on your lunch hour and you can get a good job and I think that’s changing. I’d like to hear a little bit more about that.

Speaker 3: Yeah, that might never have made this. First of all, if there are many floors and they would have to take a lot of time to actually go from one floor to another on the interviews. But I understand that was more also for testing in terms of the genericness of the skill. There was a huge market, and then what happened is that the mean of testers came diluted to some point and then came back to the nicheness of it. The dynamism of the market is very high and there are opportunities. For me, the reach to the right talent is too difficult. There is so much of dilution because of the kinds of skills they might have picked, all the opportunities they wouldn’t have gotten. So why? There are many opportunities that it’s not always easy for companies like us where we look for a very high grade of the skills that we want. So yes, there are many opportunities, but would the right person get the right kind of an opportunity where you know a career tester gets a good career path, where the career tester gets the growth opportunities that he desired. It might not always be easy.

Matthew Heusser: So we’re talking about two interesting dichotomies. One is what skills make a good tester? And that’s how should I be aware of my skills and developing them. But on the other side of that, what are hiring managers hiring for and how can we help them find candidates that can actually do the job? Curiosity is really important for software tester, so you hire someone who’s really curious, but if they don’t have the communication skills, they don’t have the coverage skills, didn’t have the analysis skills, they’re just gonna walk around and ask a bunch of questions. So maybe Jess can that help us resolve that dichotomy. What are the important skills in testing and how do we find them?

New Speaker: I think that something that I have tended to look for and something that’s helped me personally is a research mindset. Seeking with a goal or goals in mind as a qualitative researcher might do that research and having the question in mind from a customer perspective, I find that to be a very helpful mindset. Whether or not I’m hiring for a exploratory position or for a fully automated position. Meaningful test design comes from trying to answer the right questions. The fact that give us the highest quality that decreased the amount of risks in my hiring. I’ve been open to people who have different backgrounds as I’ve come into testing from a qualitative research and an education background, I looked for people who had life experiences that give them directed focused curiosity, research skills, concern about others and ability to communicate concerns and risks. A potential criticism in a way that is not aimed at a person or an individual, but is more aware of goal orientation; “hey, we’re trying to deliver a quality product. This is something I’m noticing. How is this going to impact the product that we’re trying to deliver?” The ability to have those conversations and a past history of employment, even if it’s not in test. That shows an ability to have those conversations, to think with that mindset can help in any aspect of testing on either the exploratory or the automation side. So those are the skills that I tend to look for in my hiring.

Matthew Heusser: You’ve hinted on it in that look at their progressive responsibilities throughout their career. See if it’s a part of the job. Do you interview for those communication skills?

Jess Ingrassell: Part of it is just asking the basic questions. I like to know how people handle failure, to talk about how they dealt with a difficult communication issue with a colleague or with a boss and listen to “Do they blame others? Do they take responsibility? How did they communicate the failure when it was happening? Did they communicate it early on? How did they communicate that their concerns’, all the ways that they talk about failure to ‘you can indicate their ability and skill in communicating to others when things are going wrong?” That definitely is a critical part of testing. We’re not communicating, “hey, this works great all the time”. More often than not, we’re communicating problems and to be able to do that in a way that is skillful and considerate of others is something that’s easier for me to assess. If I’m asking somebody to talk about failure .

Sangeetha G: So for us, in India, it’s a lot of choice. We have to rank people to understand who is better than whom and then take a perspective. What I have seen very common is that when the foundation is strong in terms of understanding how coding works, where actually look for anomalies, also the functional knowledge, the tool expertise. Nowadays we also give a lot of weightage on the domain exposure. It gives a lot of perspective on the industry they did testing for, and that also is looked upon. Another thing that I have seen, which works very well is the thought process. Trying to get a solution. That is something which I’ve always seen is a winner instinct when a hiring manager and the process of how this person’s things stage by stage and editing the solution. And I look at it from a HR point of view, communication and articulation is a must because ultimately most of it is services organizations and that is needed to be in constant and right. Communication has to happen. It shouldn’t be a language barrier, which would probably not send the message across.

Matthew Heusser: Okay, thanks.

Elle Gee: I wanted to pick up on a couple of the points that had been mentioned along the way when I started testing back in the late nineties and entered the field because somebody pointed out, hey, you’re good at breaking stuff. That was how most of us got into testing. We were picked out to do testing because we had stood out in some way. I had stood out because I was great at finding the flaws in the applications that we were using. Along the way though, testing has evolved from being that activity that anyone can do to being a quality journey. Personally, I’ve come to understand that the thing that caused me to break things and to have a mentality of breaking things, it was a curiosity. Curiosity has been a theme that’s come up throughout this podcast and I think it likens back to the earlier discussion about think like a scientist. It’s not just about science or having a particular mindset. It is about curiosity and like Jess said, understanding your end goal. Taking that curiosity. Taking the journey, getting to a goal, and then evaluating how you got there. And to that end, I’m looking for people who can recognize yes, they might break something or yes, they’ve got a curiosity, but they can formulate a thought process that explains why

 

Michael Larsen: Awesome. I think that’s a great place to call it. We want to give everybody a quick chance to say, how can we find you and what are you doing? So let’s go around the board really fast. Sangeetha, since this is your first time. How do people get to talk to you? Where are you active?

Speaker 3: I’m very active on linkedin and Instagram more socially, but then yes, on my emails in LinkedIn, I can be reached.

Michael Larsen: Awesome. And Jessica?

Jess Ingrassell: Twitter is probably the easiest place to reach me about testing and, upcoming, I have a keynote at STAR Canada and some workshops at STAR Canada and STAR West.

Michael Larsen: Lanette?

Speaker 3: Twitter @LanetteCream or you can come see me in person at Selenium Conference in London. Hopefully one of those.

Michael Larsen: Awesome. Elle, where can people find you?

Elle Gee: You can find me at https://qualitestgroup.com/careers. You won’t find just me, you’ll find all the opportunities that can be found at Qualitest Group. Or you can visit our social media sites, which include https://facebook.com/qualitest and you could look for the Hashtag #LifeAtQualitest.

Michael Larsen: Matt and I tend to talk about our stuff all the time here, so we’re not gonna’ belabor that, but I will mention just simply because it does tie into this particular conversation. I am going to be talking about testability at the Pacific Northwest Software Quality Conference in Portland next month in October. So if you happen to be in Portland and are participating at PNSQC, come to my talk.

Matthew Heusser: It’s going to be over by the time this show was out, but I’ll be at the workshop on teaching the teaching of testing or WHAT>T>T>T>T>T… which will be in Canada during the Kitchener/Waterloo software quality conference, two weeks. The good thing about that is we’re talking about teaching the teaching of testing. So we’re going to develop materials to help people teach testing, and I expect those materials will start to appear in the community this fall and winter. Ask me about them because that’s what I’m really excited about doing it.

Michael Larsen: Awesome. Fantastic. Thank you for joining us and for everybody out there who is listening to this show. We will see you next month. Thanks for participating and we’ll talk soon.

Matthew Heusser: Thanks, Michael. Thanks everybody.

Elle Gee: Thank you.

Sangeetha G: Thanks everybody.

Jess Ingrassell: Bye.

Lanette Creamer: Bye.

Sangeetha G: Bye.