https://www.mdu.se/

Forty years since IEEE Software Magazine began, its impact is shown today. We must constantly ask ourselves if we are building the product right and if are we building the right products, as new ways of developing software challenges both research and industry.

Achieving automatic, valid, verified answers from generative AI models, is a goal that many of us are working on. We must find a way to make sure we have reliable and trustworthy results despite numerous challenges in the field.

This issue is tackling the Future of Software Engineering Education and Training in the Age of AI. Generative AI tools will change how we learn. A new, more precise language is needed to communicate better with AI tools. Learn prompt engineering!- Sigrid Eldh, EIC IEEE Software.

Industrial embedded systems often require special-ized hardware. However, software engineers have access to such domain-specific hardware only at the continuous integration (CI) stage and have to use simulated hardware otherwise. This results in a higher proportion of compilation errors at the CI stage than in other types of systems, warranting a deeper study. To this end, we create a CI diagnostics solution called 'Shadow Job' that analyzes our industrial CI system. We collected over 40000 builds from 4 projects from the product source code and categorized the compilation errors into 14 error types, showing that the five most common ones comprise 89 % of all compilation errors. Additionally, we analyze the resolution time, size, and distance for each error type, to see if different types of compilation errors are easier to localize or repair than others. Our results show that the resolution time, size, and distance are independent of each other. Our research also provides insights into the human effort required to fix the most common industrial compilation errors. We also identify the most promising directions for future research on fault localization.

What is the best pathway to acquire new knowledge, create a positive work-life balance, and to plan and adapt successfully? Acceptance, tolerance, and inclusiveness: embracing these practices is key to transforming our outlook and attaining higher motivation and great results.

Impact can be anything from a software solution, a product, or even changing people's minds about something. Successfully turning an idea into something that has an impact requires alignment among many contributing factors. This issue of IEEE Software gives us more insight into this journey from idea to impact.

It is the time of trust and transformation in software. We want explainable AI to assist us in dialogue, write our programs, test our software, and improve how we communicate. It is the time of digitalization, but we must ask ourselves - on what data in what format, when do we collect it, and what is the source? Does “data” make sense? Every action can be automated, should eventually be automated, and as such should be traceable and explainable. The transformation of software – and how we can now train, and feedback in a fast way, enable us to not only utilize existing technologies, but also aids us in faster embracing new technologies. This transformation is much to slow even if things change at a lightning speed. Change is the only thing we can be sure will happen. Evaluating and assessing quality of software sounds easy but is only as good as you design it to be. We, often simplify the problem so we can move forward, but it is the complications that is the real issue – our context, our combination of tools, languages, hardware, history, and way of working. We simply need the labeling, the meta-data, the context – and this data in a form with “many” perspectives to draw the more “accurate” scientific picture. Having a multi-facetted perspective is important when analyzing complex contexts. In software, listening skills and asking the right questions to the right people is often invaluable to complement blunt data. On the other side - much information is probably missing as you are too easily getting “only” what you asked for. So, we cannot judge what we cannot observe – and analyzing this data, is another issue all together. We need to know what is right – because if we cannot trust the source – or double check the outcome, how would we know it is not just a “fake” data? What does the outlier really mean? Is it a sign of a new trend is it the first time we capture this odd event? Therefore, it is easy to lose perspective in a fast-changing world. Despite drowning in tools, we still miss a lot of them. The threshold of using a tool is high, as we cannot trust them, and we cannot be sure that the data these tools collect does represent what we want to investigate. Therefore, the role of the scientist is more important than ever. Trusting the scientific process, utilizing multiple methods, and combining them is the receipt! Another goal is doing our best to select topics and collaborators – as building better software (quality) for humanity. It starts with you and me. I hope I will in this context be able to touch upon areas like security, testing, automation, AI/ML, ethics and “human in the loop”, analysis, tools, and technical debt, with a focus on evaluations and assessments.

Testing large complex systems in an agile way of working was a tough transition for systems having large active legacy and honouring backward compatibility. Transition from manual test to full test execution automation resulted in increased speed and manifested technical debt. The agile way of working in continuous build and test, creates a lot of repetition by execution of the same tests. Overlap between agile teams producing similar test cases, causes a constant growth of the test suites. Despite the obvious improvement of automating millions of test cases, the numbers provide a false sense of security for management on how well the system is tested. The causes of technical debt should be addressed, instead of managing the symptoms. Technical debt in software testing could be addressed by refactoring, supported by known techniques like cloning, similarity analysis, test suite reduction, optimization and reducing known test smells. Increasing the system quality can also be improved by utilizing metrics, e.g. code coverage and mutation score or use one of the many automated test design technologies. Why this is not addressed in the industry has many causes. In this paper we describe observations from several industries, with the focus on large complex systems. The contribution lies in reflecting on observations made in the last decade, and providing a vision which identifies improvements in the area of test automation and technical debt in software test, i.e. test code, test suites, test organisation, strategy and execution. Our conclusion is that many test technologies are now mature enough to be brought into regular use. The main hindrance is skills and incentive to do so for the developer, as well as a lack of well educated testers. 

Faults in the automated continuous integration (CI) process can seriously impact the development of industrial code. To reduce manual intervention in automated CI processes, we want to understand better the CI systems' failure distribution to improve efficiency, reliability, and maintainability. This paper investigates failures in CI in four large industrial projects. We gather 11 731 builds over six months, identifying 1 414 failing builds. We also identify the distribution of different types of build failures in each of the four CI projects. Our results show that compilation is the most significant individual cause of failure with 47 %, followed by testing at 36 %. The checkout step with associated checks also incurs a non-negligible portion of failures with 12 %. Furthermore, we identify 14 distinct types of failures in the testing step. We conclude that configuration problems are a significant issue, as pipeline scripting and dependency errors make up a large number of failures. © 2022 IEEE.