Forewarned is forearmed!

Forewarned is forearmed!

Testing is an important set of tools for influencing the quality of the functionality that gets delivered. The term testing can cover a wide range of activities ranging from reviews to user acceptance testing with a nearly infinite number of stops in between. Some organizations expend up to 60 – 70% of project effort just on testing (this is abnormally high), often with the intention of “testing in” quality. When the effectiveness and efficiency of testing has been derailed there are five typical root causes.

  • Planning
  • Involvement
  • Organizational Management
  • Capability
  • Process

Planning is the first of the root causes. Poor planning will yield poor results. Test planning defines the approach a project will use to verify and validate the deliverable they are creating. There are several inputs that impact and shape a test plan. The inputs are:

  1. Risk – Risk is a reflection of possibilities that might impact the project if they occur. Some projects will inherently have a bigger impact on the organization if things go wrong. Testing can be tuned to act as insurance that risks do not become issues. Agile projects use a wide range of techniques to incorporate risk into how testing is approached. Planning techniques include release planning, sprint planning, tools like the definition of done, techniques such as test first development (including test driven development) or classic test planning documentation.
  2. Test Goals – Test goals reflect an organization’s business strategy and needs. Test goals can be as simple as ensuring software is defect free (this is not only simple, but a simplistic) to improving the product’s delivered quality (as compared to a standard or a baseline).
  3. Test Policy – A policy defines a course of action that supports a long-term purpose. A test policy describes the type of behavior without defining the ends, means or approach. Good policies are aligned with the business strategy and the test goals. Test policies must be agreed upon (at least passively) by all of the stakeholders.  Policies that the involved parties don’t agree with will potentially generate poor behavior as stakeholders struggle against what they perceive as artificial constraints. For example a policy that requires all applications to be stress tested even if they are standalone, one person applications will not be perceived as fitting the environment.  The policy will be ignored when practitioners don’t think it applies which opens the door for failure if something is not stress tested that should be.
  4. Test Strategy – At an organizational level, a test strategy represents a broad outline that will orperationalize the test policy.At a project level, a test strategy will define the how the project will conform to the test policy and meet the test goals. The strategy operationalizes the testing goals and policies based on the business and project risks.

The typical image painted when discussing test planning is an omnibus document that defines how a project will approach testing, sometimes in mind-numbing detail. While that level of detail might be important in some scenarios, in most Agile projects the adoption of standard techniques provides the policy, strategy and guidance to ensure a good test planning. Agile techniques that improve planning include:

  1. Well-formed user stories (including acceptance criteria),
  2. Test first development (such as test driven development or acceptance test driven development), and
  3. A solid definition of done.

Planning is requirement for any activity development activity, testing included.  Good planning is a requirement for good testing.