Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Testing strategy/Implementation Plan

From MoodleDocs
Revision as of 03:02, 13 March 2012 by Tim Barker (talk | contribs) (Created page with "<H1 CLASS="western" STYLE="page-break-before: always">Implementation</H1> <P>Agile testing guru and automation expert Brian Marick coined the term “Hump of Pain” to describe ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Implementation

Agile testing guru and automation expert Brian Marick coined the term “Hump of Pain” to describe the initial phase of implementing test automation. The impact of this hump can be minimised by good planning, good coaching and a strong managerial support for the new processes. As time progresses, particularly as infrastructure becomes implemented, the test cases in the automated suite are completed and the introduced practices become second nature; the hump disappears.

Agile Implementation of Testing Practices

Modifications to the process should be made in an incremental manner based up scrum methodology. A series of 2 weekly sprints will be used to time-box test planning and implementation tasks.

Phase 1: Infrastructure and the Integration Process

The infrastructure to maintain automated testing effort must be implemented. This process will start with the installation of cloud based hardware at Moodle HQ and the setup of VM's to support the required test environments.

The integration process affects quality for the whole organisation as all code must go through the integration process to become 'live'. The processes described above will will be initially implemented at integration. Any changes to the existing processes will take place side-by-side with existing processes to manage risk. i.e. existing processes impacted by changes will be maintained in their current state until implementation of changes becomes stable.

The setup of test environments will initially start with a restricted number of high risk test environments so that the automation process, particularly test cases, can be developed incrementally.