Software Testing Forever:
Old and New Processes and Techniques for Validating Today's Applications
Antonia Bertolino is a Research Director of the Italian National Research Council (CNR),
in Pisa, where she leads the Software Engineering Research Laboratory. Within European
and national projects, she investigates approaches for rigorous and automated model-based
integration and system testing, for architecture-based and component-based test methodologies,
as well as methods for evaluation of extra-functional properties of compound systems.
She is the Area Editor for Software Testing for the Elsevier Journal of Systems and Software;
she is also an Associate Editor of Springer Empirical Software Engineering Journal, and of the
IEEE Transactions on Software Engineering.
She has been the Program Chair for the joint European Software Engineering Conference and
the ACM SIGSOFT Symposium on the Foundations of Software Engineering Conference ESEC/FSE 2007.
She serves regularly in the Program Committees of the main events in software engineering and testing,
including ISSTA, ESEC/FSE, ICSE, TESTCOM/FATES, CBSE.
She has (co)authored over 90 papers in international journals and conferences.
ABSTRACT. Software testing is a very complex activity deserving a first-class role in software development.
Testing related activities encompass the entire development process and may consume a large part of
the effort required for producing software. In this talk, I will first organize into a coherent framework the
many topics and tasks forming the software testing discipline, pointing at relevant open issues.
Then, among the outlined challenges, I will focus on some hottest ones posed by the testing of modern
complex and highly dynamic systems.
What is assured is that software testers do not risk to remain without their job, and testing researchers are
not at short of puzzles. Software testing is and will *forever* be a fundamental activity of software engineering:
notwithstanding the revolutionary advances in the way it is built and employed (or perhaps exactly because of),
the software will always need to be eventually tried and monitored. In the years, software testing has evolved
from an 'art' to a discipline, but test practice largely remains a trial-and-error methodology. We will never find
a test approach that is guaranteed to deliver a 'perfect' product, whichever is the effort we employ. However,
what we can and must pursue is to transform testing from 'trial-and-error' to a systematic, cost-effective and
predictable engineering practice.
Supporting Experience and Information Flow
in Software Projects
Kurt Schneider studied Computer Science in Erlangen, Germany. He received a doctoral degree in
Software Engineering from the University of Stuttgart in 1994. He had a grant from the
NATO Science Committee for a Postdoctoral position at the University of Colorado at Boulder
from 1994-1996. Kurt Schneider was a visiting member of the interdisciplinary Center for
LifeLong Learning and Design in Boulder. From 1996-2003, he was a researcher and a project leader
at the DaimlerChrysler Research Centre in Ulm, Germany. In particular, Kurt Schneider was
leader of the Software Experience Centre (SEC) project for DaimlerChrysler. Since 2003, he is
a full professor of Software Engineering at Leibniz Universität Hannover. His main research
interests are requirements engineering, software quality, and service-oriented architectures.
Life-long learning and cognitive optimization of techniques and tools are investigated in all
ABSTRACT. Several large companies have conducted initiatives for systematic
learning from experience in software engineering. In the international
Software Experience Center (SEC), for example, five companies exchanged
experiences and collaborated in building experience exchange mechanisms
to be used within each company. Many insights were gained and lessons were
learned over the years, among them: (1) Written and documented experiences
are the exception rather than the rule. (2) Although not documented in detail
or controlled by a process, experience needs guidance and support in order
to reach the designated person or group. The “flow” of experience must be kept
in mind. (3) Experience is a delicate material, and any avoidable effort or
threshold to participate in systematic experience exploitation may endanger
stakeholder participation and success. (4) Tools can effectively be built to
support orderly flow of experience, but they must be optimized for cognitive
support of their users.
These lessons learned from supporting experience
exploitation can be applied to software projects more generally:
Requirements, rationale, and other information flowing through a software
project resemble experience with respect to the above-mentioned
characteristics: They are often communicated orally rather than in a document.
There are diverse processes and practices designed to channel information flow.
Early and vague requirements must be handled with care, and tools need to be
optimized to reduce cognitive barriers and thresholds, or they will not be
A focus on information and experience flow takes the
above-mentioned lessons into account. Information flows within one project,
while experience often cuts across several projects. Requirements of one
project are useful only in that same project. Experience in designing a product,
however, may be reused in subsequent projects. Information and experience
flows need to be modelled explicitly. A simple notation is proposed to
capture just the essence of flowing information. What may seem like a subtle
shift from processes to flows offers a new perspective: Based on those models,
dedicated techniques and tools can be developed for analysing and for
improving the flows. A wide range of current trends in software engineering
can benefit from a better understanding of – and support for – appropriate
information flow: Interfaces to the subcontractors, distributed and
collaborative teams, Wiki webs, and a variety of new communication channels
in global software engineering call for a focus on information flow.
Culture of Error Management
“Why admit an error when no one will find out?”
Short bio of
Horst Degen-Hientz. "In my roles as consultant and business development manager
I have today the responsibility to support our customers’ process performance
improvement and change programs towards targeted business success.
In my various roles as programmer, consultant, and CEO I have gathered since 1986
in-depth insight in companies and practices in this field. My experiences are
based on intensive work with culturally diverse small, medium, and large
embedded systems software development organizations within the value creation
network especially in Automotive and Telecom industries. Selected experiences
were packaged as tutorials and papers and published at various conferences,
e.g. NASA/SEL96 - USA, ESCOM97 - Germany, ACOSM97 - Australia,
DASIA97 - Spain, SPI98 - Monte-Carlo, E-SEPG98 – UK, SEPG08 - USA."
KUGLER MAAG CIE is a professional consulting services company, member of Lero, the
Irish Software Engineering Research Institute, co-founder of iNTACS (TM),
partner of the SEI-USA, and sponsor of the SEI-Europe. www.kuglermaag.com.
ABSTRACT. What has a Stradivari and Linux in common? It is the error culture-driven process
that created it. A culture of restless strives for innovation and quality enabling
continuous learning. We systematically get trained by being punished as child
when doing mistakes and often need a life long cumbersome process to undo this
conditioning. In western world many organization behave just like as that:
errors are socially not acceptable. This seems to be universal applicable as
Kaizen and the “zero-defect-culture” can teach us. It is not a society
intrinsic attitude - as one can observe from the Toyota way - which took
years to establish an organizational error management culture. Studies in
Europe show too that organizational error management are a means to boost
companies’ performance and goals achievement. Hence, what can we learn from
Stradivari and Linux? It is the way to organize error management and
innovation. This is key to open source projects and the raising inner source
projects as observable in companies like Google.