1 Introduction 1 1 Introduction Software is everywhere. Virtually every complex product manufactured today is controlled by software, and many commercial services are based on software systems. The quality of the software used is therefore a crucial factor when it comes to remaining competitive. The faster a company can integrate new software in its products or bring software products to market, the greater the opportunity to beat the competition. Agile software development methods are designed to reduce time to market (TTM) and improve software quality while increasing the relevance of products to customer needs. It is no surprise that the use of agile methodology is on the increase in large international projects as well as in product development at all manner of large corporations. In most cases, this means switching from the tried and trusted V model to agile testing using Scrum methodology. However, switching to agile and learning to use it effectively and productively is not always easy, especially when multiple teams are involved. Every team member, project manager and all members of line management have to make significant changes to the way they work. Particularly, the effectiveness of software testing and quality assurance (QA) are crucial to the success of introducing and using agile methodology in a team, a department or an entire company, and will determine whether its potential advantages can be put into practice. Most literature on the subject of agile methodology (including many of the works referenced in the bibliography at the end of this book) is written from the viewpoint of software developers and programmers, and tends to place its main emphasis on programming techniques and agile project management testing is usually only mentioned in the guise of unit testing and its associated tools. In other words, it concentrates on testing from the developer s point of view. However, unit tests alone are not
2 1 Introduction sufficient and broader-based testing is crucial to the success of agile development processes. The aim of this book is to close this gap and describe the agile development process from the viewpoint of testing and QA. It shows how agile testing works and details where traditional testing techniques are still necessary within the agile environment and how to embed these in the agile approach. 1.1 Target Audience Understanding how testing in agile projects works On one hand, this book is aimed at beginners who are just starting to work with agile methodology, who are due to work in agile projects or who are planning to introduce (or have already introduced) Scrum into a project or team. We provide tips and advice on how product development managers, project managers, test managers, and QA managers can help to realize the full potential of agile methodology. Professional (certified) testers and software quality experts will learn how to work effectively in agile teams and make optimal use of their expertise. You will also learn how to adapt your working style to fit into the agile environment. Augmenting your knowledge of (automated) testing and agile quality assurance techniques On the other hand, we are also aiming at readers who already have experience working in agile teams and wish to expand their knowledge of testing and QA techniques to increase productivity and product quality. Product Owners, Scrum Masters, QA operatives, and members of management teams will learn how systematic, highly automated testing works and about the importance of providing continual, reliable and comprehensive feedback on the quality of the software being developed. Programmers, testers, and other agile team members will learn how to apply highly automated testing methods to unit, integration and system tests. The text includes a wealth of practical examples and practice questions, making it well suited as a textbook or for self-teaching.
1.2 Book Contents 3 1.2 Book Contents Chapter 2 provides a brief overview of the currently popular Scrum and Kanban methodologies and an overview of the most important agile management methods for managers looking to implement agile methods in their departments. These methods are compared with traditional methods to give you an idea of the changes that introducing agile methods involves. Readers who are already familiar with Scrum and Kanban methodology can skip this chapter. Chapter 3 details the lightweight planning and control tools that Scrum uses in place of traditional project planning tools. Remember, working in an agile fashion doesn t mean working aimlessly! Chapter 3, too, is aimed primarily at readers who are making the switch to agile development. Nevertheless, the explanations and tips regarding the importance of planning tools for constructive quality assurance and error prevention will be useful to experienced readers too. Chapter 4 covers unit testing and test first programming techniques. Topics include what unit tests can be expected to achieve and how they can be automated. This chapter covers the basics of unit testing techniques and tools and will help system testers, test specialists, and project team members with little or no unit testing experience to work more closely and effectively with programmers and unit testers. It also includes a wealth of useful tips that will help experienced programmers and testers to improve their testing techniques. We also explain the test first test-driven approach to programming and its importance within agile projects. Chapter 5 covers integration testing and the concept of continuous integration testing. Integration testing covers test cases that even the most diligent programmers miss when using unit tests. This chapter covers all the basics of software integration and integration testing, and introduces continuous integration techniques, explaining how to use them within a project. Chapter 6 discusses system testing and the concept of nonstop testing. Based on system testing foundations, this chapter explains how to use agile techniques to perform manual tests. It also explains how to automate system tests and embed them in the continuous integration process. This chapter is aimed not only at system testers and other testing specialists, but also at programmers who wish to better understand agile testing techniques that lie outside their usual development-driven remit. Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6
4 1 Introduction Chapter 7 Chapter 8 Chapter Overview Chapter 7 compares traditional and agile ideas of quality assurance and explains the constructive and preventative QA practices that are built in to Scrum. This chapter includes tips on how to perform agile QA and explains how all QA specialists can use their know-how within agile projects and contribute to the success of agile projects. Chapter 8 presents six industrial, e-commerce, and software development case studies. These reflect the experiences gained and lessons learned by the interviewees during the introduction and application of agile techniques. Chapters 2, 3, 7, and 8 discuss process and management topics and are aimed at readers who are more interested in the management aspect of the subject. Chapters 4, 5, and 6 discuss (automated) agile testing at various levels and are oriented toward more technically minded readers. Because agile testing is not the same as unit, we also explain in detail the aims of and differences between unit, integration, and system testing. Figure 1-1 provides a visual overview of the book s structure: Fig. 1 1 The structure of the book Case study, checks and exercises According to most popular literature on the subject, many agile concepts, techniques and practices are simple to implement. Similarly, the ideas, advice and tips covered in the following chapters may at first appear simple, but the sticking points often only become evident in the course of implementation. To help you understand and experience the challenges involved, the text includes:
1.3 Case Study 5 A fictional case study that illustrates the methodology and techniques being discussed. Checks and exercises to help you recap the content discussed in each chapter and scrutinize your own situation and behavior within your project. 1.3 Case Study The fictional case study the book refers to uses the following scenario. The company ehome Tools is a developer of home automation systems based on the following elements: Actuators: Lamps and other electrical devices are connected by means of electronic switches. Every actuator is connected by wire or wirelessly to a comms bus that can be used to control it remotely. Sensors: Thermal, wind and humidity detectors and simple contact sensors (for example, to indicate an open window) can also be connected to the bus. Bus: Switching instructions and status signals for the actuators and sensors are sent via the bus to the central controller in the form of telegrams. Controller: The central controller sends switching signals to the actuators (e.g., switch kitchen light on ) and receives status signals from the sensors (e.g., kitchen temperature 20 degrees ) and actuators (e.g., kitchen light is on ). The controller is either event-driven (i.e., reacts to incoming signals) or works on the basis of timed commands (e.g., 8pm close kitchen blind ). User interface: The controller has a user interface that visualizes the current status of all elements of the ehome and enables its inhabitants to send instructions (e.g., switch kitchen light off ) via mouse click to the house systems. Case Study: ehome Controller ehome Tools has many competitors and, in order to remain competitive, the company decides to develop new controller software. An increasing number of customers is asking for software that can be controlled via
6 1 Introduction smartphones and other mobile devices, so it is clear from the start that this project has to be completed quickly if it is to be successful. It is essential that the new system is extensible and open for third-party devices. If the new system is able to control devices from other manufacturers, management is convinced that the company can win over customers who wish to extend their existing systems. To fulfill this goal, the new system has to support as wide a range of existing third-party hardware as possible and must be capable of adapting to support new devices as soon as they appear on the market. In view of these challenges, the decision is taken to develop the new system using agile methodology and to release an updated version of the controller software (with support for new devices and protocols) every month. 1.4 Website The code samples included in the text are available for download at the book s website [URL: SWT-knowledge]. Feel free to use them to construct your own test cases. The practice questions and exercises are also available online and can be commented on. We look forward to discussing your comments and suggestions. In spite of all our efforts and those of the publisher, it is still possible that some text errors remain. Any necessary corrections will be published online.