STAMP uses state-of-the-art search-based software engineering techniques to reproduce existing crashes
How would you present STAMP?
STAMP is about being smart about testing. We know we need to test, but often we don’t do it or we don’t do it fully enough. What STAMP brings to the table is making full use of the tests that are already there and by applying smart approaches, creating additional tests.
Some of the key technologies that STAMP uses are so-called amplification operators, or small systematic changes that are made to test code, so that the test’s course is altered. If this leads to exercising an interesting path through the code, potentially uncovering a bug, we have a new test that we can add.
Similarly, using techniques borrowed from artificial intelligence, we construct a new test that replicates a crash that has previously occurred.
What is your role in STAMP?
My primary role is to supervise and guide the two researchers from Delft University of Technology that work on crash replication. As such, I am primarily concerned with WP3, the work package about the runtime test amplification.
What key innovation do you bring or help to develop?
We use state-of-the-art search-based software engineering techniques to reproduce existing crashes. We start from a stack trace, which is a simple list of the method calls that were executed just before the program crashed. Then, using a genetic algorithm we try to approximate the exact sequence of method calls from the stack trace, with the expectation that we thus also recreate the crash.
Being able to recreate a crash is important, because it is often the first step in understanding and subsequently debugging the software. In addition, once the bug has been resolved, the test can be altered, so that it becomes a regression test.
A word about yourself and your organization
I am an associate professor in software engineering working specifically in the area of software testing. I study how people test software and how to make the process of testing easier.