Case Study: Optimizing the Automated Acceptance Testing Infrastructure at SaleMove

SaleMove on ettevõte, mis pakub tarkvara kui teenust. Kuna SaleMove asetab suurt rõhku oma tarkvara kvaliteedi tagamisele, on ettevõte huvitatud oma tarkvaraarenduse protsessi pidevast täiustamisest. Üks oluline osa selles tarkvaraarenduse protsessis on automatiseeritud vastuvõtutestide käitamine. Käesolev magistritöö optimeeribki selle tarkvaraarenduse protsessi olulise osaga seotud infrastruktuuri, eesmärgiga vähendada infrastruktuuriga seotud riistvaralisi kulutusi, vähendada viivitust vastuvõtutestide tagasiside saamisel ja suurendada infrastruktuuri paindlikkust kasvava arvu vastuvõtutestidega toime tulemise osas.Nende eesmärkide saavutamiseks analüüsitakse kõigepealt esialgse infrastruktuuri puudusi, mille järel pakutakse välja mitmeid täiendusi. Et vältida negatiivseid mõjusid ettevõtte igapäevatööle, katsetatakse neid täiendusi esialgu eksperimentaalsel koopial SaleMove’i tõelisest automatiseeritud vastuvõtutestimise infrastruktuurist. Peale esialgset mõjude hindamist, võetakse täiendused kasutusele ka SaleMove’i tõelises automatiseeritud vastuvõtutestimise infrastruktuuris ning tehakse tähelepanekuid nende täienduste mõju kohta praktilises kasutuses.SaleMove is a software-as-a-service company that places a high emphasis on the quality of its software and is therefore constantly looking to improve its software development process. An important part of that software development process is automated acceptance test execution. This thesis presents solutions that optimize the infrastructure related to that important part of the development process in order to reduce the associated hardware costs, reduce the delay in receiving acceptance testing feedback, and increase the infrastructure’s flexibility in dealing with a growing number of acceptance tests.To achieve these goals, the limitations of the initial infrastructure are analyzed, after which a number of enhancements are proposed. These enhancements are implemented and their impact is evaluated on an experimental duplicate of SaleMove’s automated acceptance testing infrastructure in order to avoid negatively interfering with the ongoing software development. Finally, the enhancements are also implemented on Salemove’s active automated acceptance testing infrastructure and observations are made about the effects of the enhancements in practical usage

Two Sides of the Same Coin: Software Developers' Perceptions of Task Switching and Task Interruption

In the constantly evolving world of software development, switching back and forth between tasks has become the norm. While task switching often allows developers to perform tasks effectively and may increase creativity via the flexible pathway, there are also consequences to frequent task-switching. For high-momentum tasks like software development, "flow", the highly productive state of concentration, is paramount. Each switch distracts the developers' flow, requiring them to switch mental state and an additional immersion period to get back into the flow. However, the wasted time due to time fragmentation caused by task switching is largely invisible and unnoticed by developers and managers. We conducted a survey with 141 software developers to investigate their perceptions of differences between task switching and task interruption and to explore whether they perceive task switchings as disruptive as interruptions. We found that practitioners perceive considerable similarities between the disruptiveness of task switching (either planned or unplanned) and random interruptions. The high level of cognitive cost and low performance are the main consequences of task switching articulated by our respondents. Our findings broaden the understanding of flow change among software practitioners in terms of the characteristics and categories of disruptive switches as well as the consequences of interruptions caused by daily stand-up meetings

Designing Attention-aware Business Intelligence and Analytics Dashboards to Support Task Resumption

