
Meet The Crafters : Patrick Priestley
How did you get into QA?
I think it was about seven or eight years ago I worked with a close friend of mine building mobile apps. He was more technical, and I would help with the marketing and QA side of things. He ended up going to school for computer science, I went to school for something else and then we met up later on. He was working at a mobile gaming company and there was a QA opening - that’s how I got into it.
So you were doing a few different things there. What specifically about the QA part was attractive to you?
He was the coder - but we both had a common goal and that a way I could contribute.
What was your path for joining Influitive?
I think at the last place I worked, I was on a path I wasn’t really comfortable with. Small children and like these moneymaking games and it just wasn’t interesting to me anymore. I noticed a job posting from Influitive - the title was Product Awesomizer, and that really caught my eye and the description felt like what I was looking for.
Did that title reflect your philosophy behind QA? Do you have a certain approach that you take or qualities that you think are important for a QA person?
I think I’m someone who likes to wear many hats - that’s why I like QA and QA in a start-up specifically. For me, I wanted to find a start-up culture where not only are you doing QA but you kind of get a chance to branch out and be exposed to things beyond the normal QA duties.
Do you think that’s different from the way QA is approached in different companies?
I think so, yeah. I think in a lot of larger companies QA is dropped into a corner and isn’t as integrated with the team. I like getting my hands dirty - seeing a product go from early stages of development, through release, and then seeing customer feedback. I think that’s really important.
What kind of qualities do you think are important in a QA professional?
Definitely attention to detail, I think that’s the basic one. There’s a certain personality that works well - having like an even keel, being able to deal with stress, and being a rock for people to rely on. I think the last one is super important. It’s important to keep a clear mind and help your team to be more productive.
What’s your favourite experience working at Influitive so far?
It was definitely the community product. Working on a project for so long and seeing it go from the very early stages of prototyping,staying with it for a full calendar year, and still continuing to iterate on it. I love seeing customers’ reactions to features we’re rolling out and internal reaction to what we’re doing.
That’s awesome. What do you want to be working on in the future? What new things are exciting to you?
I think the stand alone referrals project is pretty cool. It’s similar to community - it’s an opportunity to start fresh, it feels like we’re going to follow it from start to finish and iterate and gather feedback.
What would you be doing if you weren’t a QA person …?
That’s a good question. I like to do a bit of everything. I like to develop side projects, I don’t know if I could do that all day long but it’s something I enjoy.
You introduced the idea of quality assistance to Influitive - maybe you could tell me a bit about what that is and what it means to you.
Quality assistance is basically a process where QA sits with the team - in a lot of companies, QA can be isolated, and stories are rolled out and thrown over the wall to QA. We try to make sure QA sits with the development team and the product team, and gets insight into the project from the early stages. Because of that early involvement, QA can provide useful guidance to developers - like pointing problem areas of the app or what things might break. And that allows them to develop faster and smarter and it’s a higher quality product by the time it gets to us.
It also saves deployment time because we do something we call demos where Dev and QA meet prior to pushing a story to ourQA environment. In the demo, we can quickly go through things, make sure nothing’s broken, there aren’t any obvious mistakes before it’s being pushed over. So we can address those things more quickly and effectively.
You guys have been practicing quality assistance for a while. How has it been working out so far??
We had some pretty high expectations and goals.. At the start, the goal was under 50 bugs in the backlog, which was a big stretch for us. Today we’re under 10 active production bugs. And the rate at which we log bugs is down as well. About a year ago we were receiving up to 20 bugs a week, and we’re down to, seven or eight.
What practices do you want to see happening more in the industry?
I’d like to see quality assistance implemented more widely. . I talk to a lot of QA people and their experiences are completely different from mine. They’re used to that isolated QA team just kind of existing on their own, seperated from the development team, and an antagonistic relationship between the two. Whereas here, we all work pretty well together.