Webbapplikationer bygger på många olika webbramar och utvecklare har en mängd olika webbramverk att välja mellan när de utvecklar en webbapplikation. Två populära webbramverk som finns på marknaden är NextJS och Create React App (CRA). Varje ramverk har sina egna för- och nackdelar i olika perspektiv. Syftet med denna studie är att granska om det finns några skillnader i dessa två populära webbramverk ur ett kontinuerligt integrations och kontinuerligt leverans-perspektiv med ett fokus på att kolla närmare på skillnaderna inom utvecklingsprocessen vid utökningar av applikationer och den tid det tar att bygga och driftsätta applikationer i de olika ramverken. För att få kunskap om ämnet så har en teoretisk studie av webbaserade källor gjorts och en applikation har skapats i de båda ramarverken för att sedan utvidgas med ytterligare verktyg för att kunna utföra en jämförelse. Studien visar att ramverken resulterar i liknande byggoch driftsättningstider men skiljer sig dock åt gällande konfigurationer när applikationerna utökades och att NextJS gav en enklare åtkomst åt konfigurering. / Web applications are built on numerous of different web frameworks and developers have a plethora of different web frameworks to choose from when developing a web application. Two popular web frameworks on the market are NextJS and Create React App (CRA). Each framework has its own advantages and disadvantages in different perspectives. The objective of this study is to review if there are any differences in these two popular web frameworks in a continuous integration and continuous delivery perspective looking closer at the differences in the development process when extending applications and the time it takes to build and deploy applications in the different frameworks. To gain knowledge about the subject, a theoretical study on web based sources has been made and an application has been created in both framework to then be extended with further tools to be able to perform the comparison. The study shows that the frameworks results in similar build and deployment times but does however differ in the configurations when extending applications and that NextJS did provide a more straightforward configuration.

AbstractThe increasing amount of data available from software systems has given a unique opportunity for software development organizations to make use of it in decision-making. There are several types of data such as bug reports, website interaction information, product usage extent or test results coming into software-intensive companies and there is a perceived lack of structure associated with the data. The data is mostly scattered and not in an organized form to be utilized further. The data, if analyzed in an effective way, can be useful for many purposes, especially in decision-making. The decisions can be on the level of business or on the level of product execution. In this paper, through a literature review, an interview study and a qualitative analysis we categorize different types data that organizations nowadays collect. Based on the categorization we order the different types of decisions that are generally taken in a software development process cycle. Combining the two we create a model to explain a recommended process of handling the surge of data and making effective use of it. The model is a tool to help both practitioners and academicians who want to have a clearer understanding of which type of data can best be used for which type of decisions. An outline of how further research can be conducted in the area is also highlighted.

The current migration of companies towards continuous integration and delivery as well all service-oriented business models brings great benefits but also challenges. One challenge that a company striving to establish continuous practices is the need for pipeline traceability, which can bring great enhancements to continuous integration and delivery pipelines as well as offer a competitive edge. This exploratory case study looks at the current and desired states at Axis Communications, a global leader in network video solutions based in Lund, Sweden. It further evaluates the practical and organizational aspects of the adoption of the Eiffel protocol in the company’s pipeline tools through developing a proof-of-concept Eiffel plugin for Artifactory. Based on the discovered technical and organizational needs and obstacles, it draws conclusions and makes recommendations on a possible strategy when introducing Eiffel in a company.

The thesis deals with the reengineering of the Umbrela questionnaire system. The text describes the reasons for reengineering, technology selection, application design, description of basic application blocks and implementation. The work also mentions proposals for improvement of the overall project and its further development.

Continuous Integration (CI) has become an essential practice in software development, allowing teams to integrate code changes frequently and detect issues early. However, the selection of proper test cases for CI remains a challenge, as it requires balancing the need for thorough testing with the minimization of execution time and resources. This study proposes a practical and lightweight approach that leverages Reinforcement Learning with a linear function approximator for test case selection in CI. Several models are created where each one focuses on a different feature set. The proposed method aims to optimize the selection of test cases by learning from past CI outcomes, both the historical data of the test cases and the coverage data of the source code, and dynamically adapting the models for encountering new test cases and modified source code. Through experimentation and comparison between the models, the study demonstrates which feature set is optimal and efficient. The result indicates that Reinforcement Learning with a linear function approximator using coverage information can effectively assist in selecting test cases in CI, leading to enhanced software quality and development efficiency.

In this thesis the application of software defect prediction to predict unit test failure is investigated. Data for this purpose was collected from a Continuous Integration development environment. Experiments were performed using semantic features from the source code. As the data was imbalanced with defective samples being in minority different degrees of oversampling were also evaluated. The data collection process revealed that even though several different code commits were available few ever failed a unit test. Difficulties with linking a failure to a specific file were also encountered. The machine learning model used in the project produced poor results when compared against related work, from which it was based on. In F-measure, it on average achieve 53% of the mean performance of state-of-the-art for software defect prediction on bugs in Java source files. Specifically, it would appear that very little information was available for the model to learn defects in files not present in training data. / I denna avhandling undersöks applikationen av prognos för mjukvarudefekter för att förutse enhetstestfel. Data för detta syfte samlades in från en utvecklingsmiljö med kontinuerlig integration. Experimenten utfördes med användning av semantiska särdrag samlade från källkod. Då data var obalanserat med defekta exempel i minoritet evaluerades olika grader av översampling. Datainsamlingsprocessen visade att även om det fanns många kodinlämningar så misslyckades få någonsin ett enhetstest. Svårigheter med att länka testmisslyckanden till en specifik fil påträffades också. Den använda maskininlärningsmodellen uppvisade också dåliga resultat i jämförelse med relaterade värk. Mätt i F-measure uppnåddes i genomsnitt 53% av genomsnittlig prestandan av bästa möjliga prognos av mjukvarudefekter av buggar i Java källkod. Specifikt så framträdde det att väldigt lite information verkar finnas för modellen att lära sig defekter i filer som ej fanns med i träningsdata.

