Testing

Testing is the practice of building confidence into your software. It's how you prove that code works, how you catch problems before users do, and how you create a safety net that lets teams move fast without breaking things. Good tests don't just validate behavior—they document intent, prevent regressions, and enable fearless refactoring.

What follows traces the arc of how engineers grow in their relationship to testing. It begins with awareness and exposure—learning that testing is a key part of building reliable software. It evolves through writing your own tests, shaping team testing practices, scaling quality across organizations, and ultimately defining how an entire company thinks about confidence and risk. At every stage, the core question remains: how do we know this works?

Early Career

At this stage, you're beginning to learn that testing is a key part of building reliable software. You may not write tests yet, or you rely heavily on others to tell you what kind of test is needed. Your primary focus is still on getting the feature or fix to work, but you're starting to understand the role of tests in making sure it stays working.

This is about awareness and exposure—seeing how and where testing fits into the workflow. You're building the foundation that will support more sophisticated testing practices later.

What This Looks Like

Engineers at this stage manually test code by clicking through the UI or checking console output. You run the test suite but may not fully understand the failures when they occur. You rely on teammates to write or suggest tests, and you're starting to understand the difference between types of tests—unit, integration, and so on. You may copy existing tests with minor modifications, which is a reasonable way to learn the patterns.

The common struggles are natural at this stage. You might not write tests unless explicitly asked, or you may not know how to start writing a test from scratch. You might be unsure how to validate correctness beyond basic functionality, and you may not run the test suite regularly or interpret results accurately when you do.

The Shift

The fundamental shift at this stage moves from "Testing is extra work" to "Testing is how I make sure my code keeps working." This reframe is crucial. Tests aren't overhead—they're the mechanism by which you earn confidence in your changes and trust from your teammates. When you internalize this, testing stops feeling like a tax and starts feeling like protection.

You'll know the shift is taking hold when you know how to run the tests and check that your code doesn't break them, when you're aware of the team's expectations around testing, when you ask for help when you're unsure how to test something, and when you manually validate your own work before pushing changes.

How to Grow

Start by asking yourself key questions. What's the most important thing that could break here? Is this tested elsewhere, or do I need to add something? What would give me confidence this is working tomorrow? These questions help you develop testing instincts.

Build habits that reinforce testing awareness. Run the test suite before and after changes—make it automatic. Start reading and understanding tests for features you work on. Try modifying existing tests to see how they work. Ask teammates to walk you through a test or test strategy. Write a small unit test with help, add an assertion to an existing test, or read a failing test and trace it to the problem.

You'll know you're ready to move to the next stage when you run tests regularly and understand the results, when you begin to write simple tests with guidance, and when you ask about test coverage or test plans.

At this stage, you're building the habits and curiosity that testing requires. You don't have to write tests perfectly yet—just begin seeing where they fit.

Mid-Level Engineer

As a mid-level engineer, you write basic tests without being asked. You understand that testing isn't separate from your work—it's part of how your work gets done. You begin to think about what could break and how to prove it won't.

You may still need help choosing the right type of test or understanding edge cases, but you now include tests as part of most changes. Testing has become integrated into your development rhythm.

What This Looks Like

You write unit or integration tests for the features you build. You think about happy and sad paths when implementing new code. You check coverage reports or test results as part of your daily workflow, and you fix broken tests you didn't write—because you understand that test health is everyone's responsibility. You read and reuse existing test patterns in the codebase.

The struggles at this stage involve balance and judgment. You may write overly complex or brittle tests that break with small changes. You might miss key edge cases or failure conditions. You may be unsure how to test UI interactions, async flows, or side effects. You might focus too much on testing implementation details rather than behavior—a common pitfall that leads to tests that break when code is refactored even though behavior hasn't changed.

The Shift

The shift at this stage moves from "I write tests for my code" to "I write tests that help the team move faster and safer." This is about purpose. Tests aren't just about proving your code works—they're about enabling confidence for everyone who touches the code after you. Good tests make the whole team more productive.

You're succeeding when you write clear, passing tests for most of your changes, when you proactively ask what needs to be tested and what doesn't, when you catch regressions early through test failures, and when you fix flaky or failing tests when you encounter them.

How to Grow

Ask yourself regularly: does this test actually verify the behavior we care about? Would this test failure help us quickly debug a real issue? Is this test helping reduce risk—or just adding noise? These questions sharpen your testing judgment.

Build habits that improve your testing craft. Use AI tools to suggest test cases and edge cases you might miss—but always evaluate whether the suggestions reflect real user scenarios, not just mechanical variations. Review others' tests to learn patterns and styles. Refactor tests to reduce duplication or improve clarity. Use test names and structure to explain intent. Delete or fix brittle, misleading, or unused tests. Add tests during refactors or bug fixes, not just features. Write test-first for a small component or utility. Pair with someone to improve test design or coverage.

You'll know you're ready to move to the next stage when your tests catch issues before others do, when you simplify or stabilize flaky tests on your own, and when others rely on your tests to understand behavior.

At this stage, testing is part of your professional rhythm. You no longer think of it as extra work—it's just how you build resilient, trustworthy software.

Senior Engineer

As a senior engineer, testing is a core part of how you design and deliver software. You write tests with intent and clarity, balancing speed, coverage, and maintainability. You consider the risk profile of your code and tailor your tests accordingly.

You also help shape the team's overall testing approach. Your tests help others understand the system and prevent regressions. You're becoming a testing leader, not just a testing practitioner.

What This Looks Like

You design tests that document and validate behavior clearly. You write efficient, meaningful tests that run fast and fail informatively. You lead by example in test-first or test-guided development, and you improve test design and structure across the codebase. You encourage teammates to test earlier and more effectively.

The challenges at this stage involve trade-offs and influence. You may overinvest in testing low-risk code while underinvesting in high-risk areas. You might struggle to balance test confidence with developer velocity—more tests aren't always better. You can become overly opinionated about tools or frameworks, missing that different contexts may call for different approaches.

The Shift

The shift at this stage moves from "I write good tests" to "I enable better testing across teams and systems." Your focus expands from your own testing practices to raising the testing capability of everyone around you. You start thinking about leverage—where can you invest effort that will multiply the testing quality others produce?

You're succeeding when you write tests that others trust and rely on, when you refactor tests with the same care as production code, when you improve the test suite's coverage, readability, and reliability, and when you provide feedback that helps teammates test more effectively.

How to Grow

Ask yourself regularly: where are our test gaps or blind spots? Are our tests helping us move fast—or slowing us down? How can I improve testability across the stack? These questions lead to strategic testing improvements.

Build habits that scale your testing impact. Review and maintain testing infrastructure. Advocate for testability in system and API design. Create documentation, patterns, or training to support quality testing. Lead the test strategy for a new feature or service. Migrate flaky or outdated tests to more effective patterns. Improve test reliability in CI/CD workflows.

You're ready for the next stage when other engineers model your testing practices, when your tests reduce incidents and speed up debugging, and when you shape the team's culture and standards around testing.

At this stage, your testing creates leverage—for you, your team, and the business. You bring focus, clarity, and resilience to the development process.

Staff Engineer

As a staff engineer, you scale good testing practices across teams. You proactively identify where testing is failing the organization—whether through gaps, flakiness, confusion, or lack of tooling—and drive change.

You shape the culture of testing, not just the coverage. Your impact is felt in how confidently teams ship, how quickly they debug, and how easily new engineers get up to speed.

What This Looks Like

You lead initiatives to improve test tooling, infrastructure, or conventions—including evaluating how AI tools can assist with test generation, flakiness diagnosis, and coverage analysis while keeping humans accountable for test quality and intent. You introduce patterns that increase speed, clarity, and coverage. You help teams reduce flakiness, duplication, or redundant test cases. You bring test strategy into planning and design reviews, and you mentor others on writing meaningful, maintainable tests.

