(Sorry it's a long question)

I have worked with several companies where QA Team is treated as part of the development team, and the QA team is involved in most of the activities within the development process.

But now I am working at a company where they separate QA's effort and they consider QA not a part of the development team. Since then I have had some debates with Project Coordinator who is running project management and whose idea that QA should be estimated separately.

Details are: Development Team (BE, FE, UI, PO) usually have a meeting to discuss the process and tickets in which QA is not invited. QA is only invited to Sprint Planning for each sprint, but not invited to the overview meeting or process of the project. Sometimes I saw the whole team in a meeting, after that I asked PO why QA was not invited and the PO said the team discussed about tickets and processes which were not really relevant for QA! They were discussing the project and QA was not relevant! I was speechless.

And what drives me crazy is that, in the Planning meeting, only BE and FE are allowed to estimate and track work in JIRA. And after planning, they ask the QA's effort separately and write this effort estimation in a ticket as a comment !!

I have discussed with the Project Coordinator a lot of times, but she said it's complicated to handle if QA also tracks estimation and work's hours in JIRA!. I also gathered the feedback of QA team and discussed with CTO and CTO also agreed that there is something wrong with project management and we should discuss with the Project Coordinator. But when we had a meeting, this Project Coordinator convinced the CTO that what she's doing is right! And then, nothing changed or improved.

So I am losing my interest when the QA Team effort is not appreciated. Can some experts give me some idea or suggestion on this topic, which is right, and which is wrong? Thanks in advance

  • 1
    What do you think including QA in all those meetings will accomplish ? Who is the 'boss' of QA and why doesnt he fight about the testing process ?
    – George
    Mar 9, 2017 at 10:39
  • 2
    It depends upon company to company; See In every Meetings and discussion there is no need to include QA team. But while Sprint planning at least single QA (QA lead) should be present so that he/she will drive his team as per the decided plan.
    – Bharat Mane
    Mar 9, 2017 at 10:56
  • Yes, i think question should be 'What will changes i propose actually improve?'. I think its company, product, team specific. No one wants to change things around 'just because', however if clear benefits can be seen, its a lot different.
    – George
    Mar 9, 2017 at 13:26
  • 3
    Note to closing mafia: This question is not trivial to answer, but is obviously relevant to QA life, which makes it interesting. Upvoted. Mar 9, 2017 at 15:28
  • Forgive me, but this looks more of a rant than a question. The background will undoubtedly be useful for the eventual question, but as it stands I don't see one.
    – corsiKa
    Mar 9, 2017 at 19:17

5 Answers 5


My ex-client went through a very similar thing. When I started, QA weren't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.

The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of the team.

Our initial argument was that it might take development one day to produce a fix, but it might take QA four days to test it - QA are the experts, the time required for testing shouldn't be left to anyone else.

So, we came to an agreement that we were able to join stand-ups, sprint planning and retrospectives as observers... which just meant we'd sit in the corner and not get involved.

The business realised they had no genuine visibility of how long it'll take project work or fixes to be delivered. They only knew how long it would take to develop. There was a learning and understanding required from development (and the Project Manager) but, slowly, they started asking QA for input and advice because we were there - in sight, in mind. We also highlighted the cost of finding defects early on (PM's tend to recognise the benefit when cost-saving is involved!) and did a presentation on the importance of raising defects, even in static testing. The developers just needed to know that raising tickets against their work wasn't personal.

After a few weeks, QA being involved became second nature to them.

Anyway... when I left, QA were part of the development team and invited to everything (even when we thought it was too early!) and, although our time assigned to the developer, it was definitely progress and our throughput was recognised! We were active participants in all meetings, and the development team considered our input as constructive.

TL;DR: Request to observe the discussions you're being left out of. Over time, you'll be involved.

As an aside (and apologies for the essay), not tracking your time separately might work in your favour because the business can't ask where your effort is going. This is dangerous for them, but not so bad for you if you fancy a relaxed day or two ;)

  • Thanks Dan, I found myself in exact situation you had. QAs take part in Daily Scrum and Retro, but like you said, QAs are more like observers. The thing is, all our suggestions, proposal for a change/improvement are left unheard, and it's pretty demotivated. I don't know how to improve things when our feedbacks are not taken into account.
    – Ragnarsson
    Mar 9, 2017 at 12:43
  • 1
    Louis, job is to provide the best possible feedback. What to do with this feedback is project/application managers problem. For most companies the goal is to make money, not produce best quality software :)
    – George
    Mar 9, 2017 at 13:32
  • George, yeah I agree with the business goal. But from the QA's perspective, we always want to ensure software has the quality that would satisfy any stakeholders ;).
    – Ragnarsson
    Mar 9, 2017 at 14:32

