Other Agile Methods - Agile Testing

This section provides a high-level overview of the key features of a number of other agile methods and approaches to software development and testing. By necessity, this is only a snapshot of the current popular methods and does not seek to be a comprehensive catalog of all agile approaches. Because this subject evolves so quickly, it is recommended that the reader also refer to as a useful source of updates on agile methods.

The Enterprise Agile Process(formerly XBreed)
Developed by Mike Beedle with the goal of developing “reusable software in record time, ” this twenty-first-century agile approach combines a number of best practices from other agile methods, such as XP and Scrum. Specifically, EAP employs best practices from Scrum as the basis of its management framework and incorporates a subset of XP techniques for its development process.

A key feature of the method is the use of design patterns to create reusable objects; EAP creates a library of components that can be easily reused in new software projects to save time, effort and cost of development and testing, while improving quality by the reuse of “tried and tested” components.

The EAP development process promotes the use of well-trained, skilled and experienced practitioners to populate its teams,and encourages the use of effective knowledge transfer between team members, which, combined with a low communication overhead, helps keep the project running smoothly and efficiently.

Ruby on Rails
Created by David Heinemeier Hansson from his earlier work on the Basecamp webbased project management tool, Ruby on Rails (RoR )is an open-source web framework that is optimized for“programmer happiness and sustainable productivity.” Typically used by developers for relatively short client-driven web development, and often referred to as “Rails,” RoR use is guided by two key principles:

  • Convention over configuration (CoC) – In effect development by exception,the benefit of CoC is that only the unconventional aspects of the application need to be specified by the developer, resulting in reductions in coding effort. For example, if the developer creates a class “Part” in the model, the underlying database table is called “Parts” by default. It is only if one deviates from this convention,such as calling the table “parts_on_hand,” that specific code needs to be written that utilizes these names.
  • Don’t repeat yourself – RoR promotes an approach where information is located in a single, unambiguous place.For example,using the ActiveRecord module of RoR, the developer does not need to explicitly specify database column names in class definitions. Instead, RoR can retrieve this information from the database. Using the model-view-controller architecture for organizing application
    programming, RoRincorporates a number of tools:
  • scaffolding, for simplifying the generation of basic Web site models and views;
  • WEBrick,a simple RoR web server; and
  • Rake, a simple build system.

By providing these tools combined with an agile development philosophy,RoR can be seen as an example of highly agile integrated development environment.

First released to the public in July 2004, RoR continues to find supporters in the web developer community with an impressive list of adopters(since2007 RoR has been shipped by Apple with MacOS X v10.5 Leopard, for example).

Evolutionary Project Management
Developed by Tom and Kai Gilb, Evolutionary Project Management(Evo)is a twenty-first-century agile project management method whose focus is on earlier delivery of critical results and on-time delivery of deadlined results. Evo is claimed to be able to provide more control over software quality, project performance, and project costs than more traditional project management methods.

Evo is particularly suited to developing large-scale software systems, involving complex technology and in rapidly moving environments. Evo aims to be highly responsive and adaptable to unforeseen circumstances while delivering rapid results. Evo follows ten key process principles:3

  1. Real results, of value to real stakeholders,will be delivered early and frequently.
  2. The next Evo delivery step must be the one that delivers the most stakeholder value possible at that time.
  3. Evo steps deliver the specified requirements, evolutionarily.
  4. It is impossible to know all the right requirements in advance, but it is possible to discover them more quickly by attempts to deliver real value to real stakeholders.
  5. Evo is holistic systems engineering; all necessary aspects of the system must be complete and correct,and delivered to a real stakeholder environment. It is not only about programming, it is about customer satisfaction.
  6. Evo projects will require an open architecture,because project ideas will change as often as needed to really deliver value to the stakeholders.
  7. The Evo project team focuses their energy,as a team,toward success in the current Evo step.They succeed or fail in the current step together.They do not waste energy on downstream steps until they have mastered current steps successfully.
  8. Evo is about learning from hard experience,as fast as possible – what really works and what really delivers value.Evo is a discipline to make teams confront project problems early,but one that delivers progress quickly when provably,the team have got it right.3 Sincere thanks to Tom and Kai Gilb for allowing me to reproduce this information.
  9. Evo leads to early, and on-time,product delivery – both because of selected early priority delivery and because the team learns to get things right early.
  10. Evo should allow teams to validate new work processes and get rid of bad ones early. Benefits cited by Evo users include reducing the duration and cost of requirements capture by 75% over traditional methods, reducing the integration effort to upgrade from a previous code platform to a new code platform from hours to minutes, and improvements in the motivation, enthusiasm and morale of developers and testers, leading to significantly higher staff retention.The success of Evo can also be measured by the number of high-profile users(such as IBM, HP, and Microsoft) that have been involved in learning and using the method.

Rational Unified Process
Originally developed by Ivar Jacobson, Grady Booch,and Jim Rumbaugh at Rational Software Corporation, RUP is a use case–driven iterative software engineering process that employs the Unified ModelingLanguage(UML)notation[33] to incrementally develop and deliver software. RUP provides industry best practice guidance on software development and testing to its users through a web browser interface, allowing the information to be accessed in a simple and easily distributed manner.

The RUP iterations are organized under a number of phases – inception, elaboration, construction, transition and production– with development and testing activities grouped as a series of disciplines that run across the phases.These typically include business modeling, requirements, analysis anddesign, implementation, test, deployment, operations and support, configuration and change management, project management, environment, and infrastructure management.

RUP provides comprehensive information on all aspects of software development,including project roles and responsibilities, project planning and management, tasks and timescales,inputs and outputs, testing techniques and approaches, reusable project templates (such as test plan and test script templates), metrics and guidance on process improvement. RUP explicitly supports agile approaches by providing a customizable metamodel that allows users to select from the RUP best practices to create and maintain their own subset of agile best practices. RUP also provides access to predefined agile customizations, such as its XP process plug-in.

With its early origins in Ivar Jacobson’s 1990s Objectory process, the development of RUP has been a highly inclusive process, and it has drawn from many sources including the experience of major industry experts, special interest groups, industry standards and guidelines, and the experiences of many thousands of ordinary practitioners. Over the years, RUP has spawned a number of other agile methods and initiatives, such as the EssUP and the Object Management Groups SPEM.

The Essential Unified Process
The EssUP is a continued development of the work begun in RUP by process guru Ivar Jacobson,which identifies and promotes the use of a number of essential practices that include use cases,iterative development,architecture-driven design,team practices,and process practices, plus process improvement(through Capability Maturity Model Integration) and agile development.Adoption and use of EssUP are accelerated through the use of a set of “playing cards” - concise ready reference cards documenting the process best practices in a simple and highly accessible manner.EssUP appears to be gaining in popularity and use, with both IBM and Microsoft incorporating its best practices into their respective process product offerings.

The Software Process Engineering Metamodel
SPEM is, as its name suggests, a process metamodel that allows users to develop and maintain their own specific development and testing process.SPEM is administered by the Object Management GroupOMG) and based on the RUP metamodel, which the Rational Corporation donated to OMG for the purpose of supporting the development of a widely available open-source software process engineering metamodel.Employing the UML notation, PEM provides facilities for individual development and testing practitioners to create their own specific development method that incorporates those process elements appropriate to their own particular development needs and requirements.

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

Agile Testing Topics