The challenges at this stage are organizational. You may struggle to influence teams without formal authority—testing improvements often require buy-in across boundaries. You can overstandardize or push tools that don't fit all contexts. You risk investing heavily in testing infrastructure with unclear ownership, leading to solutions that don't get maintained.

The Shift

The shift at this stage moves from "I improve test practices across teams" to "I shape how the company thinks about risk and quality." You're no longer just improving tests—you're reshaping how the organization builds confidence into its software.

You're succeeding when you improve reliability and confidence across teams through better testing, when you help the organization reduce the cost and confusion of test maintenance, when you enable faster feedback loops and earlier defect detection, and when you scale a testing culture that prioritizes simplicity and value.

How to Grow

Ask yourself regularly: where is testing slowing us down—or not protecting us? How can we reduce the cost of poor test decisions? What would a culture of high-confidence delivery look like here? These questions drive strategic testing initiatives.

Build habits that institutionalize testing quality. Promote holistic test strategies that span unit to production checks. Partner with stakeholders to align on risk and quality trade-offs. Evolve standards and infrastructure to keep pace with scale. Run cross-team test health audits or retrospectives. Create resources that clarify when and how to test effectively. Help align deployment gates or rollback policies with real-world coverage.

You're ready for the final stage when teams improve test effectiveness with your input, when your test strategies shape release plans and architectural decisions, and when others cite your examples or tooling when testing is discussed.

At this stage, your testing impact goes beyond code. You remove pain points, sharpen priorities, and help teams move faster with confidence.

Principal Engineer

As a principal engineer, you influence how an entire engineering organization approaches quality and confidence. You don't just write or guide tests—you shape mindsets, standards, and systems that enable thousands of confident changes per day.

You lead cross-functional efforts to balance speed, safety, and simplicity at scale. Testing becomes a strategic capability that differentiates your organization.

What This Looks Like

You define org-wide testing strategies aligned with product and risk profiles. You advocate for and deliver quality initiatives with executive buy-in. You connect test strategy to uptime, velocity, and customer satisfaction—making the business case for testing investments. You establish durable systems for test governance and review, and you develop or sponsor internal tooling that makes testing easier and faster.

The challenges at this stage are about balance and alignment. You're balancing ideal strategy with practical team capacity. You're navigating cross-org alignment and competing priorities. You're avoiding complexity or overreach in frameworks and tools that could become burdens rather than enablers.

The Shift

The final shift moves from "I shape how the company thinks about risk and quality" to "I create systems where confident delivery is the default." You're building an environment where testing excellence emerges naturally from the tools, processes, and culture you've helped establish.

You're succeeding when you make high-confidence development and deployment a competitive advantage, when you shape how teams think about reliability and quality at every career stage, when you lead initiatives that measurably reduce incidents and increase trust, and when you create scalable systems where quality happens by default.

How to Grow

Ask yourself the biggest questions: do teams feel confident in what they ship—and why? Where do our quality efforts feel misaligned with real pain? What tools or guidance would make it easier to do the right thing?

Build habits that create lasting change. Maintain close feedback loops with teams doing the work. Turn war stories into playbooks, docs, and onboarding tools. Capture test strategy in product development processes. Launch company-wide confidence and rollback strategy. Sponsor tool development that embeds quality into everyday workflows. Mentor senior leaders on test prioritization and technical debt.

At this stage, growth means deepening your mastery—becoming more effective at connecting testing to business outcomes, more skilled at building systems that sustain themselves, more influential in shaping how the industry thinks about software quality. Your work is referenced in launch planning, postmortems, and goals. Teams adopt your testing philosophy without needing your involvement. Engineering leaders use your language to talk about quality trade-offs.

At this stage, you lead through trust, strategy, and systems thinking. You help an entire organization deliver with confidence—because you made quality scalable, intuitive, and core to how the company works.