I work as a PM for a medium sized org that develops mobile application.

My front end team has some challenges with test scenarios. Often a task will be handed over to the QA team or for code review and either have untested functionality or crash quickly, then is handed back to the respective dev who fixes the issue promptly. Is this a lack of skill or process?

The issue I believe lies in the mindset of the dev's and not necessary just the skill level. Its simple things that are overlooked like a scroll function is tested on X mobile device model but not another model and has unexpected results such as infinite scroll on the larger model and no issue on the smaller model, which is quickly correctly once identified.

How can I put some framework in place that helps prompt the dev's to run further test cases on their code and help develop a mindset around this?

We currently use Jira to define tasks and requirements, in past organisations I've used TSF which had the ability to make templates for tasks, the tasks would prompt for risk/impact/breaking change/unit tests needed etc. Would this sort of approach work here?

Any other examples or resources people could point me to would be wonderful!

  • The second paragraph seems to talk about the kind of errors that imply that the developers didn't even just run through their implementation once. The third paragraph shifts gear into testing all features on multiple devices. Those are two very different things. The latter sounds very much like what you presumably hired your QA team for.
    – Flater
    Commented Aug 5, 2022 at 12:23
  • Also be very careful about using "bug was corrected quickly" as a negative remark about the team. Rather than thinking about it that it must have been trivial if it was fixed quickly; have you considered that your devs are simply putting in effort to resolve reported issues quickly? If you miss the mark on this, you're liable to make a dent in morale and developer attitude over time.
    – Flater
    Commented Aug 5, 2022 at 12:24
  • My tone didn't reflect what I intended here, I think the team is responsive to quality but as you mentioned above they miss items due to not testing their implementations before handing over or haven't fully designed out a solution. Its a fine line between QA catching bugs and missed test case scenarios. I'm hoping to nudge them into a better initial design. What happens is a task will say "Add new button that does X,Y,Z". The task will be completed and reviewed between devs and ticked off as done. Then on final review or QA is fails. Commented Aug 8, 2022 at 0:46
  • As the button does X,Y but only does Z once then crashes the app or something similar. Trying to find an example that highlights the problem here. At a high level its not laziness, I believe its a lack of understanding of initial design( dont know if theres a better description here). When I create a task I assume the devs will think through the design needed and go from there but maybe I need to really define the task out further? Commented Aug 8, 2022 at 0:52

4 Answers 4


One obstacle, and perhaps the biggest, is the separation of the "front end team" from the "QA team". When you isolate the skills needed to get work done and introduce hand-offs, there's little incentive for cross-training in the skills needed to get the work to a completed state. There's no need for a developer to develop the knowledge, skills, and mindset for testing because they can build the work and then throw it over the wall to someone else while moving on to the next thing.

Combining quality assurance and testing skills with development skills on a single team and making the whole team responsible and accountable for delivering well-designed, implemented, and tested work is a first step. You may still need to encourage the sharing of skills and cross-training, but limiting work-in-progress and focusing on the flow of units of work from the start of development through the completion of testing can help. There are plenty of techniques from lean and agile methods that can promote cross-functional teams, cross-trained individuals, and flow of work.


the respective dev who fixes the issue promptly. Is this a lack of skill or process?

It's an obvious lack of process. You say there is a dev responsible. They will never find their own mistakes. Ever. That is human nature. Did you ever spot your own mistakes on math homework? No. You made that mistake, your brain is now sure that it is correct. It takes another pair of eyes to spot that.

Your process should include at least: one developer who programs, another developer who reviews the code and (ideally another) developer who tests. And only then it is ready for QA.

Developing software is teamwork. But not in the weird TV way where more than one person is using the same keyboard. But by sharing tasks that one developer alone cannot possible be good at. Finding your own mistake is a very hard to impossible task. Finding mistakes of others is easy. So use that power and bring "others" into the process. No ticket should ever be the result of a single developer working on it. That is the way to bug ridden software, no matter how good that one person is. They can never be as good as the whole team.

And as a side effect it might even lead to a better "team". Because it is hardly a team when each developer is working alone on their task all the time.

  • At present we have have cross code reviews happening then handed to the "senior" dev to do another review then merge and release to QA. However what tends to happen is an item is passed from one dev to another. "tested" it then passes initial review and fails on final review with simple things like a button is added but doesn't actual function etc. Usually a task is defined as a user story with the requirements below: As a users.. Must be able to do X,Y,Z Commented Aug 8, 2022 at 0:42
  • And then I leave the implementation up to the developers, this is where I feel I need extra process around testing but following agile process this is meant for the developers to work out the solution? Commented Aug 8, 2022 at 0:43
  • Yes. Ask them why the bug slipped through and what they want to do about it. It might be a good idea to have testable acceptance criteria on the story, so testing is both easy and the person testing can be held accountable if one of those fails.
    – nvoigt
    Commented Aug 8, 2022 at 5:40

Without knowing your team and your process, it's impossible to tell.

As a PM, I would look inside your organization and process for clues.

  • Do developers have enough time and an environment that supports focused work to design and implement meaningful tests? If people work under pressure, tasks that seem less important tend to be done with less attention or not at all.

  • Do developers and QA people talk to each other? You've mentioned separate dev and QA teams and handover, that's kind of a red flag.

  • Does your organization encourage quality over quantity? I.e. do you give incentives to create good code in the time it takes, or any code in as little time as possible?

  • If the issue is seen with multiple developers, do you perhaps try to get work done with low-pay workers who might not yet have the skills and experience they need to create high quality code?

  • Do you actively work on improving developer's skills by offering them courses and other opportunities to learn new skills?

I know, this is a list of questions and not an answer, but in the end you will be the one who needs to find an answer to your question.


Isn't the job of QA to find bugs? what's the point of having a QA team if we aim to have zero bugs?

My understanding is that you want to get rid of the clear, easy-to-find bugs, do you?

The key to this is ownership and responsibility... make someone have some meat in the game in regards to the application's success and that person will be conscious of the app and the processes.

I think your devs are just using the process as a pipeline... they deliver code and go home at the end of the day... none of them is being conscious about the results of their job because they are going to get paid anyways ;)

Responsibility means, being punished or rewarded whether we are doing right or not... find someone that wants that kind of responsibility, make sure punishments and rewards are understood and set beforehand, and there you go... you fixed the problem!

That person will check with the devs, QAs, etc, to make sure the app succeeds...

One important aspect... responsibility without power is hell! No one wants to have responsibility and accountability for something that's out of their hands... so make sure that person can have a final say when there's no agreement, at the end of the day, that person will be punished or rewarded, so they will take the best decisions, remember... his/her skin is at play! ;)

Your Answer

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

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