Iterative Agile Testing

Iterative models of software development evolved to address issues raised by both waterfall and spiral approaches, with the goal of breaking large monolithic development projects into smaller, more easily managed iterations. Each iteration would produce a tangible deliverable (typically some executable element of the system under development).

The Objectory method [7] provides a good example of such an approach.In 1987, while assisting telecommunications company Ericsson AB with its software development efforts, and concerned with the shortcomings of earlier methods, Ivar Jacobson brought together a number of the development concepts he had been thinking about,such as use cases [8],object-oriented design[9], and iterative development,to create a new approach to developing successful object-oriented applications. The Objectory method supported innovative techniques for requirements analysis, visual modeling of the domain, and an iterative approach to managing the execution of the project.In essence, Objectory would break down a project that might have been run in a large and inflexible waterfall manner into smaller,more easily understood, implemented,and tested iterations.Such an approach brought a number of important benefits for software quality:

  • Testing could begin much earlier in the project(from the first iteration), enabling defects to be identified and fixed in a timely manner, with the result that timescales were not impacted,and that the effort and cost of fixing and retestingdefects were kept low.1
  • Testing would continue throughout the project (within each iteration), ensuring that new defects were found and fixed in a timely manner, that newly added system functionality did not adversely affect the existing software quality, and verifying that defects found in earlier iterations did not reappear in the most recent iteration.
  • The valuable visual metaphor provided by use cases and visual modeling enabled the developers and the customer to more easily understand the intention of the system functionality – in effect the customer, analyst, designer and tester share a common language and understanding of the system.
  • Testers discovered that the scenarios described by the use cases could very easily be used to design and implement effective test cases 2– the actors(people or other systems) identified in the use cases and their interactions with the system under development, mapped easily onto the steps and verifications needed to develop the test scripts.

The Objectory process was organized around three phases:

  1. The requirements phase – which involves the construction of three models that describe in a simple, natural-language manner what the system should do:
    • The use case model – which documents the interactions between the actors and the system, which are typically captured using use case diagrams and natural-language descriptions.
    • The domain model – which documents the entities within the system,their properties, and their relationships.
  2. It is generally considered that for each phase of the project during which you fail to find a bug, the cost of fixing it increases by a factor of 10 [4]. In practice, my experience is that this is a conservative estimate.
  3. A test case represents the design for a test. A test case is implemented by means of a test script.
  4. The user interface descriptions – which document the various interfaces between the actors and the system.
  5. The analysis phase – which involves the construction of two models that are a refinement of the information captured during the previous phase:
    • The analysis model – which is a refinement of the domain model produced in the previous phase and which documents behavioral information, control objects(linked to use cases),and entity and interface objects.
    • The subsystem descriptions – which partition the system around closely coupled and similarly behaving objects.
    • The construction phase – which refines the models produced in the analysis phase. During this phase the following models are generated:
    • Block models – which represent the functional modules of the system.
    • Block interfaces – which specify the public operations performed by the modules.
    • Block specifications – which are optional descriptions of block behavior using finite state machines [10].

In its time, Objectory was considered to be a very successful software development method,and many of its key principles, such as use case analysis and design, continue to be widely used today.In 1991, after having worked closely with the Objectory process for several years, Ericsson AB purchased a major stake in Ivar Jacobson’s company(Objectory Systems), changing its name to Objectory AB.

In 1995,Objectory AB merged with the Rational Software Corporation, and shortly thereafter,the Rational Objectory Process version 4.0 was published, which incorporated elements of Grady Booch’s object-oriented analysis and design method[11]and Jim Rumbaugh’s object modeling technique(OMT [12]).Much of the procedural side of the Objectory method (such as use case modeling)was incorporated into the Rational Objectory Process, with the addition of many notational and diagramming elements from the OMT and Booch methods.

Ultimately, through an incremental process of extension and enhancement, the Rational Objectory Process evolved into the Rational Unified Process(RUP)version 5.0,which incorporated modeling and design extensions addressing business engineering, plus best practice guidance on configuration and change management, data engineering,and user interface design. The release of version 7 of RUP provides extensive best-practice guidance on traditional and agile software development and testing methods, such as the ability to optionally select an “extreme programming” style of development, as well as the means of customizing the RUP framework to support the user’s own specific agile approaches.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics