Responsibilities and suggested tasks of a QA/automation within an agile team?

Question

I've been told by my line manager that I, as the sole QA tester and automation developer of our agile team, lack the engagement, commitment, and mindset of a quality lead, which I effectively am, by virtue of being the single quality-specific team member on the team.
When given specific examples of what he meant, I have to admit he is correct.

My problem/question therefore is, broadly speaking, not tied to a specific incident, what are an agile team QA's responsibilities, acting as the team's de-facto quality lead?
What, how do I "engage" in quality?
What is expected of me?
What does it mean to lead the quality?

Currently, as in the past, I consider my position to be what the title says: a QA tester and automation implementor, to say: I write down test plans, execute them manually to verify the feature's behavior, and once satisfied with the feature, I automate the tests and put them on the CI/CD pipeline so they are now run repeatedly.

That is not enough, according to my boss.

(I didn't ask outright because I've instead been tasked with thinking about the subject and drawing my own conclusions.

P.S. Drawing said conclusions, and acting upon them is the first step of the PIP I've been placed on.
I truly believe if I prove myself the PIP is NOT an auto-termination, but rather a "flag on the play", but in order to keep my career, I need to first understand what I'm expected).

Answer 1

...lack the engagement, commitment, and mindset of a quality lead...When given specific examples of what he meant, I have to admit he is correct.

First, what examples did your manager provide? That is key to understanding their expectations of what you need to be achieving. Without knowing the specifics of those expectations, it's hard to provide meaningful advice.

I write down test plans, execute them manually to verify the feature's behavior, and once satisfied with the feature, I automate the tests and put them on the CI/CD pipeline so they are now run repeatedly.

We also don't know your skillset or the type of software product you are testing. This is a pretty generic explanation of what you do.

However, my impressions of your explanation is you might be doing reactive testing. Meaning, do you wait until the work is assigned to you to start doing testing activities? This is a more "shift-right" mindset. Or, are you being more proactive in testing? This is more "shift-left" mindset.

What other skills or activities do you do that will help improve the quality of the product you are testing?

• Can you setup linting on your team?
• Can you write unit tests along side the developers? Can you code review their unit tests?
• Do your participate in the devs code reviews? If seeing a pull request, do you add comments to it on bugs you see?
• Can you create UI automation frameworks from scratch?
• Can you automate API tests in Postman or via custom code frameworks?
• Can you automate Database testing? Setup unit tests on stored procedures? Other forms of integration testing?
• Can you setup and use SAST tools or other security testing tools? Are you doing any form of security testing?
• Can you do any performance/load tests?
• Are you doing any accessibility tests?
• Are you doing any internationalization or localization tests?
• Can you expand your automation skills from web to mobile automation or vice-versa?
• Are you able to setup any of these from scratch yourself? Or do you rely on others (developers, devops, other testers like a QA Lead, QA architect) to have set these up previously?
• When looking at a list of requirements, can you spot bugs in them? (A big reason bugs occur in software is a misinterpretation of the requirements between devs and testers, so if you can spot those before coding begins, that's a big win.)
• Can you explain the test automation pyramid to your team?
• Do you utilize white-box, gray-box, black-box testing techniques?
• Are you able to find efficiency issues and implement fixes for those in your teams development process? To me, testing is 1 part working on the software, 1 part working on the process.
• Are you able to mentor/coach/train junior level testers?
• If a developer asks you how they can improve their code before you start testing it, what would you say?
• What value do you provide to the team?
• When you find a bug, do you just report it? Or are you able to do some root cause analysis?
• Do you use a bug template when reporting bugs? If not, are you able to implement this? When I've done this, bugs are always fixed faster and developers appreciate this as it speeds up their work.
• How do you or the team triage bugs? Are you able to create and lead a triage meeting with appropriate stakeholders?
• Are you able to create a holistic testing strategy? Something more than just a test plan for a specific ticket or more than just a collection of test cases.

The list of questions and skills goes on and on. If any of these questions are unknown to you, these are areas you can explore learning more about.

Answer 2

In addition to the other excellent answer, I have a few things to add from the perspective of another "lone tester".

First, reading between the lines, I get the impression that you are working reactively rather than proactively. You're doing what the job requirements say, but nothing you've said suggests that you're trying to improve the process your team is using (it may be perfectly suited to the work they're doing - that's something for you to think about), or that you're examining the user stories/specifications before you test looking for potential trouble spots.

Here's how I approached being the only tester for my team:

• I spent the first six months or so learning the way things were done and familiarizing myself with the software I was working with. Said software is a large web application which has been developed continuously for some 20 years, so it poses... challenges.
• As I was assigned more challenging and interesting work to test, I started asking questions about why certain things were done the way they were. In most cases the answer wasn't as important as understanding the process that led to the answer.
• By the time I'd been there for a year, I was actively reviewing requirements and (after the third or fourth time I'd asked a question that led to a fair bit of rework from the developers to handle a situation that hadn't been considered) becoming involved in the process of refining requirements prior to development (we were still working very much waterfall at that point).
• As I grew more settled and comfortable with the team, I started suggesting process improvements. This... evolved. I can safely say that I can stand up an on-premises installation of Team Foundation Server - because I've done exactly that. Twice. And customized it.
• I also built a wiki database dictionary because there wasn't any kind of reference for the database. I live in hope that everyone on the team will keep it updated without my input.
• And a regression guide (also in wiki format) that covers information like what circumstances cause all the fields on a given page to be disabled, which security levels have access to what functions and so on. There's a lot of complicated business logic behind the scenes that determines how a given page displays, and I was tired of having to dig through multiple sources to find the information I needed, so I created a reference source.

This kind of proactive activity that's maybe peripheral to your core duties but makes life easier for everyone in the team is the sort of thing I suspect your boss is wanting to see. For me, it evolved from something that irritated me so I found a way to improve it, then figured that if it irritated me it probably bothered the rest of the team as well, so I made it available to them.

Answer 3

I saw in one of your comments the need to "shift left". That usually means adjusting your quality focus to earlier in the development cycle. Start with the requirements. Attend user meetings, be very active in planning to ensure your team is building the right thing and that your user stories have the correct AC and are prioritized properly. Test that your product owner is doing the right thing. This should be a quick and easy way to show you are shifting left. Also, provide feedback in retros for ways the team can build in quality early on, and be passionate about the product being built, not just focused on the day to day of moving stories to done. Good luck in your performance improvement!

Answer 4

First of all, I would like to cheer you up and applaud you for the effort that you are putting in to find out where you are lacking.

As per my experience and knowledge, QA automation engineers mainly work on designing automated tests which are meant to validate the functionality of web and mobile applications. The job role involves creating the initial test designs, writing the scripts, installing the automation testing protocols, and reporting the results. Some of the other responsibilities include:

• Collaborate with the software design team to discuss verification protocols.
• Identify weaknesses and target areas for software application
• Plan new and innovative ideas for automated software test procedures.
• Review software bug reports and highlight the problem areas.
• Write automation scripts and implement software applications.
• To design and install software databases.
• Troubleshoot automation software and finalize system procedures.
• Identify quality issues and create test reports.
• Collaborate with the design team to solve application faults.

In your case, I would suggest you talk to your team as well as managers and other people involved in QA Automation operations to have a clearer understanding of what they expect from you. I believe communicating the problems is the best thing we can do to create our path to success and ensure success for all.

Answer 5

Agile is a collaborative and iterative approach towards project management and software development that is preferred by various top software testing companies. Agile works with a goal for the teams to deliver value to their customers faster and get their valuable feedbacks. Instead of focusing on full project launch at once, an agile team delivers work in small deliverable chunks. Teams prefer Agile as it is faster way to deliver the working product into market and get valuable feedbacks from the dedicated customer in order to enhance the quality of the product

With this methodology in action, there comes a lot of responsibility for the whole team that majorly includes good communication at each level may it be Product Owner, Dev, QA, Scrum master or stakeholders.

Coming to the responsibilities associated with the QA/automation with in an Agile team, so following are the list of the responsibilities that need to be taken care of:

1. Collaborating with the Dev/ design and the Product owners to get a better picture of the area being tested i.e. having a concrete Acceptance criteria to gain knowledge on what specific areas of the feature needs to be covered specifically.
2. Create defects and share or highlight the priority defects to the team to get the issues tracked/resolved timely.
3. Create automation testscripts to cover maximum functionality with different inputs to find the loopholes in the application
4. Plan, learn and find innovative ideas and frameworks that could help in maximum automation coverage of the application in minimal time.
5. Discuss any sort of the blockers with the team to prevent unnecessary delay.

Answer 6

Agile process roles and responsibilities Manual QA engineers main role to test the software to detect bugs manually when automated testing is impossible. Manual testers validate the product from the end user’s perspective to ensure that product works as expected Responsibilities: Create and execute test cases to detect usability and performance issues

Test automation engineers are in charge of developing scripts for automated tests that ensure fast and effective and has more advanced skills than a manual tester. They also execute and maintain automated test plans that would require a lot of time if done manual. Responsibilities: Run performance tests (load, stress, spike tests, etc.) to ensure the software works expected in extreme conditions

Technical leads are taking care of technical issues and responsible for sticking to a schedule and handling problems that appear during the testing process. Responsibilities:Introducing tools and technologies that fullfil the required business goals and their cost effective, company infrastructure, and testers’ skillsets

Team leads are responsible for solving issues and follow the communication with all the parties and looking to the process followed Responsibilities: Accepting the requirements documents from product owner and then assigning the responsibilities to the team member.