Should there be a separate QAE (Quality Assurance Engineering) team for the product development?

Time to time I keep hearing of companies restructuring their 'quality assurance' or testing team as part of quality-enhancement measures. Some say - let's not have a dedicated team of QAE instead just distribute them among the projects/product development teams. Others would say, this might bias them of product features and so to keep them effective in fault-finding, let's keep a separate team of testers.

What is your take on this?

Which way do you think is good for improving quality of the product being developed?

What are the pros & cons of two methods?

Do you have any other remark / experience to share?

Moving from traditional product development to agile..

The companies around the world are going agile, leaving aside the drawbacks of traditional product development processes. Transition from traditional approach to agile is not an overnight change, especially for the development teams. They have to adopt new practices which could be quite different from what they were used to.

** What are the changes you observe, while transitioning to be a part of an agile development team, as:

1) A developer

2) Designer  (UI, Software/Hardware architect)

3) Tester (quality assurance)

4) Product owner (marketing professional)

5) Project leader /manager

** What do you think are overheads (redundant /time consuming/less productive)?

** What do you think is really good compared to traditoinal development approach?

<Please respond to the questions in the same sequence in your comment>

Attributes for assessment of an SQE (software quality engineer or a tester)

I conducted a survey on Linkedin to get more opinions on how to assess the performance of an Software Quality Engineer (SQE) or a tester. This blog-post summarizes the response I got from Linkedin users.

Attributes of a 'good' tester:

1) Rate and Quality of the defects:

* Finds defects as:

- error in compliance to specifications

- issues to be fixed (independent of any spec)

- issues that a developer never thought of or never specified in the requirements

* Finds high severity/priority defects than just filling the defect database with cosmetic defects

* Ensures lesser number of bugs are reported from the field by doing rigorous testing and catching the defects before the product is released

* Has lesser 'false' defect rate (Waste bugs or defects that are labeled as 'not a defect' or 'duplicate') by ensuring awareness of product to be tested and already found defect database.

2) Attitude

* Shows enthusiasm to learn, understand and master the product domain 

* Puts the best of effort in testing, identification of bugs, adequate reporting and escalation at appropriate level.

* Curious and creative

* Thinks beyond the original scope of testing requirements, during/once the original test requirements are met.

* Keeps up to date knowledge on emerging trends in testing

3) Testing Methodology 

* Tries to test the system in different possible ways to cover the complete list of requirements

* Is innovative in his/her approach

* Does lot of proactive testing and then logs/shares the findings/observations

* Tests the 'untold requirements' like performance, usability

* Goes beyond normal routine to find out 'how not to use the product under test' (negative test cases)

* Puts customer perspective while testing the product

4) Defect Reporting

* Makes clear and complete defect reports - describes behavior and the context to make them easy to classify and repair?

* Reduces the time that is wasted in defect clarification (back-and-forth communication between developer and SQE)

5) Defect Prevention

* Producing information that leads to and supports software process improvements, reducing or eliminating particular kinds of errors

* Is the SQE suggesting process change to avoid future defects and thus helping the developers to learn from their mistakes

6) Automation & repeatability

* Writes automated and repeatable test cases/scripts

* Follows (tracks the execution errors) and understands test script

* is able to walk through the code, understand the logic and debug (when needed)

What do you think about it? 

Do you have any other expectation from an SQE / tester?

What could be another way for an SQE to add value to the product development?

- Mukesh