Question about scrum in terms of developer/QA workflow. We have a problem in our team: basically when a dev submits an MR it needs to get 2 approvals from devs and then task is marked ready for qa. Now problem here is that qa takes 2-3 weeks to get to the task and when they do usually MR has merge conflicts and since QA are quite new-ish they have to wait for dev for conflicts to be resolved, ergo rendering the MR unable to be tested until dev resolves the conflicts.

Our teamlead proposes to solve this by forcing devs to rebase everyday (even if QA will get to working on the task 3-4 weeks later). Problem with that approach is that each conflict resolve removes approvals. So I had a situation where in 3 weeks I rebased like 15 times and 5 times I had resolve coflicts and because approvals were lost I had to annoy all devs and ask for reapprovals. And this is only with 1 MR. Now imagine all devs doing rebasing daily and spamming each other for reapprovals. Its not efficient.

Anyone could advice how to solve this issue?

  • 0
    script the rebase for qa, help get qa up to speed

    skip the approval bs and tag "ready for qa" and have them work off that ?
  • 3
    If it takes 2-3 weeks for QA, who are presumably members of the scrum team, to review a story, then you have some fundamental problems with your whole interpretation of scrum.
  • 0
    Do you work in sprints? You could implement a develop branch per sprint, all PRs go to the develop branch after dev review. When QA gets to finally test it you'll merge the develop branch into master after they mark it as passed.

    And if QA is more than one sprint behind dev you could branch the next develop branch on the previous one... But it might create a mess when a dev needs to integrate a fix to an older develop branch...

    But anyway it's a starting point..way better than everyone rebasing all day everyday 🤡
  • 1
    MR is immediatly merged, and QA starts immediatly.
    If QA has a backlog, All Devs stops creating more work for QA by writing automated tests, until QA backlog is cleared. Then normal workflow can be restarted.
  • 1
    If you have a workflow and the workflow doesn't work because the necessary human resources are missing....

    ... Burn the fucking workflow.

    I mean it. Don't work around, don't try to be smart, just nuke it.

    The workflow needs to fit the human resources given.

    In this case it's pretty evident that the problem lies in the verification phase… so do the sane thing and give QA a sensible timeframe to check the merges.

    This could be - as some pointed out here - by properly releasing in a periodic interval.

    Alternatively you could just do an additional branch, queuing up all changes - or utilizing tags / commit IDs.


    One of the reasons many projects fail btw is this - copying a workflow without validating that it fits.

    It's an entirely different game wether you have 2 devs, 1 qa guy or 50 teams of 5 devs and 20 qa teams of 3 devs...

    Workflows can only solve problems if they're not the problem themselves...
  • 1
    @nibor what he said

    Also if you have a queue that work goes through any improvement in efficiency that does not address the bottleneck in the queue does effectively nothing.

    Google shift QA left
  • 0
    Whatever you do - never ever leave completed features just rot away in abandoned branches. Until they arrive in the common staging branch, some dev has to rebase them every time something significant gets merged into staging. If for whatever reason the dev who did the feature should not be bothered to keep his feature branches rebased, you need to have someone else responsible for the daily rebase and other maintenance of all that branches until they finally get integrated into staging. That doesn't have to be a dev. But if it isn't a dev and conflicts appear, that poor sod better has access to a dev...
  • 1
    But if QA testing is lagging behind, there has to be a reason for that. And it has to be fixed. Because in the end, fetures will wait years until they get tested. And that isn't gonna work at all. So either make devs automate more of the testing or get more QA people.
Add Comment