Process · Context Discovery

Learn the ground before you move it.Five steps for arriving at a new testing organization.

The first thing a test leader should do at a new organization is understand the context. These five steps keep you from proposing the wrong solution because you misread the problem.

Steps
5
Time per pass
1–3 weeks
Best used
At arrival
Context is the single most important variable in any testing decision. Assume nothing; discover everything that matters before you write one plan.

Key takeaways

Four things to remember.

  1. 01

    Start with the lifecycle, not the test team

    How the organization builds software shapes every testing decision that follows. Discovery begins there.

  2. 02

    Read what already exists

    Test plans, bug databases, and field failure data tell you who made which decisions, why they made them, and what forces were at play.

  3. 03

    Peer-level stakeholders carry the real information

    Their history with testing (the wins, the disappointments, the conflicts) will shape whether your process improvements stick.

  4. 04

    Clarify quality assurance vs. testing expectations

    Senior managers often blur the two. Surface the distinction explicitly, in their words, before you scope your role.

Why this exists

The problem this process fixes.

Almost every testing failure we unwind traces back to a test leader prescribing before diagnosing. Strategies fail, not because the strategy was wrong in the abstract, but because it ignored the organization it was applied to.

This five-step process exists to prevent that. Work through it in the first weeks of an engagement; repeat it at a lower cadence when the organization changes.

The checklist

5 steps, in order.

  1. 1

    Understand the lifecycle process(es) used in your organization for system development, maintenance, or acquisition, including any planned or on-going process improvement initiatives.

  2. 2

    Study whatever testing, test-related and quality-related documentation, data and metrics exist, such as test plans, bug reporting databases, field failure data, test systems, and so forth. Understand who created these items, why they did so, why they did it the way they did it, and what was going on in the organization that led to all those decisions and forces that influenced the outcomes.

  3. 3

    Discuss with other participants what testing activities they're doing, and what they'll continue to do now that you're on the scene.

  4. 4

    Identify your peer-level stakeholders in the testing process. Talk with them to understand their current relationships with the people doing testing now, their expectations of how testing can add value, past disappointments or conflicts with the testing process or people involved in testing, and so forth.

  5. 5

    Clarify with your managers and other senior managers what value they expect the test team to add, and especially to what extent your role involves quality assurance as distinct from testing.

One more thing

Discovery is never one and done. As the organization changes, so does the context, and a strategy that fit the old context will undermine the new one. Revisit these five steps whenever something large changes around you.

Take it with you

Download the piece you just read.

The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.

In the library

Pair this with.

Keep reading

Related reading

Practices

Where this leads

Working on something like this?Talk to the people who wrote it.

Book a call