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

Testing the testers...

Measuring the performance of testers (product quality assurance engineers) is required for the assessment of their capabilities in finding critical defects of the product before getting released in the market. Testing of testers is also needed to identify and recognize the talented team member who is more effective in making the product better by catching vital defects. The effort put in finding high priority/severity defects than cosmetic or low-value-to-customer defects should be recognized and rewarded. Devising a set of metrics gives a QA team leaders the ability to measure the performance of the team and to build a transparent appraisal/recognition system in the organization. Ensuring a team of highly skilled and effective testers will also optimize the cost-to-company (CTC) of the testers.

Before assessing the performance of a product quality engineer, it is appropriate to set the expectations from them - when do we say that a tester has done a good job?

So here is the discussion question:
How do you guage performance of a tester (quality engineer)? How would you assess the performance of a proudct quality engineer (tester) YOU being –
a) A product developer (you are a developer and assessing a tester)
b) A Quality Engineering Team Manager ( you are a Manager and assessing a tester)
c) A fellow tester (you are another tester and assessing a fellow tester)

I am looking for performance metrices/indicators/expectations that would show a true picture of a tester's performance - I am looking for "Metrices" or "Attributes" as "Indicator" of performance; something that would make the assessment more objective / would assist in relative assessment.

Dark User Interfaces

I really like these newer user interfaces that use a dark gray/black color palette. The first time I saw it was in the early releases of the Microsoft Expression products. Then, I saw the UI of the Adobe CS products shift to a darker palette. And following that, Corel's graphics program shifted to a black/gray interface.

I like the dark UI because it allows the thing you're actually working on to stand out more. The UI itself competes less for the user's attention. The items you want are available and visible...but they're understated...less screaming, "Look at me. Look. At. Me." than products with more colorful palettes.

Question: Anyone know of a UI that uses a dark palette that's not a graphics program?

Below: zBrush

Below: Adobe Bridge

Below: CoolIris

Below: Paint Shop Pro X2

Below: Microsoft Expression Design 2