Introduction

My name is Colin Cassidy. I'm a software architect for Prolifics – a systems integration company that specializes in IBM technologies. Coming from a software development background, I have ten years' experience in the IT industry. I have performed a number of roles, including software architect, systems analyst, developer, and development process engineer. This has been mainly in the retail, telecom, and finance sectors.

My interest in software testing stems from a desire to build better software and to find better ways of building that software. Having practiced development and testing on a number of project types ranging from the very agile to the very structured, I have experienced the problems caused by too much automated testing as well as those caused by too little.

This case study describes a Java system integration project that used test-first development and continuous automated regression testing.

Introduction

My name is Dass Chana and I am a computer science student. This case study describes a project I undertook as an industrial placement student working for a very large IT company. I was assigned as a resource to a large distributed team who were responsible for providing technical support to the company's business partners, and tasked with setting up and delivering a Wiki (for internal use within the team) under very challenging timescales, with extremely low budget, and with very few resources.

Introduction

My name is Lucjan Stapp and I work as an Assistant Professor at the Warsaw University of Technology. This case study describes research conducted at the Warsaw University of Technology, Faculty of Mathematics and Information Science, to determine the differences between one group employing an agile testing method and a control group using an ad hoc approach to testing.

Overview of the Testing Challenge

Agile approaches are often proposed as a solution to improving a number of characteristics of the testing process; typical improvements are claimed in speed and cost of testing, but many of these claims are only backed up by qualitative or anecdotal evidence.

This research was conducted to try to quantify the benefits of agile versus ad hoc testing approaches.

Teams and Exercises

To check the cost of using test-driven methodology, we have created two groups with the same knowledge of programming in Java:

• the test group, later called the TDD team (using test-driven development [TDD] methodology), and

• the control group, which, traditionally, does not have unit tests built in.

Both groups have made the same, rather simple applications (about 6 hours of coding for a three-person group).

Introduction

My name is Graham Thomas. I have a range of experience in software development and specifically testing, with formal qualifications in programming, systems analysis and design, and latterly in software testing. Most recently I have been involved as a program test manager looking after high-value testing portfolios of work.

I became involved with agile development and testing methods in the autumn of 2000, when I was working on a project with a small transatlantic software house producing systems for the treasury dealing markets.

This case study looks at my involvement in the project, starting at the point where I realized that traditional testing approaches were not working for an organization that was delivering customized releases combined with a high volume of small changes to an installed client base.

Introduction

The following pages of this appendix contain a test script template (Figure E.1) that may be copied and used within your own testing task or project.

The test script template contains the following sections:

• Project ID – the unique project identifier;

• AUT Name – the definitive name of the Application Under Test (front sheet only);

• AUT Version – the definitive version information for the Application Under Test (front sheet only);

• Iteration ID – the unique identifier for the iteration this test is being conducted in (front sheet only);

• Date of Test – the planned start date of testing (front sheet only);

• Test ID – the unique identifier for the test;

• Purpose of Test – a brief description of the purpose of the test including a reference, where appropriate, to the requirement that is to be tested (consider providing references to the requirements specification, design specification, user guide, operations guide, and/or installation guide), as well as any dependencies from or to other test scripts/test cases;

• Test Environment – a brief description of the environment under which the test is to be conducted (may include a description of the state of the AUT at the start of this test, details regarding the platform or operating system, as well as specific information about data used in this test);

• Test Steps – concise, accurate, and unambiguous instructions describing the precise steps the tester must take to execute the test, including navigation through the AUT as well as any inputs and outputs; and

• Expected Result – a brief and unambiguous description of the expected result of executing the test.

Introduction

My name is Richard Warden and I wrote and tested my first computer program on May 12, 1970. When I worked for the Swiss Exchange in Zurich as a test manager they called me an “Old Rabbit” – a complimentary term, I will add. That was eleven years ago and I have since spent much of my time immersed in UML and agile-related projects within financial services companies.

My career started in the Royal Air Force as an analyst, developer, and tester on large mainframe defence support systems. I then moved to Racal Electronics working first on business systems and then interactive computer-aided design (CAD) systems in positions of programming team leader, test manager, project manager, and head of quality assurance. Following this I worked for the K3 Group as a product and research manager. Since 1991 I have been an independent consultant.

