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.

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

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/

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.

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.

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