Special Issue "Agile Practices"

Guest Editor
Dr. David Parsons
Technology Institute of Information and Mathematical Sciences Albany Campus, Massey University Private Bag 102-904 North Shore Mail Centre Auckland, New Zealand
Website: http://www.massey.ac.nz/~dpparson/
E-Mail: d.p.parsons@massey.ac.nz
Phone: +64 (0)9 414 0800 ext. 9138
Fax: +64 (0)9 441 8181
Interests: mobile and blended technology enhanced learning; agile and test driven software development; virtual world learning; web technologies

Dear Colleagues,

2011 sees the 10^th anniversary of the Manifesto for Agile Software Development. During that decade, agile practices have moved firmly into the mainstream, but there are still many questions to be answered and many innovations to be explored. The agile approach to information systems building encompasses many different activities and artefacts, including project management, software development tools and techniques and organisational re-engineering, and these aspects interact in complex and challenging ways. The popularity of hybrid approaches to agile development, for example the common pairing of Scrum and XP, raises questions about the similarities an differences between various agile methods, and the consequences of choosing particular methods, techniques, and combinations of these.  Practitioners and researchers view agile methods from many different perspectives, including management, testing, team dynamics and architecture, amongst many others. We continue to find new ways to practice agile development, for example with non iterative management approaches like Kanban  (revisiting the roots of agile in lean manufacturing), innovative test tools such as Infinitest, and efforts to scale agile into ever more complex and large scale systems development.

The special issue takes as its theme the challenges and opportunities of the second decade of the agile manifesto.  Now that agile practices are widespread, we have the opportunity to gather large scale, longitudinal empirical data, and to reflect and build on previous research and practice. There is already a long tradition of international conferences that have revealed the work of the agile community, for example the Agile series, presented by the Agile Alliance and with a strong industry flavour, and the XP series, which tends to encompass both industry and academia.  There are also a number of journals, both commercial and academic, that have published material related to agile development. This gives us a rich background of research and experience literature from which to build new ideas, theories and studies that can take our understanding of agile forward and increase the effectiveness of agile practices as we move into the next decade of the agile age.

Dr. David Parsons
Guest Editor

Submission

Manuscripts should be submitted online at www.mdpi.com by registering and logging in to this website. Once you are registered, click here to go to the submission form. Manuscripts can be submitted until the deadline. Papers will be published continuously (as soon as accepted) and will be listed together on the special issue website. Research articles, review articles as well as communications are invited. For planned papers, a title and short abstract (about 100 words) can be sent to the Editorial Office for announcement on this website.

Submitted manuscripts should not have been published previously, nor be under consideration for publication elsewhere (except conference proceedings papers). All manuscripts are refereed through a peer-review process. A guide for authors and other relevant information for submission of manuscripts is available on the Instructions for Authors page. Future Internet is an international peer-reviewed Open Access quarterly journal published by MDPI.

Please visit the Instructions for Authors page before submitting a manuscript. The Article Processing Charge (APC) for publication in this open access journal is 300 CHF (Swiss Francs). English correction and/or formatting fees of 250 CHF (Swiss Francs) will be charged in certain cases for those articles accepted for publication that require extensive additional formatting and/or English corrections.

• agile software development
• agile teams and environments
• agile methods (Scrum, Kanban, Lean, XP, FDD, Crystal etc.)
• agile techniques  (pair programming, continuous integration, test driven development, information radiators etc.)
• automated software testing
• agile project management (techniques, tools, metrics etc.)
• large and/or distributed agile implementation
• agile organisations
• user stories and story mapping

