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.
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.
Start with the lifecycle, not the test team
How the organization builds software shapes every testing decision that follows. Discovery begins there.
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.
Peer-level stakeholders carry the real information
Their history with testing — the wins, the disappointments, the conflicts — will shape whether your process improvements stick.
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
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
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
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
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
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.
We keep this library free. All we ask is that you tell us who you are, so we know who to follow up with if we release an updated version. One-time form, this browser remembers you after that.
Related in the library
Pair this with.
Need a QA program to back this up in your organization?
If a checklist is not enough and you want help applying it to a live engagement, we can have a call this week.
Related reading
Articles, talks, guides, and case studies tagged for the same audience.
- Whitepaper
Evaluation Before Shipping: How to Test an AI Application Before It Hits Production
The release-gate playbook for AI features. Covers the five evaluation dimensions, how to build a lean golden set, where LLM-as-judge is trustworthy and where it lies, rollout mechanics with named exit criteria, and the regression suite that keeps a shipped AI feature from quietly rotting in production.
Read → - Whitepaper
Choosing the Right Model (and Knowing When to Switch)
A practical framework for matching LLM model tier to task. Covers the four axes (capability, latency, cost, reliability), cascade routing patterns that cut cost 60 to 80 percent without measurable quality loss, switching costs you did not plan for, and the worked economics at 10K, 100K, and 1M decisions per day.
Read → - Whitepaper
Beyond ISTQB: A Multi-Domain Certification Roadmap for Technical L&D
Most engineering L&D programs over-index on a single certification family, usually ISTQB on the QA side, AWS on the infrastructure side, and under-invest across the rest of the technical domains the org actually needs. This paper covers a multi-domain certification roadmap (QA, AI, cloud, data, security, project management, software engineering) with sequencing logic for each level of the engineering ladder, plus the maintenance discipline that keeps the roadmap relevant as the technology shifts underneath it.
Read → - Guide
The ISTQB Advanced Level path, mapped
The Advanced Level landscape keeps changing — CTAL-TA v4.0 shipped May 2025, CTAL-TM is on v3.0, CTAL-TAE is on v2.0. This guide maps all four core modules, prerequisites, exam formats, sunset dates, and which module a given role should take first. Links directly to the authoritative istqb.org syllabi.
Read → - Whitepaper
Bug Triage: A Cross-Functional Framework for Deciding Which Defects to Fix
Bug triage is the cross-functional decision process that converts raw defect reports into prioritized action. Done well, it optimizes limited engineering capacity against risk; done poorly, it becomes a backlog-management ritual that neither fixes the important defects nor drops the unimportant ones. This whitepaper covers the triage process, the participants, the six action outcomes, the four decision factors, and the governance disciplines that keep triage effective in continuous-delivery environments.
Read → - Whitepaper
Building Quality In: What Engineering Organizations Do from Day One
Testing at the end builds confidence, but the most efficient quality assurance is building the system the right way from day one. This whitepaper covers the upstream disciplines — requirements clarity, lifecycle selection, per-unit programmer practices, and continuous integration — that make system-level testing cheap and fast rather than the only thing holding a release together.
Read →
Where this leads
- Service · Quality engineering
Software Quality & Security
Independent test programs, security testing, and quality engineering for systems where defects cost real money.
Learn more → - Solution
Risk Reduction & Clear Decisions
Quality programs and decision frameworks that shift risk discussions from anecdote to evidence.
Learn more → - Solution
Reliable Software at Scale
Quality engineering programs for organizations whose software is now operationally critical.
Learn more →