Google Test Certified: History, Levels, Benefits, and Retirement

Test Certified (TC) was an internal Google certification program aimed at encouraging testing as an integral part of software development.

Over eight years it reached several milestones, with more than 1,700 project registrations, over 1,200 projects achieving levels 1‑5, and 578 mentors participating.

The program originated in 2006 and, through years of practice, played a positive role in many Google projects.

TC defined a project’s testing health using five certification levels, promoting developers to adopt unit testing and treat testing as a core development activity.

This goal was achieved, and TC was retired in 2016, replaced by a new, dynamic standard called Project Health.

What is Test Certified?

The certification program consists of a series of incremental levels, each defining measurable testing goals. Teams that achieve more goals receive higher levels, similar to a CMMI‑like improvement framework, encouraging better testing practices.

Why Test Certified?

The program is based on several premises:

Later detection of bugs increases the cost of fixing them.

Google does not maintain a large manual testing team and prefers automation.

Developer‑written tests are a relatively cheap and effective way to find bugs early.

Google lacked a unified testing standard for engineering teams.

The belief is that good testing methods are an essential component of effective software development, and the certification program fosters a testing culture through guidance and mentorship.

What problems does it try to solve?

Lack of engineering testing culture; increasing participation in the program raises awareness.

Absence of standards; the certification ladder provides a clear hierarchical roadmap.

Insufficient guidance; mentors, documentation, and checklists offer direction.

Empowering teams to decide when and how to test their code.

What benefits does it bring?

Reduced emergency releases.

Fewer failed builds thanks to smoke testing.

Higher product confidence measured through surveys.

Increased change velocity as teams overcome fear of change.

Fewer defects such as 404 errors and unhandled exceptions.

Lowered complexity.

Higher defect‑fix rates.

Measurable improvements

Teams participating in the program can observe improvements such as fewer emergency releases, reduced build failures, increased product confidence, higher change rates, fewer broken functionalities, reduced complexity, and higher defect‑fix rates.

Test Certification Standards (Five Levels)

Level 1

Set up test coverage bundles.

Set up a continuous build.

Classify tests as Small, Medium, and Large.

Identify nondeterministic tests.

Create a smoke test suite.

Level 2

No releases with red tests.

Require smoke test suite to pass before submit.

Incremental coverage by all tests ≥ 50%.

Incremental coverage by small tests ≥ 10%.

At least one feature tested by an integration test.

Level 3

Require tests for all non‑trivial changes.

Incremental coverage by small tests ≥ 50%.

New significant features are tested by integration tests.

Level 4

Automate running of smoke tests before submitting new code.

Smoke tests should take less than 30 minutes.

No nondeterministic tests.

Total test coverage ≥ 40%.

Test coverage from small tests alone ≥ 25%.

All significant features are tested by integration tests.

Level 5

Add a test for each non‑trivial bug fix.

Actively use available analysis tools.

Total test coverage ≥ 60%.

Test coverage from small tests alone ≥ 40%.

Why was Test Certified retired?

Teams had already adopted testing habits.

The static standard lost motivation after levels were achieved, and some projects regressed.

Most projects stopped progressing after reaching level 3.

Project Health emerged as a fully automated, dynamic (daily) health assessment covering the entire lifecycle—from development and testing to release and deployment.

Reference: https://mike-bland.com/2011/10/18/test-certified.html