Rock Solid Software Without Hiring an Army
Trish Khoo an Engineering Manager at Google gave an insight into how they handle software testing. Another great talk from Business of Software 2015. Here are my notes.
Most companies will get to the point when they feel a need for more testing. At this point some knee jerk reactions can often be made.
Typical decision #1
Hire a QA team to fix the quality problem. Don’t do this!
- They are accountable but have little power to change the software.
- Manual testing is very slow and doesn’t scale.
Typical decision #2
Hiring an automation team to fix the testing problem. Don’t do this!
Expectation from engineers that the automation team will just write their tests for them so it isn’t there job.
“Hiring a test automation team hiring a team of people to encourage bad practices in your development team.”
What is testing?
Testing provides expert driven feedback on the state of the business requirement gaps, user impact and overall project quality.
One way to do this is by Checking.
Everyone can do this. Checking is easy, but testing is hard.
A testing expert in a team will:
- Make sure people make timely decisions by providing feedback.
- Make development processes more efficient.
- Design tools to help teams become more productive.
Change your company culture
Creating a culture of testing doesn’t happen overnight. It must be a long term process that everyone in the company is involved in. Sometimes however there will be pushback, some of the common reasons for this are:
- We don’t have time to write tests.
- We don’t know how to write tests.
- That’s not the way we work at this company.
One problem is when the a (10x) developer is rewarded for quick work that has poor quality with no automated tests. It may take longer to write automated tests but the overall result is a reduced testing phase. Developers that take the time should be rewarded.
Hire the right skills
Types of role Google hire:
- Software Engineer — Tools and Infrastructure
- Test Engineer
Both have engineer in the title. This is a way of empowering the testing experts by making them first class citizens in the team.
Learn, don’t blame
Cultivate a postmortem culture
- Write a factual timeline of events for each bug.
- Include suggestions to prevent it from happening again.
- End with practical actions.
Trust your people. Make it clear that it is OK to make mistakes.
Launch and Iterate
“Fast releases. Fast feedback”
Experiments and feature toggles can be used to test features with a small subset of users. Doing this is less risky.
Dog fooding can be used to get the team to test the feature themselves by using it. Use this kind of testing to find edge cases and usability issues. Functional issues should be found way before this point by checking.
What’s in it for me?
Well, warm fuzzy feelings inside you for starters. But also:
- Rock solid software.
- Ability to quickly change with confidence.
- More time to innovate.
During the Q & A after the talk an interesting book was recommended for teaching people how to test. This was Explore It! by Elisabeth Hendrickson.
