Surprizing Facts in "How Google Test Software"

There are quite surprising facts in "How Google Test Software". Some of the surprising and need some thought on type of facts are related to the 'Fatal Flaws in Google’s Process".

What are the things that google find fatal and others don't in their process and why they find them fatal?

• The first fatal flow that none of us finds fatal when we look through traditional testing is that if we ask a developer what he is doing about quality, then his answer often is “testing”. 

But book says that quality is not lying in testing. It has to be embedded to the product it self. As the developers are free to think that the tests are going to be done by testers and should not be considered as a burden to them, and then what happens is that they start to reduce their testing. This should be avoided.

• The second fatal flaw is that the developers and testers are separated and they are walled by different organizations at Google. Which is sometimes a prominent feature in most of the other organizations.

Mostly the testers who work at google are identified with their job and not the product that they are working on. But it is said that, a sign of a healthy organization is when the employees say, that they are working on a particular product, rather than telling their designation. Development and testing should not be separated  If it happens then a role-based association is created and testers find it really difficult to assign themselves to a particular product.

• The third fatal flaw is that, the testers often embrace test artifacts than the software or the product they are creating.

Counting the number of bug reports by a test engineer and being happy over them is not the thing to be in testing. It is like something focusing more on process than the product. The things which are being done need to be directly associated with a value.

• The fourth fatal flow is that almost always the users find problems after releasing the products, even though there are lots of tests had been carried out before releasing.

In here what needs to be considered is that ensuring quality is every one's responsibility. It is not confined to people who are assigned for testing.

And the other surprising facts are related to the future of employees at Google, which will probably rewind the future of SETs TEs and Test Directors/Managers in other IT related organizations in the near future.

It is hoped that there will be no future SETs. How is it going to be managed?

They can be considered as software engineers as a whole. So what happens ultimately is that the 'testing' task is equally distributed among all the developers of the company. Then the development and testing both is done at the developers side. Ultimately all can work as one team.  



TE's tasks will be changed in the future. How is their life cycle being replaced?

In the future TE's job will be something different with respect to the present job of them. In future dogfooders, early adopers and crowd testers etc. will be involved in testing and they will be giving feedback about the system. Then what TEs will have to do is seeing and evaluating whether all these things(feed backs etc) covered the project in testing aspect. He will be involving in calculating the risk impacts, adjusting the test activities like things rather than involved in test creation and execution types of things. So ultimately they will become as specialists or managers for testing.

What happen to Test Directors and Managers in the future?

There will be fewer Test Directors and Managers involved with Google in the near future.   

So ultimately these things will be very surprising without the explanations for them.