I've been there. This is my experience:

  • Start with - Review all the documentation you're given. Chances are good something critical has been overlooked because Project Managers tend to focus only on their projects and developers tend to focus on the work they're developing. Testers are usually the ones with a broad perspective. The key thing here is that each time you encounter an oversight you track the cost in time of correcting that oversight. It doesn't have to be extremely accurate, just an estimate in days.
  • Wait for your team to derail a few projects - By this I mean you've pointed out expensive oversights and forced the project to be reconsidered. At this stage of educating the rest of the business, it's a good thing if the reconsideration involved programmers having to rework their coding to fix the oversight. Once that's happened a time or two you will find them receptive to the idea that it would be much better if these gaps were found before they start coding.
  • Talk to the Project Management and higher management again - This time you have evidence on your side: you can point out the cost and inconvenience to the company is not getting your input sooner. You should have developer support as well since I've yet to meet a developer who enjoyed having to redo half a project because of an oversight. The language upper management speaks and hears is money, and rework is wasted money.

Above all stay polite and professional. Upper management does notice who is behaving in a professional manner and who is not.

  • this is good advice. In summary, find ways to deliver value early and the PO/team will start to value QA.
    – jruberto
    Mar 9, 2017 at 15:58
  • Thanks Kate, for the advice. I have actually tried above advice, even talked to CTO, but ... I don't know, the situation is strange here, this is all I could say. It is like, the upper management lets feedback from the teams (not only QA team) unheard and unnoticed. We can just keep trying to make things better, in some way :)
    – Ragnarsson
    Mar 10, 2017 at 9:42
  • 1
    @LouisT - it took me well over a year of doing this to convince my managers that they really did need to involve me earlier - I had to cause multiple big projects to be reworked before my managers really got that I had more skills than just checking things off boxes: a LOT of managers have the idea that testing is not a skilled career path, and they are usually the ones who don't see why testers should be involved early in the project life cycle.
    – Kate Paulk
    Mar 10, 2017 at 17:48

As your question is tagged Scrum I will try to answer it within that context.

It starts with the Scrum's Definition of Done:

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

I would expect work to be complete when it is also tested. Thus this means the development team should have finished testing before it is done. So either QA is part of the development team, or the developers do the testing. Pick one.

Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule;

Concluding that testing should be part of the estimations, so if QA does the testing, they should be part of the planning. Now I understand this could skew your velocity statistics, but if you estimate in relative complexity (story-points) this should not differ too much. Also wonder if these statistics are really valuable, certainly if it is an in-house development.

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.

Hopefully, you are consulted during the Retrospective as QA people are best to suggest improvements for quality I would think.


Overall it sounds your company is not really doing Scrum but is doing ScrumBut. Truly Scrum companies do not have separate QA departments. Ex-Project managers as Scrum Masters are the worst! (It should be forbidden in the Scrum Guide if you ask me.)

Next steps:

Join the team's daily Scrum. It should be an open meeting, just don't talk until the meeting is over. Maybe ask some key testing questions after the Dialy.

Personally I would try to become the Scrum Master of the team and in parallel teach developers to become better testers. Or bring in an Agile consultant that understands the definition of done and that can convince your project coordinator to see the new light. Someone who will challenge the status-quo and hopefully implements the process better than it is now.

For the last resort I will quote Martin Fowler:

"If you can't change your organization, change your organization!"

