0

I have a QA team report directly to me, their day to day tasks are:

  • Correct the new specifications together with tech leads/PM
  • Write test plan
  • Discuss with teammates during implementation phases
  • Review automated test from teammates
  • Workflow stuff, analyze bug reports etc..
  • Automation test when they have free time

Each team have 1 QA, 5-10 devs, they're not "Tester" so counting bugs are not mean for them. In my point of view, my QA team doing a lot, there is no debate about that among team members.

But then a high level manager asks me: What is the QA team doing? We're refactoring team structure (honestly we didn't deliver as expected) I realized:

  • It's normal to ask that, they're not technical and don't work directly on the ground.
  • Different with others developers, QA don't have many Jira tickets under their names. Their git commits also can't compare.
  • Don't like PM, they don't speak to high level manager that much (only the lead QA - and not really often).

My actions:

  1. write daily stand-up so we have work logs (report a Jira issue for all spec mistakes is too overkill I think)
  2. discuss on public group only (no slack private group)
  3. peer review from team members

What's else should I do/stop to make theirs communication tasks more visible?
(Task like discuss, review specs, classifying/prioritize bugs)

PS: Of course I can just explain to them, but it's not data-driven. If one day I leave or lost trust from my manager this won't work.
Also it's unfair to the team. I don't need to write a daily report.
The only difference is they don't work directly with high level manager.

Improve this question
3
  • If I understand correctly, this is the kind of information I normally include in the communications plan. The appendix to the communications plan lists the messages that are needed to facilitate cooperation among the teams. Your QA team seems to be managing those communications channels. The simple metric is to use those channels as a denominator and show that they meet 100% of the needs; you could also use that to estimate the size of each message. (Communications plan is the protocol diagram for a project).
    – MCW
    Jun 28, 2021 at 15:57
  • Hi @MCW you mean this kind of lucidchart.com/blog/project-management-communication-plan ?
    – nvcnvn
    Jun 28, 2021 at 16:21
  • 1
    Having trouble pulling down all of that page, but it looks right - that is the kind of plan I use. You could simplify it for your needs.
    – MCW
    Jun 28, 2021 at 17:24

1 Answer 1

Reset to default
1

CodeGnome's Law of Transparency says "No invisible work, ever!"

You say that

Different with others developers, QA don't have much Jira ticket under their names.

To which I reply - why not?

Every single day to day task that you listed, I could envision as visible as either a task, subtask, or workflow status. So... Why not do so?

Improve this answer
2
  • you are correct, but what tracking method for discussion I'm not so sure. Write test plan, review code can be track with ticket/status. But more than often they get involved into discuss of multiple features. Normally other engineer have 1 task as time so communication overhead is smaller.
    – nvcnvn
    Jun 29, 2021 at 1:08
  • @nvcnvn How to group/split tasks should be discussed with the team. Assuming Scrum, I'd suggest to bring it up in the Retrospective.
    – Sarov
    Jun 29, 2021 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.