Separate QA v.s. Scrum Team Member - How should QA be involved?

Question

(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

Answer 1

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 ;)

Answer 2

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.

Answer 3

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.

ScrumBut:

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.

Answer 4

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.

Answer 5

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/