[ Originally published on Techwell’s StickyMinds ]

I’ve written about the many hats that testers wear, and the importance of collaboration between testers and engineers. My thinking in those articles focused mainly on the work that testers put into their teams, but lately I’ve been considering the other side - the effort that teams and companies put into their QA engineers and testers.

I don’t typically do a end-of-year post. In fact, I think this is my first one. I wasn’t going to write this one, either - mostly because I felt like I hadn’t really accomplished anything. But as I thought back about my 2018, I realized that I actually had accomplished quite a few things that I’m proud of. One of my goals for 2019 is to be more intentional - that is, to do more explicit planning for my path forward, and I know there are things in 2018 that I can use to inform and inspire my approaches and goals for 2019. So my first step toward that is writing this post, thinking about what I did or didn’t do, and how I can use my experiences from the past year to succeed in the new year.

I really enjoy writing about the conferences I attend - I think it’s a great way for me to reflect on what I learned, and remember which cultural or technical ideas I want to try out. I also hope that it helps someone who is on the fence about whether to attend a conference - being able to read about the content and impact can help them decide (or convince their company to pay for it)!

Earlier this week, Ash Coleman asked a question on Twitter: “Today I walked a team through several analogies to describe testing, like ‘gatekeeper’ or ‘goalie’… Curious, which analogies do you use to describe testing and testers?”

[ Originally published on TechBeacon ]

[ Originally published on TestCraft ]

[ Originally published on TechBeacon ]

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.

I’ve written previously about my setup for BackstopJS (which I’m still excited to say is the creator-recommended tutorial for V2 of the package!). Since that article, I’ve switched from JSON to Javascript configuration, and added a Makefile as the main method of running visual regression tests with BackstopJS.

My team’s most recent project has been really interesting - it’s a JavaScript project that includes using the Serverless Framework to deploy a variety of AWS Lambda Functions (e.g. uploading to S3 buckets and making requests to the API that we built). Part of my responsibility as QA Engineer was to set up a CloudWatch dashboard in AWS. Dashboards can be created manually in the CloudWatch service, but I wanted to create the dashboards through code deploys.

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?

As I write this, I’m entering into the second week of capstone projects at Portland Code School. The lectures are done, although the learning continues, as we use our knowledge of full-stack JavaScript to build our own web apps!

I’m halfway through my developer bootcamp, filling my brain with JavaScript and preparing to transition my skills out of the classroom and into a job. Along the way, I’ve been collecting resources: documentation libraries for Orchestrate and jQuery, tutorials like Mozilla Developer’s Network and Treehouse, and oodles of bookmarked pages for projects and tips. There are an enormous number of resources out there, and they cover every aspect of development that I could want.

When I look at each day of learning JavaScript, it can be really hard to recognize how much I’ve learned since this course started. But then I realize that just five short weeks ago, this interaction on Twitter would never have happened.

Hello, interwebs! I’m Angela - it’s nice to meet you!