Editorial: Agility must be good for testing

Abstract

This issue has three papers that advance our knowledge in criteria-based test design. The first, Improving the coverage criteria of UML state machines using data flow analysis, by Lionel Briand, Yvan Labiche, and Q. Lin, proposes coverage criteria to design tests from UML state machines. The second, Automatic string test data generation for detecting domain errors, by Ruilian Zhao, Michael R. Lyu, and Yinghua Min, presents a new method for automatically generating strings as test values. The third, Full predicate coverage for testing SQL database queries, by Javier Tuya, Maria José Suárez-Cabal, and Claudio de la Riva, adapts test criteria in a novel way, to testing database queries. Unless you’ve been hiding or never look outside of academia, you must have seen the wave of agile processes that have been sweeping the software industry. Is the term agile process just one more of the hundreds of buzzwords that have made the rounds, only to disappear in obscurity, or does it describe something that will have a lasting positive impact on software development? If you hope for an answer to that question here, I am no fool to make such a rash prediction. I am neither an advocate nor a critic of agile processes, and not knowledgeable enough to be either. My mind is truly open on this subject. Through my students and other industrial contacts, I have talked with numerous people who applied an agile process correctly and thought it helped very much. I have also talked with people who failed miserably with an agile process. Many of them seem to have applied the process incorrectly. Without a long tutorial, agile processes involve some speedups to older processes and also some changes that are intended to make major quality improvements. Most companies I have seen fail left out two things: they did not refactor and they did not document. Both are crucial for quality and the companies leave them out to ‘save time’. But leaving those out means after three or four maintenance cycles, the software is in danger of turning into a huge unmaintainable mess. But these issues are well known and discussed by people who are far more knowledgeable about process than I am. My interest is more personal. Whether agile processes are good for software development or, I like them! I like them for the simple reason that they put more emphasis on testing. Perhaps my favorite new term is Developer Testing. Teachers and researchers have been advocating more ‘unit testing’ for decades, but agile processes emphasize ‘developer testing’, where developers are responsible for testing their own classes before integrating them into the rest of the system. Get it? Developer testing, not unit testing. Okay, I don’t see the difference either . . . but the new term works! In the last five years hundreds of software companies have been pushing their programmers to do a better job of developer testing. And the most widely used testing tool is

DOI: 10.1002/stvr.443

Cite this paper

@article{Offutt2010EditorialAM, title={Editorial: Agility must be good for testing}, author={A. Jefferson Offutt}, journal={Softw. Test., Verif. Reliab.}, year={2010}, volume={20}, pages={175-176} }