Title: Evolving Web-Based Test Automation into Agile Business Specifications
Authors: Rick Mugridge ¹, Mark Utting and David Streader
Affiliations: ¹ Rimu Research
² University of Waikato
Abstract: Not surprisingly, a common approach to test automation of web applications is based on the way that manual testing is carried out. Test scripts mirror the actions in the browser that the tester carries out to verify that a system under test is correct. Such scripts are either hand-written or are recorded with record-and-playback tools.
Unfortunately, there are several serious problems with test scripts that are expressed in terms of the implementation, as well as a significant lost opportunity. Such scripts tend to be low-level, verbose, and repetitive. They are not effective in an agile setting, as they tend to be written after development. They tend to be slow to execute. They prove to be expensive to create and maintain. Sometimes, small changes to a system can have a major impact on the tests. This has led some teams to abandon test automation as a bad idea. Other teams may try to avoid these problems by rewriting tests at a higher level, but, with large test suites, making such changes can be expensive and error-prone.
An alternative approach is to start with the goal of creating business-level specifications based on meaningful examples, and then provide a convenient way to map those into the implementation level for automatic verification (possibly through several interfaces). In this way, the specifications serve a dual purpose. They specify business rules, constraints, and processes, which help with a wider communication of the business level. They aid in discussing changes in an agile/lean process before implementation. They also provide the means of ensuring consistency with the system, so we know that they can be trusted.
Our research has focussed on providing tool-support for creating business-level specifications, using two main approaches. First, we provide support for the evolution of existing implementation-level tests into business-level specifications. This is akin to Extract Method refactoring with code. The tool rapidly searches for repetition across a test suite and proposes abstractions, with parameters, based on the compression that can be obtained. The user selects and alters these, to be applied automatically to the suite. Step-by-step, a knowledgeable person extracts out the business level from a large suite. At the same time the tests are compressed into concise and focussed specifications.
We also provide a variation of the record-and-playback approach. By introducing an abstraction step into the process, we retain the benefits of this approach, but avoid the problem of low-level verbosity. Abstractions can either be applied to a few tests that have already been recorded, based on the patterns of repetition, or they can be designed upfront and used in recordings. With web applications, it's useful to build this up from layers at the field/element, page, scenario, and business levels. In this way, someone who is knowledgeable about the business domain can build business-level specifications from using the system and so are known to be consistent with it.
In addition, we provide feedback on coverage in business rule tables, suggesting possible additions. We also support the automatic generation of user-level documentation from specifications, including screen dumps at appropriate places. This drastically reduces the effort involved in maintaining example-based documentation, and ensures that it is kept up to date with the system.

Title: Test Driven Development: Advancing Knowledge by Confirmation
Authors: David Parsons¹, Manfred Lange² and Ramesh Lal¹
Affiliations: ¹ Massey University
² Prism Software
Abstract: Traditional methods of software testing have followed a philosophy that can be equated to Poppers’ concepts of conjecture and falsification in the advancement of knowledge. In this model of testing the proposed solution to a programming problem is a conjecture, and the post hoc tests are (potential) falsification. Knowledge of the system advances by a series of conjectures and falsifications, but the conjectures can only be proved to be false if the appropriate tests happen to exist. The philosophy of Test Driven Development is somewhat different. It shifts the process such that the test cases come before the proposed solution, so that the tests themselves, rather than the units under test, become the conjecture. This has the effect of redirecting the emphasis from the somewhat negative falsification to the more positive confirmation. In other words, post hoc testing emphasizes the negative desire to break the proposed solution, whereas test driven development emphasizes the positive desire to implement a solution that passes the test. From a philosophical perspective, this supports the contention that the tests in a test driven approach are qualitatively different than those written during post hoc testing. From a more practical perspective, this provides us with a new interpretation of how knowledge advances, by describing tests directly from requirements, and systems directly from tests. This step can be seen as literal if requirements are expressed as customer acceptance tests embodied in automated testing tools.
In this article, based on interviews carried out during a longitudinal case study, we explore the experiences of an agile project team, and investigate how test driven development and its supporting practices are applied within well-defined team dynamics. Our study suggests the contributions to software quality of the test driven approach in advancing knowledge by confirmation rather than falsification.