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'm working in environment where a QA team is absent at all. There are only developers who are testers too. We write specs, production code, tests, make exploratory testing. And I'm a true believer that development and testing are inseparable. Testing application from the beginning to the end of the development process gives great results. But I'm really lack of a dedicated QA person or team - people who have different from my coder's mind. Their role plays our community that are on a pretty long distance nevertheless.

Answer 2

I think that the qa team should be separate from development, but work closely with dev.

That said, I think a good way to get them more involved earlier in the process is to write good specifications and include them in the process. As you work on implementing the product, they are able to focus their testing on the core pieces (because those are defined in the spec), and are able to collaborate in the development process.

As an QA guy, I have directly experienced the difference between testing a product that has a clear goal and can be understood vs a vague framework that needs to be covered.

While it is possible to find the bugs in both, it is more enjoyable and much more rewarding working in an environment where you know what the product should be doing.

Answer 3

I have a rather broad set of feelings on this. I think the QA team should be involved early so that at the requirements gathering stage the idea of some tests can be discussed and a baseline formed then, before any code is even written. This also allows QA the ability to juggle if they have enough to work on yet or if they want to see more of the functionality to help build various tests.

There are a few key points if you want to try to do the transition that come from Dale Carnegie's book, "How to Win Friends and Influence People:"

Twelve Ways to Win People to Your Way of Thinking

1. Avoid arguments.
2. Show respect for the other person's opinions. Never tell someone they are wrong.
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions the other person will answer yes to.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person's point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Call attention to other people's mistakes indirectly.
3. Talk about your own mistakes first.
4. Ask questions instead of directly giving orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give them a fine reputation to live up to.
8. Encourage them by making their faults seem easy to correct.
9. Make the other person happy about doing what you suggest.

Some of these are easier to apply than others, but there is something to be said for explaining why they would want to be involved earlier, how does it help them, why should they care to have better tests or help to make a better product or service?

Answer 4

At our shop the QA manager and development managers are peers, and it's a relationship built on respect and shared goals.

You need strong, experienced QA engineers, people who learn fast and can get results quickly; or at minimum one strong senior person to lead the QA team: somebody who can command the respect of your senior developers. Then get the team to focus on real problems, take a risk-based approach, show their value: once they start finding real problems before the product is released, the kind of problems that should never have got past a smart developer, then the dynamic starts to change.

Get the QA team and development team both involved in retrospectives / release reviews: let them work together, come up with ways to improve how software is built and released.

Answer 5

Have you heard of method engineering? Using this approach, your QA team could contribute to the design of the specific methodology (or methodologies) that your company (or development team) ends up using for each project.

The way it works is that, with method engineering, a method(ology) is constructed from pre-defined method components, rather than being taken off-the-shelf (such as RUP or XP). If you QA people are aware of practices, techniques and work products that tend to work, they can contribute these as method components, and thus participate in the specification of the methodologies.

Answer 6

Role of Software QA, this role verifies that the Requirements conform to the basic standard (Templates) and the requirements are free of any ambiguities. In terms of completeness, Software QA would also review the risks of not completing the Non-functional section. The Software QA would also review the Traceability Matrix in order to make sure all requirements were referenced.

Software QA should analyze the origin of the defects and examine the SDLC to determine where the defect was introduced (Requirements\Design or Coding) and review these with the process owners for possible improvements.

The QA’s should also be running these tests against the existing code base. This validates that the test harness is working correctly and that the new tests do not mistakenly pass without requiring any new code. Obviously, the new tests should also fail for the expected reason. This tests the tests themselves, in the negative: it rules out the possibility that the new tests will always pass, and therefore be worthless. OK, so that’s day one and two.