Owen Gotimer

Testing and test automation are things that aren't often put into curriculum at colleges and universities for people who are studying software. You obviously heard about testing and test automation in some capacity and you've decided to start your career in that space. What attracted you to test automation? How did you hear about it? And why did you decide that was where you wanted to dive into the software world?

Chloe Chen

Before I joined the team, not saying I didn't hear it at all, but I'd never tried it, and I only had like a vague idea what it could be, what you can do in it, sort of things like that. So when I was studying in university, I was majoring in computer science, so it was more like software development topic. I remember one interesting thing. It seemed completely unrelated to what I was going to do back then, but it's weirdly tight to what I am doing now, which is kind of interesting is like the life story.

So what happened was, I did my first three years of university back in China, and when I did that every week we had this very interesting event in our school called an English quarter, where people just go, get together, and then just talk in English just as practice. It's not just for students only, it's also for professors and people who live around the university. So I got to talk to this one person, who was at the time a manager of some high tech company, and he was leading a team of testing automation, and he was doing a lot of testing conferences himself as well. At that time, I didn't think I would do anything related to testing at all at that time. So I ended up talking to him, and he started to talk about how testing is underestimated, how automation is highly required, but never got enough attention, and how testers are not treated as well as they should be. I just thought it was an interesting thing to talk about, and I never actually thought about that. Then I just went away, and then I started to think about, okay, I don't want to do anything right after I graduate, I might want to do something else.

So I ended up coming to Canada and did my master here. After I graduated, I found a job at InGenius, and then at that time, I was basically, I can't say desperate, but I wanted a job because all my friends had all started working. So I ended up being a manual tester. After a year, I'd like being a tester. I found testing on very interesting. It's been an ongoing battle between developers and testers. I find it's funny and interesting to see their reactions whenever I find some critical bugs. I enjoyed that. But also at the same time, I feel I don't want to waste my skills in software development, and I really liked it when I did that in school, and also in my co-op term. I felt there had to be a bridge somewhere.

Then I talked to my boss who was very supportive. He said, "Okay, we're in this phase where manual testing was no longer enough for us, so we tried [test automation] before, and now we want to try it again. Would you be interested in joining the team?" And I was like, "yeah, sure, I want to try anything." And then I joined the team with another dev person. We tried it again, and then eventually we were like, "it can't be a site job, it has to be a full time job, and we have to have some experts or guidance from some specialists." That's why we hired Chris Loder, who we all know very well. He became my mentor. I started this journey, and we basically started from there. He's been the best person I've ever met and worked with. He gave me a lot of help.

Owen Gotimer

Chris Loder, who you mentioned, is super passionate about test automation and values that you also are super passionate about test automation. Now that you've been working in this test automation space for a little while, you mentioned that some of the things that attracted you were the fact that you could bridge manual testing to the software development background you had. Now that you're fully integrated here in the test automation position, what about it do you still like? What about it do you find challenging working in this field?

Chloe Chen

So this field is kind of different from manual testing and development. You feel like you're doing a developer's job, but also there is a lot of testing mindset involved in the process of your work. The challenge would be, first of all, I would say communication, because there has to be a lot of talking between you, and both dev teams and manual testing teams. With developers, you have to persuade them to work with you to figure out the best way that you both can automate the product. It can't be just the automator who goes in and just decides what to do with the product. The developer team has to work with you, so you need some help from them. And also from the manual testing side, you have to work with them to figure out what to automate. A lot of people would think automation comes from nowhere. They just invent themselves, but it's not true. In our company, for example, we don't automate brand new products, we automate whatever has been regressed. So we have to have something being tested. In the process, you have to talk to manual testers to figure out what they tested, if there is test scripts that we can follow, so communication is our first challenge.

Second of all, you have to show your value to your company, to your boss, to your fellow coworkers, to see that there is actually value to automate your product. So being able to work on what you want to work on and also at the same time showing your value and finding a good method to measure your value is also challenging.

Owen Gotimer

With that value piece of it, obviously, the team you're working with is valued, what kinds of things have you done as a team and personally as a test automator to show your value?

Chloe Chen

Okay, so take my case, as an example. Our product is a productivity software. So we basically tie the telephony system into CRM systems. So part of our main functionalities for our product is to talk to the telephony systems like Cisco or Avaya, or Twilio, like cloud phones, things like that, so we have a very wide platform support. So to show our value, we need to expand our supported systems as well. So we have customers who use mostly this phone system. So if we can speed our process to control those phones, it showed that we can also keep up with the product. So basically, we are capable of lifting a lot of weight from the manual testers. That showed our value, and I've done a lot of work in helping that, so that's kind of what I did to show our value.

