Staff

Research interests  [ Show full biography ]

Successful test automation is one of the primary enablers for efficiency in a modern software design organization. Apart from reductions in time-to-market by decreasing the time spent waiting for feedback, several other benefits can be reaped, for example, the amount of people involved in manual testing can be decreased and used for other activities, the general confidence in the product is increased by allowing for a higher test coverage in the same or lower lead time. Also, testing can be performed hands-off during otherwise idle times, such as breaks, week-ends, and nights, which contributes greatly to the over-all efficiency. However, test automation is traditionally performed ad hoc, typically beginning with a small set of test cases are executed together, a report generator is added, then everything is wrapped in an off-hours execution system, and so on. Clearly, the results from an activity like that will vary, from stable and reliable, to only providing a false sense of security to the user and actually not performing any reliable testing at all. Technical debt is a metaphor comparing design short-cuts to financial debt. By taking a loan one may fulfill a goal faster, but the loan will incur costs over time in the form of interest and paying down the principal. According to Cunningham, "a little debt speeds development so long as it is paid back promptly with a rewrite." From this we conclude that the concept of technical debt is related to design imperfections primarily due to time pressure or lack of other resources. This can be compared to "impediments", which according to the Scrum Alliance are "anything that prevents a team member from performing work as efficiently as possible". If technical debt in a tool impacts the functionality or performance of the tool, the user of that tool may experience the impact as an impediment. If the impact on the work is large enough, the impediment may in turn be the reason for introduction of technical debt in the product being produced by the tool user. In the case of test systems, poorly designed, hard to use, or instable test systems may cause the software developers to spend excessive time on setup or configuration, reducing the time available for actual development work. Also, if the test systems are performing suboptimally, it is not unreasonable to expect that the testing suffer, and that some defects in the delivered product stay undetected even after testing. We also need to consider that a poorly designed or architectured test system will, exactly as any other badly designed complex software system, require more resources for maintenance and feature development, resources which could have been better used elsewhere. Our research in this area has two goals: (1) investigating the impediments caused by technical debt in test system and relating them to the cost of resolving the technical debt, and (2) investigating the reasons for the introduction of the technical debt in the first place.

Latest publications [ Show all publications ]

Research projects

On-going:
• ITS-EASY Post Graduate School for Embedded Software and Systems