Contributes to Project Management. Effective testing is a planned activity - it should be a first-class citizen of the project management plans and schedules. Testing needs to be resourced (time, money, staff, tools, etc.) adequately to be effective - testing done at the last-minute, ad hoc, or as an after-thought is unlikely to be effective. The test activities should enable the project manager to have both positive and negative control of the system development. Testing enables the ability to confident promote, package and distribute products - as well as the ability to cull defective components, delay premature deployment and recover from sub-standard craftsmanship. There is a very high, very positive relationship, between the planning/management of the test effort and the ability of a product to meet the target schedule, cost and quality goals.
Stakeholder Participation. Effective testing engages a breadth of stakeholders - business sponsors as well as testing professionals, domain experts as well as technical staff, and senior management as well as individual contributors. Testing engages the stakeholder population when it occurs at several levels of scale from the component level (developers), the interface level (system users) and the system functional level (sponsors and customers). Testing applies the stakeholder resources effectively when it occurs in a number of formats including evaluations of architectural experiments, design reviews, code reviews, analysis by subject matter experts, technical testing by engineers, and demonstrations to customers/sponsors. Stakeholder engagement is effectively applied when it can be re-applied for a manageable incremental cost - defining tests is a creative/engineered/analytical task, execution of the tests should be routinizated/automated task.
Risk Management. Effective testing is structured to reflect the risk characteristics of the project - be that cost, schedule, quality, etc. The testing should be organized to derive the greatest impacts from the resources applied - one of the few certainties in the craft of software engineering is that early testing is nearly always more effective than testing deferred - e.g. catching a bad requirement avoids the time, cost and effort of building the wrong components. Risk management is a discipline of degrees with neither too much, nor too little, being desirable - the test activities should be similarly measured and balanced.
Integration with the Systems Development Activities. Effective testing has a reciprocal relationship with the other system development activities - requirements management, analysis/design, construction, project management, etc. The requirements management discipline should support test cases/scenarios/etc. as a requirements type - with a disciplined change/review process, mechanisms for traceability, etc. Similarly, the test artifacts should explicit trace to and support the requirements - and reflect the requirements attribution for priority, risk, etc. Change management practices (read/write management, check-in/check-out, versioning, etc) should be applied to test artifacts as they are for requirements and software construction artifacts. Similarly, the test artifacts should support the product as it is versioned - e.g. with regression testing, release-assigned test cases, etc.