Roles and responsibilities

- I found that the role of QA can differ based on the individual, the team, and the company they are working for. on the team and what needs to get done. It helps to have skills cross functionally, and apply certain skills when needed. These skills should include technical aptitude, business knowledge, DevOps principles, and process and release expertise. Technical aptitude is needed for both manual and automated testing. While most QAs focus on higher level automated testing, this can also include lower level testing like unit and integration. The role will usually include some programming and scripting as well. Here a QA can wear the hat of a tester or developer. Business knowledge is necessary for activities including feature scoping, test planning, test case management and bug management. This requires having an understanding of how the product functions and what's important to the business. Here a QA can wear different hats such as business analyst, data analyst, product owner or product manager. The DevOps principles needed will include being able to configure tooling, set up continuous integration, and automate processes like running tests, or deploying the application. Here a QA wears the hat of an infrastructure or platform engineer. Process and release expertise includes defining and improving practices for testing throughout development, as well as a process for releasing new version of the software. Here a QA wears the hat of a release planner, iteration manager, or delivery manager. Now, I know this is a lot. You may be thinking what hat do I wear? Don't worry, while every skill is valuable, you won't need to excel in all of them. Identify your own strengths and For any team that you are going into, ask questions to understand what the role on your team will be, and what different hats you might need to wear. Find a team where you can continue to hone in on your skills or take on a challenging project to grow When possible, try to work with and learn from your teammates who are all skilled in different areas. Let me share three examples of projects I've worked on in the past, and what kind of expertise, or hats, I needed to wear in each project. The first example is of a small startup of 75 people. I was the first QA hire and needed to define how to ensure quality for the product. Right off the bat, I needed to do things like determine and implement a strategy for manual and automated test. I needed to set up and maintain the continuous integration pipeline, and make a release plan. I had to do all the things because I was the first hire and a lot was expected of me to build a strategy for quality from the ground up. I found it necessary to be well rounded in my skills and wear multiple different hats, and thankfully my past experience allowed me to do that. The second example is of a small team at a 100 person company where there was another QA on the team in addition to myself. At this company, there are cross functional product teams. The QA team worked together to iterate on our existing processes for testing and release, automated more functionality, and performed manual testing. At this company, the other QA and I were able to share responsibilities somewhat. It really came down to what our individual strengths and preferences were. For instance, I did a lot of automation while my QA partner focused on infrastructure work, and was constantly finding ways to make automation faster and more reliable. This way of working allowed for more depth into a particular area. The third example is of a larger and more complex company. Here the technical teams were divided by area of business with each area having multiple product teams and multiple QAs. On this team, because the QAs worked in similar areas of the business, we were able to help support each other even when we weren't on the same team. One QA was assigned to each project, which meant that it would be best if that QA was well rounded in their skills. But sometimes, a QA wouldn't feel comfortable enough with technical skills of DevOps skills. We ended up using our specialties to collaborate with one another to conquer and divide. For example, if I focused on automation, someone else focused on more business specific task, and the other QA was really eager to work on release management and improving our processes. We all wore different hats. Each project and each team is unique in what is needed. You won't always follow the exact same testing processes, and you won't always need to have strengths across multiple areas. need to have strengths across multiple areas. What is most important is that you should understand What is most important is that you should understand how to identify what skills will be most needed how to identify what skills will be most needed and who is going to wear what hat. and who is going to wear what hat.