When designing a software, it was commonplace to use specialised techniques to ensure quality of the final product. Continuous Integration (CI) provides developers a strategy by allowing for teams to continuously add to their project daily without conflicting with prior work. An automated process would check that these new integration additions are functional so that any faults were quickly identified for correction. Continuous Integration played a pivotal role in organisations that developed software solutions for their own or their customers’ processes. It comes as no shock that an abundance of research illustrates its importance and success in software development. Automated testing was praised so much so that there was a distinct lack of negatives particularly in the professional industry. The goal of this study was to gather knowledge about automated testing in a work environment so that principles for implementing automated testing. This was conducted by a qualitative case study while looking at the developer/user perspective. This was done by conducting semi-structured interviews with employees working with automated testing in a telecommunication organisation. The study’s results presented eight themes that the informants and prior literature studies observed as issues of importance. These themes showed that the automated testing had experienced problems in practice that were not noticed in academical papers and for that, seven recommendations were presented for other organisations to be observant of.

Static Application Security Testing Tools (SAST) is a security tool that claims to help with security in an IT system. Static Application Security Testing tools are technical solutions that operate within the continuous integration of the system. The tool uses frameworks such as OWASP and CWE to detect common vulnerabilities in the codebase by analysing code in the building and testing phase of continuous integration. The problem with SAST tools is that there are many different beliefs surrounding them. Some say they are crucial for security, while some believe they are less helpful and can even inhibit projects by introducing false positives. This thesis determines if SAST tools are an effective solution to security problems within in an IT system. The focus was on logistics- and infrastructure-oriented operations, which the partner company Triona operates within. We use literature review to look at previously similarly conducted research combined with interviews with experienced people within the fields. This gives qualitative results that coupled with previous research can be generalized. The results show that SAST tools are effective tools if used responsibly. Both the literature and interviews conclude that SAST tools are not enough on their own to satisfy the security requirements but must be combined with responsible use of the tools as well as code reviews and other types of testing. SAST tools are also shown to have some problems, mainly false positives, and false negatives. There are also problems related to the implementation of the tools. These problems are costs that comes with implementation, as well as the time spent on it. Other problems are bad communication with developer teams that led to developers not knowing what to do in case of errors shown by the tool. Interviews conducted provides information that SAST tools are not only tools for security but also helps with manageability of code bases.

Software Quality is a key priority in any company involves with software development. Quality which can be describe as a distinguish feature of a software, has a high competitive advantage for most business organisations, especially during this turbulent time with the world battling pandemic. Software has grown and diversifies to ease our day to day life, therefore, the role of quality assurance activities has increase and become extremely important and complex. However, successful software which meets customer’s requirement and expectation depends on the quality of the software. In order to maintain the quality of their applications, several development industries have revised their quality procedure. DevOps and agile development have greatly improved the success rate of software projects with the introduction of test coverage measures. The purpose of this thesis is to implement existing test coverage metrics which are used for improving and measuring the quality of software in order to help reduce excess time consumption, overshooting of budget and maintain scope within requirement. The software quality metrics selected for this study is the ISO 9000 and the core focus area to implement this quality metrics is on unit test, integration test and acceptance test. For this requirement, a design workflow using a flowchart to get a clear description of the work process will be created, configuration of DevOps environment for the pipelines which combines continuous integration and continuous development (CI/CD) to test and build our code constantly and consistently with SonarCloud. Finally, configuration of TestProject for creating automated test script and automated acceptance test execution with automatic generation of test report as well as evaluating the quality of the software product based on the test execution and coverage result. The documentation for this implementation will contain all the steps necessary to configure the test coverage metrics. The metrics will be used to create unit tests, integration tests, and acceptance tests for web applications that run on a variety of browsers and versions, including Chrome Version 103.0.1264.37, Edge Version 103.0.5060.114, and Firefox Version 103.0.

Flaky tests are non-deterministic tests that both pass and fail when no new code changes have been introduced to the code under test. This is a widespread problem for the Continuous Integration community where the underlying idea is that code is only integrated if all test cases pass. Debugging and eradicating flaky tests is hard and time-consuming and if ignored may introduce bugs. Due to flaky tests, Continuous Integration systems are at risk of decreasing either productivity or quality, properties it claims to provide. Prior research suggests a link between 4 root causes for flaky tests and 5 different test smells, i.e. anti-code patterns. Unfortunately, difficulties in reproducing flaky tests found in the study make this connection ambiguous. This thesis intends to validate this relationship by re-implementing the test smells in a static analyser named FlakyHoover and detecting them on a new dataset consisting of order-dependent and non-order-dependent flaky tests. Analysis of the test smell distribution over order and non-order-dependent flaky tests makes it possible to determine the relationship between test smells and root causes for flaky tests. The findings suggest that there may exist a correlation between 3/5 test smells and certain types of root causes for flaky tests. However further research is required to determine the studied test smells relation to flaky tests.