问题
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?
回答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.
回答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.
回答3:
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.
回答4:
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.
回答5:
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
- Avoid arguments.
- Show respect for the other person's opinions. Never tell someone they are wrong.
- If you're wrong, admit it quickly and emphatically.
- Begin in a friendly way.
- Start with questions the other person will answer yes to.
- Let the other person do the talking.
- Let the other person feel the idea is his/hers.
- Try honestly to see things from the other person's point of view.
- Sympathize with the other person.
- Appeal to noble motives.
- Dramatize your ideas.
- Throw down a challenge.
Be a Leader: How to Change People Without Giving Offense or Arousing Resentment
- Begin with praise and honest appreciation.
- Call attention to other people's mistakes indirectly.
- Talk about your own mistakes first.
- Ask questions instead of directly giving orders.
- Let the other person save face.
- Praise every improvement.
- Give them a fine reputation to live up to.
- Encourage them by making their faults seem easy to correct.
- 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?
回答6:
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.
回答7:
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.
回答8:
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.
来源：https://stackoverflow.com/questions/1772900/how-can-one-get-a-qa-team-more-involved-in-the-sdlc