I saw this illustration make its way across Twitter recently, and it immediately resonated with me. This illustration perfectly captures how I feel and how I work, and what I strive for in my roles. It’s what I want every company, every manager that I work for to understand about me.
Recently, I helped spearhead our department’s adoption of centralized static code analysis. I worked with one of our mobile engineers to research various tools and create a decision matrix for comparing options. I’ve introduced new tools to my team before, but this was my first time selecting a tool that would be rolled out and used by my entire engineering department. It was also our department’s first time trying centralized static code analysis. Now that I’ve had the experience of researching and selecting tools that other people will use, I thought it would be interesting to lay out why we chose to implement centralized static code analysis, how we chose a tool for it, and maybe most important of all - how we introduced these changes to our department.
Note: This is the second post in a series about the different roles I end up carrying out as a Quality Assurance Engineer. You can check out the first post here, where I talk about wearing my Tester hat!
Quality Assurance Engineer is a broad term that can cover a wide variety of roles and responsibilities. It can refer to a more specialized role, like Automation Engineer or Technical Support. It might be used to describe someone responsible for DevOps practices, or the person in charge of Scrum Master duties and feature testing.
I was on a tech panel last night for a Women Who Code event (which was awesome!), and there were some really great questions from the audience about testing and quality assurance. One question stood out to me, because answering it caused me to reflect about my role at a team level.
Last year, our VP of Engineering came to me with a request. One of our long-term clients was having continued issues with the functionality of a website feature, and Tony needed me to do some investigating to figure out why the failures were happening, as well as make recommendations for fixing it.
Last week, I attended my first DevOpsDays PDX! I wasn’t quite sure what to expect, but it seemed like a cool conference - DevOps obviously intersects with QA work, and my interest has been peaked by articles I’ve read from the likes of New Relic, Julia Evans, and Etsy. It ended up being an awesome experience, full of interesting talks and conversations, and I came away from it feeling reinvigorated about how I do my job as a QA Engineer.
I just attended Monitorama 2017 in Portland, and I wanted to talk about my experience! I think it’s useful for me as a brain-dump and reflection about what I took away from the talks, but it’s also nice for other people to have some more insight into what the conference is about.
At Metal Toad, where self-organizing and self-managing teams are encouraged (and even preferred), there is a lot of room and trust for individuals to make change. Because of this empowerment, I’ve had the privilege to try out and implement changes. Not all of my attempts have been successful, and some have benefitted from iteration, but it’s pretty cool to know that the opportunity to affect change is something that’s offered and supported here.
Everyone agrees that developers’ work should go through QA in order to ensure a high quality of that work, but how many companies have a dedicated QA engineer to drive that vision forward? It’s kind of like the attitude around test-driven development - it’s definitely a great idea, and people get behind the theory, but it’s often overlooked or an afterthought in practice.
We are Toads
I first came across BackstopJS when I started as a QA Engineer in March. My team had a Drupal 7 project that was suffering from pretty regular visual regressions when we deployed. The visual regressions on the project were consistent only in their frustration - sometimes a deploy to the dev environment would be fine, but staging and prod would have regressions; or dev would have regressions, but then staging wouldn’t. At the time, the site had about 60 individual pages and several integrations, and it was pretty tedious to check for regressions manually.
One of Metal Toad’s continuing goals for developers centers around mastery. There are some high-level ideas and objectives around this, but part of reaching mastery has to do with enhancing and maintaining the code quality of our projects. We’ve put some workflows in place for our projects, including changing the way we deploy and QA. Teams at Metal Toad function fairly autonomously, with the ability to create the tools and processes that work best for them; so I’ll be speaking for my team, as the QA Engineer for Team Mutant Ninja Toaders (TMNT).
A few weeks ago, I joined some of my Toads at the first TechTown Change Agents, an event put on by Portland Development Commission to talk about how we can bring diversity, inclusion, and equity to our workplaces. One of the most interesting conversations revolved around the topic of culture. What makes up a company’s culture? How can a company show their culture? What culture indicators are already in place, and do they accurately represent the culture we have and/or want?
I stumbled onto an interesting Twitter conversation the other day, and I’ve been looking forward to continuing my thoughts in a broader form here on my blog.
I just finished my first week as a toad!
Developer bootcamps are popping up all over the U.S., and Portland is no exception. We have no less than five code schools, including one focused on online courses. With so many options and opportunities, how do you know what’s right for you? And when it comes to committing your time and money, how do you make sure that you take a viable path?
Hello, interwebs! I’m Angela - it’s nice to meet you!