Scope of Agile Approach for Software Testing Process

Agile development processes such as Scrum have been successfully applied in the software industry for many years. Based on experience, industrial practitioners indicate three predominant benefits of agile development processes compared to traditional software development processes. First of all, development results better fit customers’ and other stakeholders’ needs. That is because they are intensively involved in the development process by receiving, applying and assessing functional software increments in a defined cadence throughout the development process. Secondly, agile development processes better cope with unexpected changes in the development process due to the built-in process flexibility. Lastly, development speed has significantly increased in most of the agile software development projects, resulting in a shorter time-to-market. Especially in the context of radical innovations for technical systems, manufacturing companies are striving for approaches to optimize their development processes in a similar direction. Traditional plan-oriented development approaches such as VDI 2221 or Cooper’s Stage-Gate Process turn out to be insufficiently customer oriented, too inflexible and project duration is usually too long to reach an adequate time-to-market. For that reason, a large community in academia and industrial practice is developing and implementing approaches to adapt agile software development practices for the development of technical systems. However, a current study in industrial practice reveals that out of 23 objectives, that are expected when introducing agile development processes to technical systems, the three objectives mentioned above, show the largest negative deviations from expected benefit to realized benefit. Therefore, the overall goal of this research is to address these gaps by developing an explicit methodological approach for an agile development of technical systems. It turns out, that mainly the role of prototyping and the way product specifications are handled during the development process change significantly in the course of introducing agility to development of technical systems. Agile practitioners strive to not necessarily define product specifications comprehensively upfront, as it is postulated in plan-oriented development processes. In contrast, product specifications, which are of major importance to the overall development project, are specified and validated with customers and other stakeholders in early prototypes. Therefore, prototypes are realized in a defined cadence throughout the development process to gradually specify and validate the product. However, the way product specifications are prioritized and selected in the development of technical systems has to differ substantially from the general way Scrum or other existing agile development processes propose. That is because technical systems are characterized by multiple technical interrelations, resulting in informational dependencies for the development process. For that reason, a prioritization along criteria such as customer value, development effort and risk seems too narrow in the context of technical systems. In fact, the prioritization of product specifications has to consider both, the value being generated by their realization as well as the informational dependencies towards other specifications. Furthermore, when designing a prototype, time constraints need to be particularly considered due to lead times in parts delivery and prototype production. Therefore, this paper introduces a methodology to prioritize and select technical design parameters in agile development processes. The methodology can be applied in the cyclical sprint planning that aims at defining the scope of the next prototype to be developed. As outlined above, the major paradigms of value generation, informational dependencies as well as lead-time and effort are crucial when adapting agile for technical systems and are consequently implemented in the methodology. These paradigms are operationalized to explicitly address the mentioned major objectives of agile development processes, which are currently showing are large gap between expected benefit and realized benefit in industrial practice. The methodology is applied to the real development process of an RGB laser light source for digital cinema projectors, which is summarized as a case study in the paper. Insights from this application are equally discussed as the resulting next steps in further developing and aligning the methodology to the needs of industrial practice.

This chapter discusses the integration of ethical deliberations within agile software development processes. It emphasizes the importance of considering ethical implications during the development of software, not just AI. The chapter proposes modes of reflection and deliberation that include disclosive, weighing, and applicative modes of contemplation. It argues that these three kinds of thinking are guided by different normative values. The chapter suggests that agile development is an excellent starting point for implementing ethical deliberations, as it allows for continuous reflection and learning. It also proposes that development teams can perform this task themselves up to a point with proper guidance. This section further discusses the potential of agile processes to naturally accommodate ethical deliberation. However, it also acknowledges the challenges associated with implementing agile processes, especially in the context of machine learning models.

Software testing process is an important factor affecting the quality of software testing, which plays an important role in the entire software development life cycle. In order to achieve a precise result of testing, different software testing process model will be chosen in different software development process for testing. Traditional testing process model will be chosen in traditional software development, and agile testing process model will be chosen in agile software development. However, there is no kind of testing process model proposed for a special software development which is a combination of traditional software development and agile software development. This article will propose a hybrid software testing process model aiming at a combination of traditional software development model and agile software development model. In the following sections, traditional testing process model and agile testing process model will be introduced respectively in the first place. Most attentions will be paid to the introduction and analysis of the hybrid software testing process model through one case. Furthermore, we will discuss the relationship of the data tracing involved in the testing process model.

