How can one get a QA team more involved in the SDL

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 months ago.

Improve this question

I have worked in environments where the QA team has been actively involved in the development process from the onset of a project through maintenance. I generally have found this to be effective as the QA team has an idea of what is going on from a business prospective early on in the process. They can start working on test scripts very early on.

However, I have also worked in environments where the QA team has been very disjointed from the development team. They have no interest in the process, and simply get involved toward the end of the 'development' phase, scrambling to come up with tests and then executing a limited set of tests based on their own understanding of the business requirements.

What are your feelings on this? How involved do you think the QA team needs to be in the process? How can one transition a team that is accustomed to being 'uninvolved' to one that actively participates in the process?

Answer 1

I laud your goal of getting QA/Test involved in the process early. I'm a big advocate of having a strong test team involved from the beginning of the process and all the way through. It's great to see development looking to include QA. Too often they are resistant to test involvement.

If you want the QA team to be more involved, you have to get them to want to be involved. This probably means making sure their management sees value in it and will fund them being involved. Some QA teams have too much work to be involved early (or feel that they do). This includes QA management. If they aren't bought in, they'll fail to reward someone who is spending time engaging with you.

You need to show QA that they can contribute early in the process and that they get benefit out of doing so. Look around the QA team. Find the guy who knows how to program or at least wants to know how to program. Invite him to design meetings. Encourage him to talk. Basically, start including him on the conversations. If he doesn't start participating, find someone else who will. Sometimes test has an inferiority complex and won't come unless asked. Once asked though, they will probably jump at the chance.

Once you have a QA person showing up, they'll start to get involved and their tests will start to benefit. Once one sees the benefits, others will follow.

So, the short answer is talk to management and get their buy-in. Then approach the team and get one individual involved by inviting him and encouraging him. The rest should follow.

Answer 2

I think it's a matter of slowly getting the team into the process. Where I currently work, there was not much process and QA was considered "testers". Having worked in a previous company where QA was on par with Dev (salary-wise, too!), I found this unacceptable. I started the trend of executing tests other than those provided by Development and found more bugs this way.

But, you have to be careful as you could be fighting deeply-ingrained company culture. You can advocate change, but it will initially feel like turning a glacier into an ice cube with nothing more than a chisel.

Four years later, I am now the QA Team Lead, and our group is required to sign off on all requirements documents. We get involved as early as feasible and most programmers and systems analysts ask our advice on changes. This is because we are the generalists in the business and can tell programmers what other modules their changes might affect.

One advantage I did have with this team is that I had also held a programming position at another company in between QA stints, and remind people of this when they try and BS our team. But it's all done very diplomatically.