The case histories relate mainly to trading systems and I will give a brief outline of their design rather than a complex architecture picture. There is a trading platform that is usually a client–server design where traders conduct business.

Why Agile?

In today's highly competitive IT business, companies experience massive pressures to be as effective and efficient as possible in developing and delivering successful software solutions. If you don't find strategies to reduce the cost of software development, your competitors will, allowing them to undercut your prices, to offer to develop and deliver products faster, and ultimately to steal business from you.

Often in the past, testing was an afterthought; now it is increasingly seen as the essential activity in software development and delivery. However, poor or ineffective testing can be just as bad as no testing and may cost significant time, effort, and money, but ultimately fail to improve software quality, with the result that your customers are the ones who find and report the defects in your software!

If testing is the right thing to do, how can you ensure that you are doing testing right?

If you ask managers involved in producing software whether they follow industry best practices in their development and testing activities, almost all of them will confidently assure you that they do. The reality is often far less clear; even where a large formal process documenting best development and testing practice has been introduced into an organization, it is very likely that different members of the team will apply their own testing techniques, employ a variety of different documentation (such as their own copies of test plans and test scripts), and use different approaches for assessing and reporting testing progress on different projects.

Introduction

My name is Peter Kingston and at the time of this case study I was working on a contract as a test manager for a financial products company, The Remortgage Corporation (TRC).

My career in IT spans more than twenty-five years, beginning as a software developer before moving into systems analysis and then management. For most of the last decade, I have been a professional software test consultant and have a wide variety of experience of the software testing industry. I have gained much expertise from working as a test analyst, test manager, and test consultant in a variety of industries including finance, retail, government, and petro-chemical. In addition, I am an accredited provider of the ISTQB Foundation Course in Software Testing [42].

Introduction

My name is Tom Gilb and I am an independent testing consultant and author of Competitive Engineering: A Handbook for Systems & Software Engineering Management using Planguage (2005), Principles of Software Engineering Management (1988), and Software Inspection (1993). My book Software Metrics (1976) coined the term and was used as the basis for the Software Engineering Institute Capability Maturity Model Level Four (SEI CMM Level 4 [37]). My most recent interests are development of true software engineering and systems engineering methods.

In 1997 Kai Gilb and I published a book entitled Evo: The Evolutionary Project Management and Product Development Handbook, describing an agile software development and testing project management method [32]. Evo is an iterative method in which a series of small delivery steps are taken until the project goals are reached and the software delivered.

Introduction

Having selected and documented your agile best practices, even the best agile development and testing process is nothing without the acceptance and consistent use by a community of testers within an organization. Technical issues aside, the introduction and adoption of your agile testing process is likely to be the most difficult step in delivering effective and efficient agile testing within your organization.

In some organizations, the roll-out and adoption of agile best practices may not be an issue. For example, if you work in an enlightened company that is already familiar with the benefits agile can provide, it is likely that agile practices are already in the process of being used. Similarly, if your company already has a pressing need to adopt an agile means of working – perhaps to satisfy the terms and conditions of another organization that has asked them to bid for some development work, and who are looking for responses from companies that will employ agile practices – you may not need to evangelize about agile.

If none of the aforementioned applies to your organization, the following sections describe a tried and tested strategy for the introduction, adoption, and ongoing use of your agile process. This chapter also addresses the issues associated with the subsequent maintenance and update of your testing process.

Introduction

This appendix reviews the essential rules and practices of the Rapid Application Development (RAD) agile method, focusing in more detail on the testing aspects of the method.

The guiding principles of RAD are to deliver usable high-quality systems quickly and with low costs. The RAD rules and practices are discussed under the following sections:

• Overview of the Characteristics of RAD Projects,

• Joint Application Design,

• Rapidity of Development, and

• Incremental Prototyping.

Overview of the Characteristics of RAD Projects

RAD seeks to avoid the traditional problems associated with large, monolithic waterfall-style projects by breaking the organization and management of the project tasks into smaller, more easily managed increments.