Owen Gotimer

When you lift that work from the manual testers, you're giving them an opportunity to go out and do exploration and test in ways that the automation can't test it in. Right?

Chloe Chen

Yes, exactly.

Owen Gotimer

It's interesting, because I think there are still challenges in getting people on board with test automation. Some of the challenges are that people think that test automation means the end of manual testing. But you're right here saying the exact opposite. You're trying to give the manual testers more time and more space to do what they're good at, which is testing the software.

Chloe Chen

Yes. So basically, our goal is to, first of all, not end the life for manual testers but give them opportunity to live a better, easier, and more interesting life so that they can do more exploratory testing and do less tedious, repetitive testing. Also, we want to give the confidence to our product manager and our stakeholders to say, whatever new features that they're developing won't break. So basically the turnout time has been greatly shortened because of automation. Before, if you added a new feature, you wanted to make sure that older features were not broken. So you have to regress the old features over and over again, doing repetitive testing. But with automation, we've taken that repetitive part out and that guarantees the new development won't break the old one. That's kind of related to what we're doing right now which is what we call smoke test. So basically, it guarantees that our product is not broken. It's a baseline for us, and it has given our product manager and our CEO a lot of confidence in our product. So that also has shown our value as well.

Owen Gotimer

When you run these tests—the regression test you mentioned is what you all focus on, but you do the smoke test and whatnot—once you get these reports back, what is that next step? Obviously, the reports themselves are helpful, but they're not useful unless you're actually taking action with the reports you've received. So when say you get an automated regression test report back into your inbox, what is that next step for you all?

Chloe Chen

Okay, so what we want to do with our regression test is, we want to make sure that everything passes, first of all. So we basically evaluate the failures. That's the first thing we do to see if there is still something that we need to improve so we can get a more robust run. That's the first part. The second part, we basically evaluate the failures. So we know that there is no gating bugs in in the product so that we can guarantee from our side that the release is a go. So we basically evaluate our regression tests to see if we can release the product.

Owen Gotimer

Totally make sense. That's so crucial that you're actually acting on and evaluating and taking action steps once you get those reports back to spin them up. So another cool thing I want to talk about, and I know this is something you were interested in talking about, and you talked about your journey to test automation and you were working as a manual tester, you and one other dev to kind of this test automation project on you all hired Chris Loder and now there's three of you and the team kept bigger, and now, you are in a position where the company has actually been acquired, and you've had to go through this acquisition. What's that journey been like for you in terms of going from a smaller test automation team to where you are today?

Chloe Chen

So, first of all, a little bit correction, the team did not grow. So it was me and another dev who did the automation second try. But after Chris joined our team, the developer went back to do his job, and I was left alone with Chris. So it was just the two of us, and then we had a product owner for our automation. So we have a team of three and then we had students to write automated tests, and also a summer co-op students. So that's basically what our team is. And right now, like you said, our company has been acquired by growing. First of all when the acquisition happened, it did not really change much of our job. But we were still doing what we were doing. So another little bit of a background story is InGenius—that's our product—is the only product in the company that has automation ongoing. All the other products, they've had automation, they've tried it before, but they never succeeded. So people knew the value in automation, they just did not know what to do with that. So thanks to Chris building such a good framework that can be used not just by us, it has a potential to be used by other products. So people see the value in it. I think it was our Vice President in the R&D team, he saw the value in this and he saw a demo from Chris and just felt it was a great idea to develop the automation team as the service to be used widely by the whole company. That's how we started our journey to use automation as a service not to just benefit our product, but also the whole company in other products, too. So that's something we're working on right now, and, hopefully, we can have it going very soon and benefit some of the products that have shown interest in us.

Owen Gotimer

How have you and Chris worked together tomake that transition from being a product specific team to now trying to operate as a service? You said you haven't really started in terms of actually working with teams, but you're going to start rolling that out soon. What has that journey been like in terms of going from a single product trying to prepare yourselves to be used as more of a service across the company?

Chloe Chen

When we built our automation framework at the beginning, we never saw this happening. We never saw that we were going to be bought, and we were going to expand our framework like this. So we basically built our framework in the shape of what will work the best for InGenius. However, you have to have a very, very well designed and robust framework. If you have that as your root level, then you basically have to alter some of the things you used to before, make some of the specific things only contained in the level for this specific product, and then basically, shaping in a more general interface for other products as well. Basically, it's like a multi-head plugin, you can just plug into other products and run your automation on it. It's like a shell. So generalizing the framework is our biggest challenge now, and we have competence in building a great thing out of what we have. So that's our vision, and our journey basically starts from there.