[Originally published on TechBeacon ]
Depending on where you work, the quality assurance engineer job title can cover a wide variety of roles and responsibilities. Are you ready to take them all on?
As a QA engineer, I’ve had the benefit of creating my role as I go, adding responsibilities and accountability for things that I think are important. Before I was hired, QA at my company existed solely as a tester role on specific, high-stakes projects. There were no stable QA processes, no continuous integration/continuous delivery, and very little ownership to go along with my responsibilities.
Because of that, I’ve ended up wearing three hats in my day-to-day work: tester, DevOps engineer, and architect. I have readily taken on all three hats and learned both how to wear them and how to switch among them—and you can, too. Here’s how!
The Tester Hat
One of my main responsibilities when wearing my tester hat is acceptance testing for several agile teams. During projects, I review each Jira ticket against the acceptance criteria to ensure that it matches the stated client and business needs.
Part of acceptance testing is exploratory testing. I typically merge the feature branch into the main branch, so I can make sure it integrates with the existing code and functionality without introducing regressions or bugs.
Through acceptance testing, you should focus on the user and admin experiences that your team is creating. It’s rarely captured as explicit acceptance criteria, but this is one of the most important parts of testing features.
Your goal should be to give clients a simple, intuitive admin experience. When reviewing features, try to look at them from the clients’ point of view—as someone who may not have experience updating and maintaining a website or app. Something that may be obvious to an engineer is often unclear or not intuitive to someone acting in a site administrator role.
Communicate through collaboration
When I think a ticket needs rework, I try to explore root causes for the bug or regression, or make a specific recommendation for improvement. I don’t want to just throw it back over the wall. Clear, empathetic communication always plays a part, but especially here.
It’s easy for QA feedback to be taken personally, so it’s important to make your feedback as collaborative as possible. Your goal in giving feedback or asking for changes is the same as everyone else’s on the team: To create the best version of the product. Make sure the engineers feel comfortable knowing that they’re working with you, and they won’t need to go around you.
Create detailed test plans
Occasionally, I’ll have a bug or regression that calls for a deeper dive. When that happens, I write up a formal test plan, create and implement test cases, and report my findings, with recommendations for improvement. Depending on the situation, I’ll also work closely with clients to make sure they’re looped in, and they understand the work that’s being done to alleviate the issue for them.
Taking the time to summarize your process behind exploring, troubleshooting, and fixing the feature allows your client to establish or rebuild trust and confidence with your team. You wouldn’t expect engineers to throw work to you over a wall, so make sure you’re taking the same consideration with your clients and including them in iterations and planning.
Build a foundation of quality
The need for building that trust and confidence is a large part of why I advocate for QA practices. By including these practices throughout the software development lifecycle, my team shows clients that we take the quality of work seriously, ensuring at each step that we’re producing work we’re proud to deliver.
When you show clients that you have a commitment to quality, you’re reassuring everyone—from engineers to product managers to C-suite executives—that you have checks in place to prevent and catch bugs or regressions. These practices give you the confidence to trust in your code and processes, and to have confidence in the products you’re helping to create.
The DevOps hat
Before you read about the hat, you must understand what DevOps is. There are many lengthier explanations, but here’s my TL;DR version: DevOps is a set of practices and processes used to promote collaboration among different roles in order to to create sustainable methods for creating, deploying, and maintaining code.
Let’s see how that translates to your responsibilities when you put on your DevOps hat.
Set up for continuous delivery
I first put on the DevOps hat to help get our teams set up with continuous delivery (CD), which was a big priority for our engineering department leaders. We scheduled a swarm day, where several of us got together and configured a CD workflow for our existing repos.
During this time, I also created documentation for setting up and maintaining our CD process, which allowed other people to add a new project to the process or troubleshoot with relative ease.
When you’re responsible for setting up CD, part of your responsibility is to ensure that information isn’t siloed. In addition to creating the foundation for the best practices of CD, you need to help your engineering teams successfully use them.
Documenting your workflow and processes allows your teams to share responsibility for CD, but also makes sure they aren’t dependent on you to accomplish a task that could be blocking them.
Create a standardized development workflow
Before I started as a QA engineer, there was no formal workflow for QA steps. Testing and code reviews were done infrequently and didn’t easily allow for useful, actionable feedback.
To solve this, I created a workflow for sprint boards in Jira, with a column for each ticket status: To Do, In Progress, QA, Code Review, Product Owner Review, Done. I led discussions on the team about how to use this workflow day to day, and we established a process around when to move tickets between columns.
We also integrated GitHub into Jira. This means that commits, pull reviews, and deploys are reflected on each ticket, so every member of the team can easily see the status of work.
You may not use Jira or GitHub, but the principles around standardizing a development workflow still apply. It’s important to make sure everyone on your team can easily see what state the ticket is in and know who’s responsible for the work during each step. This shared understanding allows your engineering teams to work more effectively and efficiently and prevents them from losing time or energy due to disorganization and miscommunication around work.
Follow practices and processes that foster collaboration and communication
All of these processes and tools were implemented with DevOps in mind. When you wear your DevOps hat, your goals are to:
- Reduce overhead and increase understanding
- Make it as easy as possible for your teams to create and maintain code
- Establish transparent accountability and responsibility for getting work done
These are things that QA engineers constantly review, reflect, and iterate; the work you put in here will build a solid foundation to start from.
The Architect Hat
My architect hat is a bit newer, and I’m still getting comfortable with the fit. As with many of my responsibilities, this role evolved out of a need that I saw existing on a project, and I decided to see if I could help improve the situation.
See the forest
The project in question was suffering from a lack of clarity around communication and requirements, and sprint work was creating a lot of FUD (fear, uncertainty, and doubt). Putting on my architect hat, I stepped back from the sprint view for a more holistic overview of the project to see how I could help solve the churn that was happening.
I looked over tickets two sprints ahead, reviewing the acceptance criteria. If the criteria contradicted requirements that had changed in previous work or seemed unclear in setting expectations, I added a comment to the ticket and tagged the product manager to clarify and update the acceptance criteria.
It can be easy for engineers to limit their vision to just the work in front of them when they’re focused on a sprint. When you wear your architect hat, your goal is to remind them of the higher-level, holistic view of the project—seeing the forest as well as the trees.
By continuously looking ahead and connecting the stages of work, you help create and maintain a shared understanding of requirements among the client, the product manager, and the engineers. That shared understanding is important to team success. It reduces churn and rework, preventing the frustration and loss of morale that arise from those experiences.
Recommend and troubleshoot tooling
I also recommend tools and tests for the engineering teams to include in projects. Most recently, I worked with a team to set up a suite of end-to-end tests for a project. I sat down with them and did an overview of the tool, walked them through the local setup, and wrote a few tests to get them started.
As an architect, you can’t just send a link to the tool and throw the work over the wall. Part of your responsibility is to help software engineering teams use the tools that you put into place.
One of the best ways to collaborate with engineers is by following an “I do, we do, you do” process. Schedule a meeting where you introduce the tool and make sure everyone can set it up locally. Run through a test or two, then work with the team to do a few more before they continue on their own. It’s also helpful to check in with the team periodically, and set aside time to help remove blockers or make improvements.
Improve the developer experience
With those end-to-end tests I mentioned above, there were four distinct test suites. Those tests were run frequently during the project, and new tests were constantly being added. As the test suites evolved, the commands to run the tests became complex and frustrating. To help make it easier for engineers to run the tests, I added a Makefile to the project. This took the command from something like
codeceptjs run --config=./codecept.mobile.js --grep "site-functionality" --reporter mochawesome --reporter-options reportDir=./output,reportFilename=mobile-sf.html
to
make mobile-sf
For testing processes that we use more regularly across projects, I’ve created template repos for easy setup. We now have templates for visual regression testing, accessibility testing, and documentation that can be quickly copied over and set up on new projects.
Testing tools and frameworks is part of engineering, but it’s typically not the primary work for a software engineer. If the tools you put in place are cumbersome or frustrating, the engineers won’t use them.
Lowering the barrier of use for your engineering teams is an important part of the architect role.
Makefiles and READMEs are a great way to do that. You can also research and try out tools before implementing them on a project; find the blockers and weed out the problematic tools before you ask the engineers to use them. This gives engineers a more positive experience, and allows you to share the ownership of adhering to quality standards by making it easier for them to do the work.
QA Haberdashery
There’s no singular definition of what it means to be a QA engineer. Responsibilities differ among companies, and even between teams within the same organization. However, there is generally a range of tester, DevOps, and architect responsibilities that any QA role encompasses.
QA is a supporting role, but definitely not a minor one. It creates a foundation on which engineers and product managers can build. It involves a broad variety of tasks and responsibilities, from your team to your clients.
As a QA engineer, you facilitate collaboration and make sure everyone has what they need to be successful. You help create a shared understanding of the work that needs to be done, and make sure the processes are in place to get it completed.
And when you’re switching hats, remember to give yourself time for the related tasks. I’ve found that blocking out time on my calendar is helpful for keeping track of the context switching, and I also use color coding to easily see what type of work I’m doing each week.
As you implement testing tools or team practices, be open to feedback and iteration. All of your hats should be worn with empathy; how you carry out your job makes a difference in how your teams are able to carry out theirs. So put on your hat, and get to work!
Top comments (0)