The lack of user engagement, the absence of user feedback, incomplete and continuously changing user requirements are among the critical concerns that cause projects to fail. User-centered design (UCD) and agile software development are two iterative approaches that have been proposed to overcome such concerns. UCD is a design process focusing on user research, user interface design and usability evaluation. Introduced by software engineering practitioners, agile refers to a number of iterative and incremental software development practices that emphasize people’s needs, communication between developers and stakeholders and the ability to adapt to change. In both the agile and UCD communities, however, a full understanding of user requirements is often seen as incompatible with early and quick development iterations. We performed a literature review aiming to identify how agile teams have integrated UCD tools into their agile software development process to a better understanding of the user requirements without losing sight of the agile values and principles. UCD tools adaptations and minimal-up-front design applied in agile development are among the approaches discovered in this study. The findings could lead to a comprehensive user-centric software engineering that will overcome inherent problems faced by agile teams to understand user needs, priorities and goals.

Despite of many criticisms, agile software development (Beck et al., Manifesto for Agile Software Development, http://agilemanifesto.org, [1]) philosophy has been proved to be quite successful to increase the project success rate up to a significant extent. The primary reasons behind the criticism of agile are the strong violation of the traditional disciplined software engineering theories, principles and practices. The goal of this research paper is to establish the fact that agility may also be achieved by following traditional process models especially with BRIDGE (Mandal, 2009 IEEE International Advance Computing Conference (IACC 2009) Patiala, India, [2]) process model. Hence, the aim of this paper is to integrate the agile and traditional disciplined software development process models and establish the compatibility between both the approaches. At the beginning, we have explored the objectives and principles of agile software development. Next, we briefly discussed the BRIDGE process model and further justified that--following BRIDGE process model, the philosophy of agile may also be achieved and conclude that BRIDGE model has both the capability of traditional software development process model as well as of the agile process.

Software Testing from an Agile and Traditional view

Agile practices have recently gained popularity among large number of companies as a mechanism for reducing cost and increasing ability to handle change in dynamic market conditions. Based on the principles of the Agile manifesto [1, 2], researchers and practitioners have proposed several software development approaches such as Extreme Programming, Scrum and Feature-Driven Development. These and other agile approaches have had significant impact on industrial software development practices. However, there is also a significant concern and perplexity about the role and importance of the issues related to a system’s software architecture, which is considered one of the most important initial design artefacts. It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. Many practitioners of Agile approaches appear to view software architecture in the context of the plan-driven development paradigm [3]. For them, upfront design and evaluation of software architecture requires too much work, which may have very little value to the customers of a system. Hence, they perceive architectural work as part of high ceremony processes, which usually require large amount of documentation. We maintain that these two seemingly opposing views to software engineering can be integrated but it requires that experts from both fields work together to overcome evident challenges in bridging these two paradigms together. Indeed, software architecture researchers and practitioners appear to believe that sound architectural practices cannot be followed using Agile approaches. However, these two extreme views of Agile and architecture appear to neglect that many agile experts emphasises the importance of paying attention to good design and architecture early in the development process [4, 5]. Recently, there is growing recognition of the importance of paying more attention to architectural aspects in agile approaches [3, 6, 7]. We argue that there is a vital need for devising a research agenda for identifying and dealing with architecture-centric challenges in agile software development. Such research agenda should make it possible to guide the future research on integrating architecture-centric methods in agile approaches and give advice to the software industry on dealing with architecture related challenges. Some of the questions to stimulate discussion in the workshop are: What is the role of software architecture in Agile software development? What are the key architecture-centric challenges and potential solutions in Agile software development projects? What is the strength of the evidence that attention to architectural issues can be counterproductive in Agile development or vice versa? What are the prerequisites for integrating Architecture-Centric methods in agile development and potential implications of such integration?

Currently, it is crucial to develop a complex software on time. Agile software development methodologies provide methods to develop a system in term of time and cost-saving but it has been criticized for software quality management. In this paper, a case study is used to find out the need of NFR change impact traceability approach in most of Agile software methodology. This case study was conducted in an undergraduate course that trained the students on how to develop software using Agile process model.This case study has been conducted for 4 months in an undergraduate-level course, Application Development. The samples of this case study are among Year 3 undergraduate students. The case study shows the lack of traceability techniques in the existing Agile process model (SFDD- Secured Feature Driven Development) that result to non-awareness of NFR change impact during development. Based on the case study mentioned the main objective of the case study conducted in survey is to empirically test the theoretical constructs and the hypothesized relationships of the research issues that concern on the lack of change impact management towards NFR in Agile Software Methodology. TANC (Traceability for Agile Non-Functional Requirement Change Impact) model offered techniques in tracing change impact during the agile development process. Therefore, the result of the case study, a traceability process model needs to design in order to tackle the NFR change impact issues in Agile software development.

Agile software development methods have been proposed as the way to address the problem of delivering high-quality software on time under constantly and rapidly changing requirements in business and IT environments. An agile development process is characterized by extensive coding practice, intensive communication between stakeholders, fast iterative cycles, small and flexible teams, and minimal efforts in system modeling and architectural design. This paper presents the state-of-the-art of agile methods and analyzes them along the selected criteria that highlight different aspects of their theory and practice. Certain limitations of agile methods are identified. The chapter presents the component paradigm as a way of balancing traditional (model-driven or plan-driven) and agile development, depending on the project settings. Service-based component concepts applied at the level of modeling, architectural design and development can ensure and strengthen agile development principles and practices, and at the same time introduce necessary agility to more traditional development. By using components, the software development process can easily scale in size, robustness, and the level of details. This provides an effective balance between the requirements for agility in software development and needs for a disciplined, design-driven way of building complex software.Request access from your librarian to read this chapter's full text.

Agile software engineering increasingly seeks to incorporate design modification and continuous refactoring in order to maintain code quality even in highly dynamic environments. However, there does not currently appear to be an industry-wide consensus on how to do this and research in this area expresses conflicting opinions. This paper presents an empirical study based upon an industry survey aimed at understanding the different ways that refactoring is thought of by the different people carrying out different roles in agile processes and how these different people weigh the importance of refactoring versus other kinds of tasks in the process. The study found good support for the importance of refactoring, but most respondents agreed that deferred refactoring impacts the agility of their process. Thus there was no universally agreed-upon strategy for planning refactoring. The survey findings also indicated that different roles have different perspectives on the different kinds of tasks in an agile process although all seem to want to increase the priority given to refactoring during planning for the iterations in agile development. Analysis of the survey raised many interesting questions suggesting the need for a considerable amount of future research.

Organizations of all sorts adopt agile software development, but they rarely implement it “by the book.” Instead, agile practices evolve after initial adoption and often drift in different directions as organizations translate agile into their institutional environments. We studied the implementation of agile development in four organizations from much different institutional contexts: a startup technology company, a consulting firm, a government organization, and an industrial manufacturer. We found two core dimensions of their institutional contexts that shape agile translation: dynamism and pluralism. Dynamism refers to how fast requirements and environments change, and pluralism refers to how many diverse stakeholders are involved. These two dimensions influence the direction of agile translation. We show that agile practices evolve through a “ratcheting” process, whereby a sequence of incremental, interdependent changes gradually move teams closer to or further away from canonical agile practices. High pluralism in the institutional context, for example, tends to increase documentation, whereas low dynamism appears to slow iteration cycles. Agile software development is no longer limited to startups or software teams; it is adapted by all sorts of organizations as a way to flexibly innovate. Understanding why agile evolves differently across contexts helps managers move beyond one-size-fits-all prescriptions and set realistic expectations for agile development in their organizations.

Agile software development has become the standard in many companies. While there are reports of major improvements with agile development over traditional development, many teams still strive to work effectively as a team. A multiple case study in two companies discovered challenges related to communication, learning and selecting the tasks according to the priority list. For example, the fact that the developers were not actively involved in the planning process, resulted in weak team orientation; even though the teams had identified and discussed recurring problems, they found it difficult to improve their teamwork practices; and because customers and support communicated tasks directly to the developers and developers chose tasks according to interest and expertise, following the priority list became difficult. We provide practical suggestions for teamwork in agile software development that intend to overcome these problems and strengthen team orientation and team learning in order to achieve effective agile teams.KeywordsTeamworkTeam orientationTeam communicationTeam learningAgile methodsAgile Software developmentScrumKanban

[Context] In agile software development, requirements are frequently represented in lightweight artifacts such as user stories (USs). To support their validation, USs may be complemented with additional artifacts such as acceptance criteria and test cases. [Problem] Existing studies propose frameworks for US writing, or investigate high-level factors that contribute to productivity, such as teamwork and support from management. However, empirical evidence on the impact of requirements artifacts on team efficiency is scarce. [Method] Through a mixed-methods case study at a large Dutch organization, we investigate how the use of requirements artifacts affects efficiency. We collected data from eight agile teams: 1,345 USs from nineteen sprints, US quality indicators, the quantity of associated acceptance criteria and test cases, and cycle time. We statistically analyzed the existence of correlations between these variables, and we triangulated our results through interviews with product owners and scrum masters from the involved teams. [Findings] Our employed indicators for US quality do not seem to have an effect on on-time completion, with our interviewees highlighting the trade-off between investing on writing quality and short-term efficiency. We found, instead, that the existence of acceptance criteria may be a relevant factor for on-time completion, as confirmed both by statistical tests and the interviewees.

This position paper presents an emerging research based on a set of expressed statements and impressions from conducted empirical research during the past few years. Agile software development emphasizes on social aspects through its methods and principles. In order to improve the processes within the organization and amongst various stakeholders, there is a need for social processes and various types of interactions to be studied in the context of agile development. The objective of this paper is to present the need to conduct more empirical studies to investigate the socialness of software engineering processes and in particular the role of various type of social interactions in improving development processes and therefore creating more value in organizations.

Obstacles to decision making in Agile software development teams