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!