External interruptions are a common phenomenon in today’s working environment. Specifically, attentional shifts in working environments lead to task resumption failures that refer to the improper resuming of a primary task after an interruption and negatively influencing the individual performance of employees. Business Intelligence & Analytics (BI&A) systems are well recognized as an essential concept to support decision making of employees. One important and frequently used BI&A system component are dashboards. BI&A dashboards enable collecting, summarizing, and presenting business information from different resources to decision makers. When working with BI&A dashboards, interruptions and resulting task resumption failures have negative consequences on decision-making processes. This research in progress paper addresses this problem and provides design knowledge for attention-aware BI&A dashboards that support users during task resumption. We follow a Design Science Research (DSR) approach and derive theory-grounded design principles for task resumption support on BI&A dashboards. Moreover, to evaluate the suggested principles, an instantiation is realized. In our instantiation, real-time tracking of eye-movement data is used to capture visual attention of the users and provide visual feedback after task resumption. We introduce testable hypotheses and present preliminary results of a pre-test lab experiment

ScreenTrack: Using a Visual History of a Computer Screen to Retrieve Documents and Web Pages

Computers are used for various purposes, so frequent context switching is inevitable. In this setting, retrieving the documents, files, and web pages that have been used for a task can be a challenge. While modern applications provide a history of recent documents for users to resume work, this is not sufficient to retrieve all the digital resources relevant to a given primary document. The histories currently available do not take into account the complex dependencies among resources across applications. To address this problem, we tested the idea of using a visual history of a computer screen to retrieve digital resources within a few days of their use through the development of ScreenTrack. ScreenTrack is software that captures screenshots of a computer at regular intervals. It then generates a time-lapse video from the captured screenshots and lets users retrieve a recently opened document or web page from a screenshot after recognizing the resource by its appearance. A controlled user study found that participants were able to retrieve requested information more quickly with ScreenTrack than under the baseline condition with existing tools. A follow-up study showed that the participants used ScreenTrack to retrieve previously used resources and to recover the context for task resumption.Comment: CHI 2020, 10 pages, 7 figure

Towards the exploration strategies by mining Mylyns' interaction histories

When developers perform a maintenance task, they always explore the program, i.e., move from one program entity to another. However, even though maintenance is a crucial task, the exploration strategies (ES) used by developers to navigate through the program entities remain unstudied. This lack of study prevents us from understanding how developers explore a program and perform a change task, from recommending strategies to developers, and (ultimately) from critically evaluating a developer's exploration performance. As a first step towards understanding ES, we mined interaction histories (IH) gathered using the Eclipse Mylyn plugin from developers performing a change task on four open-source projects (ECF, Mylyn, PDE, and Eclipse Platform). An ES is defined and characterized by the way (how) the developers navigate through the program entities. Using the Gini inequality index on the number of revisits of program entities, we observe that ES can be either centralized (CES) or extended (EES). We automatically classified interaction histories as CES or EES and performed an empirical study to ascertain the effect of the ES on the task duration and effort. We found that, although an EES requires more exploration effort than a CES, an EES is less time consuming than a CES. Extensive work (number of days spent performing a task) typically imply a CES. Our results show that developers who follow an EES have a methodical investigation of source code while developers who follow a CES have an opportunistic exploration of source code

Understanding Programmers' Working Context by Mining Interaction Histories

Understanding how software developers do their work is an important first step to improving their productivity. Previous research has generally focused either on laboratory experiments or coarsely-grained industrial case studies; however, studies that seek a finegrained understanding of industrial programmers working within a realistic context remain limited. In this work, we propose to use interaction histories — that is, finely detailed records of developers’ interactions with their IDE — as our main source of information for understanding programmer’s work habits. We develop techniques to capture, mine, and analyze interaction histories, and we present two industrial case studies to show how this approach can help to better understand industrial programmers’ work at a detailed level: we explore how the basic characteristics of software maintenance task structures can be better understood, how latent dependence between program artifacts can be detected at interaction time, and show how patterns of interaction coupling can be identified. We also examine the link between programmer interactions and some of the contextual factors of software development, such as the nature of the task being performed, the design of the software system, and the expertise of the developers. In particular, we explore how task boundaries can be automatically detected from interaction histories, how system design and developer expertise may affect interaction coupling, and whether newcomer and expert developers differ in their interaction history patterns. These findings can help us to better reason about the multidimensional nature of software development, to detect potential problems concerning task, design, expertise, and other contextual factors, and to build smarter tools that exploit the inherent patterns within programmer interactions and provide improved support for task-aware and expertise-aware software development