Historically, RAD projects have been most successful when employed to develop relatively small and simple applications, with low complexity and risk. For larger, more complex applications, such as the implementation of a company-wide customer relationship management (CRM) system, for example, organizations typically looked to more mature software project management and development approaches (such as PRINCE [22]). A number of organizations have had success combining both approaches, with PRINCE used for the overall management of the project and RAD employed to develop the comparatively simple and low-complexity applications that run against (using our preceding example) the CRM system.

Introduction

This appendix reviews the essential rules and practices of Scrum, focusing in more detail on the testing aspects of the method.

The Scrum rules and practices are discussed under the following sections:

• Scrum General Practices,

• Scrum Roles and Responsibilities,

• The Sprint,

• Scrum Meetings, and

• Scrum Artifacts.

Scrum General Practices

• Customers must become a part of the development team; it is essential that the customer is genuinely interested in the success of the project.

• There should be frequent intermediate deliveries with working functionality; this enables the customer to get exposure to working software earlier and enables the project to change its requirements according to changing needs.

• The development team should be alert to project risks and develop appropriate mitigation strategies; valid risk mitigation, monitoring, and management should be actively performed throughout the project.

• Problems, issues, and risks must not be swept under the carpet; no one should be penalized for identifying or highlighting any unforeseen problem.

• There should be transparency in planning and module development; everyone must be aware of who is accountable for what and by when.

• Frequent stakeholder meetings should be held to monitor progress, with dashboard/stakeholders' updates; procedures must be put in place to ensure visibility of potential slippage or deviation in a timely manner to allow it to be corrected.

• […]

Introduction

My name is Nick Denning and at the time of this case study I was the managing director of Strategic Thought Limited, a company I founded in 1987, which we subsequently floated on AIM in 2005 and which now specializes in the development and sale of financial risk management products. At the time the events in this case study took place, we were an IT consultancy with a strong reputation for work in the Ingres Relational Database Management System arena. A particular strength of ours was to be able to analyze systems, identify performance issues, and make changes to the database configuration, the database structures, and the SQL code within the application.

Making changes to mission-critical applications, sometimes directly on the production environment, required a careful consideration of the implications for a change, and the ability to assess the risks and agree with a customer on the risk reward profile to justify implementing changes that bypassed the conventional release procedures.

Introduction

My name is David Evans. I am the Director of Methodology at SQS, a pure-play testing and software quality consultancy. I am also the chief Agile Testing Evangelist in the company.

I have been in the software development and testing business for twenty years, first as a mainframe developer and tester, later moving to object-oriented C++ windows development and then .NET web development. In 2000 I joined Cresta, a testing consultancy, where I specialized in test automation, test methodology, and software quality practices. Cresta was later acquired by SQS.

In 2002 while carrying out a test strategy assignment for a global pharmaceutical company, I came across Extreme Programming (XP), which was being trialled by some of their development teams, and had to factor this into their enterprise-wide test strategy.

This section of the book provides a review of both the traditional or “classic” view of software testing process and agile approaches.

The chapters in this section are:

• Chapter 2 – Old-School Development and Testing, which begins by reviewing the traditional or “classic” view of software testing process. This chapter will explore the good and bad aspects of classic test process, and provides a useful baseline for the rest of the book to build on

• Chapter 3 – Agile Development and Testing, which provides a review of the most prominent agile approaches that have been used to develop software, with particular emphasis on the testing aspects of the method described. If additional information on a particular approach is needed, more complete details of each method are provided in Appendices A to D.

Introduction

My name is Isabel Evans. I'm a principal consultant at Testing Solutions Group Ltd and I have more than twenty years' experience in the IT industry, mainly in quality management, testing, training, and documentation. During that time I have worked as a practitioner and a consultant with clients in many sectors, including financial, communications, transport, and software providers.

I've been a member of various working parties and groups to contribute to improvement in software quality and testing, and my book Achieving Software Quality Through Teamwork was published by Artech in June 2004. I'm interested in people and processes, how they interact, and how those interactions affect the success of projects and businesses.

Introduction

My name is Steve K. Allott and I am a chartered information technology professional (CITP), who has worked in the IT industry for over twenty-five years, after graduating with a computer science degree.