How you guy manage developer and QA tasks

Currently, I have tasks for developers. Since the task process has NEW, IN PROGRESS, WAITING TO DEPLOYMENT, COMPLETE, ON HOLD and CANCEL. And I include estimation for Coding and Testing in one task. So, I cannot evaluate developers and QA performance whether who is the bottom neck.

In my opinion, should I duplicate task for QA? after developers are complete their task. this way I can track when developers start and finish, also when QA start testing and finish. If there are some bugs later, QA will create another task for developers. Is this make sense?


Do you have any suggestions on this in Wrike?

Thank you.

1
6 commenti
Spot On Innovative Approach Stellar Advice
Avatar

Not a developer but it sounds like your project and QA may be two seperate tasks. Have you thought of using request froms when issues come up that starts tasks to address the specific issues. This could start a new task with your development team to address the issue or bug. This would then create a new task and maybe have a new status workflow.

-Hope this helps.

Ryan

2
Azioni per commenti Permalink
Spot On Innovative Approach Stellar Advice
Avatar

We use QA as a task with specific items that they check as subtasks. They number in the hundreds (which isn't ideal honestly, we are working on it) but it allows each checklist item to be passed/failed easily. Anything that is "passed" is actually being put into a custom completed status, and items that fail are flagged and assigned accordingly. Hope that helps

2
Azioni per commenti Permalink
Spot On Innovative Approach Stellar Advice
Avatar

QA is separated out for us. After a development sprint is completed QA is done against known scripts/acceptance criteria. If a bug is found then it is logged independently as a task in the QA folder. We have used forms for this and have also just added the tasks. 

The task of QA is added to the main project with an estimate associated with it. QA tracks their time there or adds sub-tasks as Michael talks about. A couple of basic tasks in the QA folder: Testing, Writing test scripts, and Regression Testing. These are the tasks that QA should be capturing their time to. It's difficult and probably not super productive to have them track time to the actual bug.

So the work looks like this:
User tracks time to task "Make the widget"
The user marks the task as "Done"
PM indicates to QA that Component/Epic/Widget is ready to test
QA tests tracking time to "Testing"
QA creates tasks in QA folder for each bug found
PM reviews tasks and assigns
User tracks time fixing bugs

1
Azioni per commenti Permalink
Spot On Innovative Approach Stellar Advice
Avatar
Stephen

Very interesting Process Tom, thanks for sharing. I'm seeing more and more people using Folder tags - is this what you do when you add the QA task to the main Project? 

I can see the actual work goes through a sort of 'pass the baton' process between the PM and QA. Do you use Workflows and auto-assigning for this? If so, what do the task's Workflow look like for the QA tasks? Is it custom made, for example? Thanks!

0
Azioni per commenti Permalink
Spot On Innovative Approach Stellar Advice
Avatar

Stephen. 

We like sequestering the QA tasks into a separate lane as it really gives us a view of what may be happening globally on the project. For example, we might be seeing an issue with a particular browser, when QA tests individual tasks, finds the bug it is difficult to see that we are having global issues with a particular browser, it just shows up as an issue with a piece of work. Not sure if I'm making sense.

We tag QA tasks to the folder we are currently working in and the component it effects. So it could be tagged "QA" "Current - Sprint 2" and "Product Detail Page". This allows the PM to understand the work that needs to be completed for Product Detail, how much work is still needed to complete Sprint 2 and how far QA has gotten in testing. All QA tasks are initially assigned to the PM/Producer.

We don't use AutoAssign in the workflows for QA we do use them when a task moves from InProgress to Ready for Code Review. 

We do not use a separate QA process flow. It was tried on one project and abandoned it. We use the Board view at our daily status meetings. Board views don't work well if you have multiple workflows for tasks in a folder. It also became a nightmare to remember to change the workflow.

One of the biggest learns we have is to not use sub-tasks for QA. We love the organizing value of a subtask but the fact that it is hidden in most views makes it difficult to gauge what work is left to be completed when we are doing status meetings.

0
Azioni per commenti Permalink
Spot On Innovative Approach Stellar Advice
Avatar
Stephen

Thanks for the detail Tom!

I think your approach is a very suitable best practice for this. Basically, in a lot of ways, you have the QA and PM/Dev tasks separate but they're given reference to each other (and the main Dev Project) by using tagging. It's a nice clean approach 👌

I think you're right too about using Custom Workflows for this as it can get a bit confusing for people. However, the auto-assign can come in useful, just like you're using it for when tasks are Ready for Code Review.

I've reached out to our own QA team to see learn a little bit about how we do this in Wrike, so I'll post it here when I can 👍

0
Azioni per commenti Permalink

Folllowing List for Post: How you guy manage developer and QA tasks
[this list is visible for admins and agents only]

Didn’t find what you were looking for? Write new post