Do keep in mind in the end it is about the product quality. If the current process works and delivers high quality software, maybe it is good enough. Either accept the situation or keep fighting. The best fight is to keep quietly repeating your wishes to everyone, until they happen. Culture change can take up to three years, be prepared to have a long breath.

  • I've never seen or worked somewhere that is truly Agile - so I like the idea (and sound) of ScrumBut :)
    – dvniel
    Mar 9, 2017 at 11:24
  • 1
    I have. :) I don't understand why teams implement Scrum only half. Only start changing a framework after you practised it about a year and really understand it. ScrumBut is better named ScrumAnd though, read: kenschwaber.wordpress.com/2012/04/05/… Mar 9, 2017 at 12:31
  • Thanks Niels for the explanation. I got to know about ScrumBut. Thanks :). We, as QA, also join Daily Scrum and Retro meeting. As you said "QA people are best to suggest improvements for quality I would think", but it happens that at my company, QA at Retro is like observer, sitting in the corner (Dan's answer). In one Retro BE and FE said they had problems with ABC, and I myself suggested some improvements and the team agreed and would do it next Sprint, but they didn't, because the Project Coordinator said the way there were doing was good enough. And next Sprint, they had same problems !
    – Ragnarsson
    Mar 9, 2017 at 12:40
  • 1
    "I would expect work to be complete when it is also tested." - is work "done" if the testing finds a lot of bugs? What if the first bug is so bad that nothing can actually be tested? Mar 9, 2017 at 13:28
  • 1
    @NielsvanReijmersdal I think it depends on the case whether ScrumBut or ScrumAnd is more appropriate. Most often, companies like the idea of scrum but there's some things they don't like so they leave those out. That to me is ScrumBut. ScrumAnd would be implementing all the scrum components but changing some of them to 'suit the company'. Then again, I am a hopeless pedant.
    – Cronax
    Mar 9, 2017 at 15:42

The biggest issue is people perception and that is what needs to be changed. There are a few hurdles that need to be overcome.

  • Hubris among development
  • Value of QA
  • Teamwork

These are not so much logical stances, but usually one of personal worth and personal biases. I have worked in all sections of the scrum team in multiple project/companies. Developers tend to be more like an artist creating things that others only wish they could create. That makes the QA the enemy so long as that perspective is maintained. It also is anti-teamwork and often one's self-worth gets involved in the job. The PO can't do what developers do so they rely principally on them for all input to ensure the product is finished correctly which is anti-teamwork as well.

The goal is to prove the QA value to the developer as a counterpart. With that in place, the rest takes care of itself. I have done this in multiple ways.

  1. Every defect is a negative hit against the developer who wrote the code. (This sounds hostile, but when you volunteer to be involved earlier in the process to avoid possible defects the developer now views you as a friend instead of the enemy...if they refuse hit them hard during the testing process and they usually won't hold that stance for long - requires management enforcement of negative hits).
  2. Customer satisfaction gets decreased directly due to the exposure of bugs that management decided not to fix. (This will work, but also has the biggest potential of fallout coming back on individual heads...even though eventually management will have to own it due to financial lashback and work to fix the quality issues in the product)
  3. Be the most annoying involved person possible by visiting developers multiple times every day at their desks to ask very "specific" questions about the upcoming functionality and how it's planned/designed (half the time you will be included just to make you stop pestering people, and then you have a chance to show your value - if Scrum master steps in and says stop, just change to going to the SM to explain everything to you...someone will eventually include you - get all of QA to do this and not just you)
  4. Better: Convince people as you have tried so hard to do...unfortunately people often need to "experience" the value of QA in order to be able to understand it.
  5. Best: Specifically craft an experiential approach for each individual to see from your perspective and to see the value you bring to their work. This is challenging, but it will help you with people skills overall as well as to better articulate your worth in the team process. You will also help reshape the whole team 1 person at a time.

Remember, if it was logic it would be working already, you are dealing with people issues now and not logic. This isn't about manipulation, but influence. Find a way to help someone see the benefit to their own job and work by including you. This will likely require you to learn about their job more as well as trying to befriend them. If you speak developer speak it tends to go farther in getting heard and included.

  • thanks. I literally like your answer, especially the part about developers being artists and PO relying on them, and it is so anti-teamwork. All you said is so true in my situation.
    – Ragnarsson
    Mar 10, 2017 at 9:50

In a project I worked on, the development team had a test team, that created unit tests from the requirement and spoke with the coders. However, in addition to that a QA team sat in another part of the building and had a different process. The distinction is between white box testing and black box testing.

Imagine your testers are involved in the development process, they know the developers are changing the way a mouse draws a line on the screen. They come up with a test to ensure the line is the correct colour and length. However, they are focused on the change and forget the knock-on effects, for example: what about the undo stack?

This is where black box testing should step in and say “There has been a change, what should I look for?”. QA should not be blinkered by the development process and should interpret requirements as they read them. That double check provides the quality.

In the project I worked on QA actually had a lot of power, whilst they were not part of the process they could request anything they liked. Generally speaking if QA found a problem, it reflected badly on the development team for not noticing it first. Only senior managers could bypass QA for the purposes of the business needs. This feedback loop leads to developers being very thoughtful about their code and estimates.

Well written requirements should not leave room for ambiguity, you should get the same output from two team. This is the point of an independent QA team.

I'm not saying this is how your company has stuctured its processes, just that it is one reason for the approach.

https://stackoverflow.com/questions/402161/black-box-vs-white-box-testing http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-box-testing/

  • Testers versus developers and testing from finished docs sounds horrible to be honest.
    – George
    Mar 9, 2017 at 21:05

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.