Прочитал книгу «How Google tests software» — рекомендую всем кто связан с разработкой и тестированием программного обеспечения. Ниже несколько мыслей которые мне понравились.
Quality is not important until software is not important.
A single rock star SET can make a huge impact on a team.
If the capability is important enough to document, it is important enough to test.
Bugs and bug reports are the one artifact every tester understands. Finding bugs, triaging bugs, fixing bugs and regressing bugs are the heartbeat and workflow for software quality.
Everyone files bugs, including engineering directors and Senior Vice Presidents. Googlers file bugs against products they use even if the are not part of that product team.
We sometimes joke, we are only good at managing highly skilled, highly motivated, and autonomous engineers.
It is important to note that Googlers are expected to set goals higher than they think possible. If Googlers meet all their objectives, they aren’t aiming high enough.
A large part of maintenance engineering is about monitoring quality, not looking for new issues.
My message to TEs out there: If you believe in something, build it! My advice to management out there: Give these engineers some room to breathe and experiment and they will do amazing things for the business and the customer.
Google’s culture of sharing ideas — supporting bottom-up experimentation and organizational flexibility creates a fertile world for test innovation. Whether it ends up valuable or not, you will never know unless you build it and try it out on real-world engineering problems. Google gives engineers the ability to try if they want to take the initiative, as long as they know how to measure success.
Everyone on a team works on the product, not some part of the development process.
The other part of the equation is a maturation of the idea that quality is everyone’s job and not the sole domain of engineers with the word «test» in their title.
* TE — test engineer
* SET — software engineer in test