Børge Haugset

Automated Acceptance Testing: A Literature Review and an Industrial Case Study

Automated acceptance testing is a quite recent addition to testing in agile software development holding great promise of improving communication and collaboration. This paper summarizes existing literature and also presents a case study from industry on the use of automated acceptance testing. The aim of this paper is to establish an up to date overview of existing knowledge to benefit practice and future research. We show that some of the proposed benefits are realistic but that further research and improvements are needed to get the full potential value.

Automated Acceptance Testing as an Agile Requirements Engineering Practice

This article describes how the use of automated acceptance test-driven development (ATDD) impacts requirements engineering in software development. We extend an existing framework of inherent risks in RE by adding knowledge from literature and a case study. We show how ATDD can be seen as a mix of the traditional RE focus on documentation and the agile focus on iterative communication. ATDD can mitigate some of the inherent risks in RE. It also carries with it the need for a proper domain and a very rigorous development method that requires disciplined developers and dedicated customers, preferably on-site.

Automated Acceptance Testing Using Fit

Automated acceptance testing is a new and promising agile testing approach. Fit is the most established technical framework for specifying and executing acceptance tests which, ideally, lets the users express requirements in the form of acceptance tests. We performed an industrial case study to learn more on the costs and benefits of Fit tests. We learned that Fit tests may improve important parts of an agile development process but there is still a need for further research and improvements.

Agile Change Impact Analysis of Safety Critical Software

Change Impact Analysis (CIA) is an important task for all who develops and maintains safety critical software. Many of the safety standards that are used in the development and use of systems with a certified safety integrity level (SIL) requires changes of such systems to be initiated by a CIA. The resulting CIA report will identify planned changes that may threaten the existing safety level. The challenge with CIA is that there are no practical guidelines on how to conduct and report such an analysis. This has led to a practice where most changes lead to extensive up-front analysis that may be costly and delay the change process itself. In this paper we propose a new strategy for CIA based on the principles of agile software development and the SafeScrum approach to establish a more efficient in-process impact analysis. We discuss several benefits of this approach, like resource savings, shorter time to initiate the change process, better prioritization and management of the change process, and others.

Quality Assurance in Scrum Applied to Safety Critical Software

Various agile methods have several quality assurance mechanisms embedded in the process itself, without any explicit QA role. In principle, the team takes care of quality assurance during sprints and as part of daily stand-ups, sprint reviews and retrospectives. We have defined SafeScrum, a variant of Scrum with some additional XP techniques that can be used to develop safety-critical software and have the software certified according to the IEC 61508 standard. This imposes a load of additional requirements on the process. In a recent industrial case, we have experienced that the quality assurance mechanisms in Scrum becomes insufficient. We have therefore analyzed the standard, consulted an independent assessor and worked with the Scrum team to identify necessary additional tasks for a team-internal QA role to be added to the SafeScrum process.

The Home Ground of Automated Acceptance Testing: Mature Use of FitNesse

This article describes a group of developers and how they successfully use Fitness. The study is based on interviews with 4 consultants, and shows that automated acceptance testing was used in two steps every iteration: a specification step where it helped communicate requirements, and a verification step where it helped developers in the process of producing and maintaining software. The study indicates that automated acceptance testing may be a viable strategy, but that it must be used with care. Communicating requirements throughout the lifespan of the software is just as important as automating the tests, and AAT can help with both of these issues.

Mobile Process Support Systems

Work process support systems, both in the form of workflow systems and of more loosely structured systems have been widely developed and also to a large extent been taken into use in a large number of work situations. As computing is becoming both pervasive and nomadic, workers use of computing and communication services is less limited to solitary moments at an office desk. Thus it gets more and more important to provide mobile work process support systems. This paper presents experiences related to the development, introduction and evolution of such systems through results from a case study following phone engineers. The main conclusions from the study are that that smaller terminals not necessarily does the job better, computerised systems are not always better than paper-based systems, and that supporting nomadic work must be done in agreement with the overall work context.

Integration of the 4+1 Software Safety Assurance Principles with Scrum

Some researchers have attempted to tailor agile methods to comply with specific standards (e.g. SafeScrum and IEC61508). However, this risks over-configuring the agile method in such a way as to make it difficult to apply it to another safety standard. Our approach sought to look at the problems of addressing the more fundamental principles of safety assurance by adopting the 4+1 safety principles and investigating how a Scrum process challenges, and can be adapted to give strong indication that the practitioners felt that there is a significant potential for successful integration of the 4+1 principles within Scrum. There were some issues where practitioners were concerned to focus only on one safety standard, and neither the agile practitioners nor the safety practitioners had a clear understanding of the outlook and work of the other group. However, we used these issues to inform a further set of questions. We conducted semi-structured interviews with participants to explore the general feasibility of the approach, and to provide an assessment as to whether the 4+1 principles can be addressed without compromising agility.

Healthcare Services in the Cloud - Obstacles to Adoption, and a Way Forward

Cloud computing has been receiving a great deal of attention during the past few years. A major feature of public cloud services is that data are processed remotely in unknown systems that the users do not own or operate. This context creates a number of challenges related to data privacy and security and may hinder the adoption of cloud technology in, for example, the healthcare domain. This paper presents results from a stakeholder elicitation activity, in which the participants identified a number of obstacles to the adoption of cloud computing for the processing of healthcare data. We compare our results with previous studies and outline accountability as a possible way forward to increase the adoption of cloud services in the healthcare domain.

From Incident Response to Incident Response Management

In this paper we propose the development of a methodology for efficient handling of computer security related incidents. Such a methodology should include technical, cultural, and organisational issues.