What is Agile Software Testing

Editor's NoteThe concept of Agile has taken root in people's hearts, and the development process is getting better and better, but the situation of testing is a bit awkward. InfoQ has invited Duan Nian, an agile testing expert from Google, to answer questions for readers and hope all testing practitioners can get their own answers from it. For more on Agile Testing, please visit InfoQ's Agile Testing related content. When discussing Agile with many testing practitioners, the most frequently asked questions are about two: What in the world? The first question is about agile testing itself. The first question is about the definition of agile testing itself, and the second question is about the concern that agile development will exclude test engineers. In fact, in the process of exploring the answers to these two questions, we can have a clearer understanding of the job definition of testing in agile software development, testing values, and the alignment of development and testing engineers in agile development. Given the significance of these two questions, in the first article of this Agile Testing column, I try to answer these two questions as clearly as possible from my own practice. Indeed, the discussion of Agile Testing is much more low-key than the Agile Development red herring. The Agile Alliance defines 4 value statements for Agile, and the accompanying 12 supporting principles, none of which mention testing alone. Does this mean that testing is not important in Agile development? In fact, a closer look at the 12 principles of Agile, as well as a variety of different Agile practices, reveals that testing has a very important place in Agile development. Whether it's frequent delivery in the principles, metrics for working software, or test-driven development and behavior-driven development in agile development practices, testing is essential. In my opinion, the reason why testing is not described separately in Agile development is precisely because in Agile development, testing is no longer a separate, independent process from development, but has become the main means to drive development and measure output, and has become a part of Agile development that all engineers must always consider and practice when working. In short, agile software testing is more of a concept than a process. If that's the case, why are we dedicating this column to Agile software testing? I have come into contact with many software development and test engineers in organizations that are trying to transition to Agile development, or have been practicing Agile development for some time, but due to long-standing work habits, the vast majority of them do not consciously recognize the critical role of testing in Agile development, but consciously or unconsciously still see testing as the next stage separate from development, resulting in the process of practicing Agile development being more of a concept than a process. As a result, they encounter all kinds of problems in the process of practicing Agile development: either they neglect code quality, resulting in frequent iterations with endless problems in each iteration; or they follow the original method of arranging the system testing of the system, resulting in the testing team being exhausted, but always failing to catch up with the progress required by the development. In this case, the topic of testing in agile software development, also known as agile software testing, should be of some help to these engineers. So, in the end? It is difficult to give a precise and perfect definition of Agile Testing, in my opinion, embracing the core values of Agile (Communication, Simplicity, Feedback, Courage, and Respect), the testing carried out during Agile software development can be called Agile Software Testing. Therefore, Agile Software Testing is not a division at the same level as Agile Software Development, but rather a part of Agile Software Development, and unlike traditional testing, Agile Software Testing is not a stand-alone process; rather, it is intertwined with other activities throughout Agile Development, and can be seen everywhere. Since Agile Software Testing does not tend to be a separate process definition, I propose to elaborate on it in terms of comparison of Agile Software Testing with traditional testing viewpoints, methodologies used in Agile Software Testing, and the work of test engineers in the Agile Software Testing process. In this article, we mainly describe Agile software testing from a macro point of view, and in the subsequent articles of this column, we will further describe the methods used in Agile software testing, the work of engineers in Agile software testing. Use Dashboard, burndown charts, etc. to show the distance between the current work and the deliverable Establish metrics such as unit test coverage*** Enjoying quality goals means that the quality responsibility is borne by all engineers*** Together with the development test should establish certain test coverage standards, for example, at this level of unit testing, establish 60% or 80% coverage requirements by using TDD, BDD and other techniques to ensure that the testability of the product and code to establish a sufficient number of automated tests to ensure that the test can meet the requirements of rapid iteration checklist mentioned four aspects of the team, feedback, quality culture and development testing, in my opinion, these four aspects reflect the Agile software testing and traditional software testing the biggest difference. Traditional software testing focuses on finding as many problems as possible through the most complete coverage, treating testing and development as two separate processes, and testing is the verification of the results produced during the development phase. Agile software testing, on the other hand, establishes a different quality culture: the purpose of testing is to ensure a rapid release of the product, i.e., an increase in productivity itself. A validation-based starting point necessarily requires independence between testing and development, as well as as as objective and complete a measure of product quality as possible, whereas a productivity-based starting point requires the creation of agile teams, the closest possible alignment between testing and development, the creation of software with a high degree of testability, and a high degree of automated testing based on these. In all of the items listed in the checklist, a culture of quality is the foundation, teams are what make agile software testing possible, and feedback and development testing are the specific methods of agile software testing. Of course, you can can stage these items in terms of Agile's core values: teams are concerned with communication and respect; feedback corresponds directly to feedback; quality culture is based on courage (the courage to take responsibility for quality) and respect; and development testing is the concrete manifestation of feedback and simplicity. Another question posed at the beginning of this article is: does agile software development still need test engineers? There are different views in the industry on this question. Some people think it is necessary because there are always some tasks that need the skills of test engineers; of course, some people think it is not necessary because testing in agile development focuses on development testing and automation testing, and the development engineers can take care of the work related to testing by themselves. In practice, companies that practice agile development on a large scale (e.g., Google) tend to set up fewer test engineers in the organization, allocate fewer testing resources to projects, or even do not use test engineers at all for some projects. In my personal experience, for most projects, especially those developed for a specific customer, it is necessary to have dedicated test engineers in the agile development team because: testing and development have different ways of thinking: testing focuses more on comprehensively verifying and checking a system, while development engineers tend to have difficulty in establishing such a way of thinking on a large scale. Therefore, dedicated test engineers are more effective in verifying a product on a system level, or discovering access points that are worth testing and verifying from an application point of view. Dedicated test engineers are able to focus more on test fundamentals and build the infrastructure needed for testing: Since test engineers have a better understanding of testing, they are usually able to develop project-appropriate test infrastructure (automated test frameworks) that can be used by development engineers to build functional or code-oriented tests, taking into account the needs of testing. However, it must be said that Agile development puts more demands on both development and test engineers, especially on test engineers. Traditional test engineers who can only accurately simulate user actions can hardly make a difference in an Agile development team because they cannot bring productivity gains to the product. In the following articles of this column, we will further discuss the work and tasks of test engineers in agile software development. About the Author Duan Nian: Senior test manager of Google China, graduated from Huazhong University of Science and Technology, has been engaged in software development and testing in domestic and international famous companies in various industries, such as communication, embedded software, Internet and so on. He has unique insights into the technology and management work in software testing, and has done more research on software testing team management, automation testing, performance testing and development testing.