On this site, there is only displayed the English speaking sessions of the OOP 2021 Digital. You can find all conference sessions, including the German speaking ones, here.
Track: Testing & Quality
- Back to Architecture
- Business Agility
- Design Erosion & Learning from Failure
- DevOps & Continuous Everything
- Diversity & Inclusion
- Domain-Driven Design moving forward
- Full Day Tutorial
- Fusion: IT-Future-Society
- Half Day Tutorial
- Modern C++ Programming
- Modern Enterprise Architecture
- Product Discovery, Customer Centricity & RE
- Signature Track: Back to the Future
- Social Integration
- Special Event
- Testing & Quality
- Trends & Techniques
80% of machine learning is said to be data wrangling. Is all this wasted effort? Hardly - often the journey really is its own reward.
In this talk, we'll briefly describe a machine learning project that predicts the outcome of test cases in a large-scale software development cycle. We'll then show what we gained from collecting the necessary data and how these insights can have lasting impact on the day-to-day work of developers, testers and architects. This includes a quick answer to the well-known question: Whose defect is it anyway?
Target Audience: Developers, Testers, Architects
Prerequisites: Basic knowledge of software development and testing and an interest in data analytics
Data science folk wisdom holds that at least 80% of machine learning consists of data wrangling, i.e. finding, integrating, annotating, and cleaning the necessary data.
While sometimes viewed as less "glorious" than the deployment of powerful models, this journey has its own rewards as well.
Benefits may sometimes be somewhat expectable, if still non-trivial, like data cleaning potentially exposing errors in underlying data bases.
In other cases, though, there may be some low-hanging fruit a casual glance might miss even though they are indeed rewarding.
Data integration often reveals opportunities for statistical analyses that are relatively simple, but may still have high impact.
In this talk, we'll start at the destination: the result of a machine learning project where we successfully predicted test results from code changes.
A necessary task was the integration of several data sources from the full software development cycle - from code to testing to release in a large industry project with more than 500 developers.
Naturally, this required all typical steps in the data science cycle: building up domain knowledge and problem understanding, both semantic and technical data integration, data base architecture and administration, machine learning feature design, model training and evaluation, and communicating results to stakeholders.
These steps yielded several benefits, on which we will focus in our talk.
Among others these include data quality insights (e.g. about actual "back to the future" timestamps), and new analyses which were made possible by a unified view of the data (e.g. survival analysis of defects).
Last but not least, we demonstrate a simple answer to a well-known question, especially in larger software development contexts: Whose defect is it anyway - how can we avoid assigning defects to teams that have nothing to do with them?
Thanks to the integrated information sources from systems concerned with version control, test result logging, and defect management, we are able to support the claims made in this talk with statistics taken from 6 years of real-world data.
The Test Pyramid is an efficient and effective approach for Software Testing but does not come with any details about concrete test methods or fixtures.
In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to elaborate a specific test strategy for your software product in a simple manner.
Target Audience: Architects, Developers, QA Engineers
Prerequisites: Basic knowledge in Software Architecture and QA Engineering
Software tests have to specify the behaviour of your product as extensive and reliable as possible. At the same time their implementation and maintenance costs should be kept at a minimum.
As Kent Beck said before: "I get paid for code that works, not for tests".
The Test Pyramid is a proven approach for this problem but leaves a lot of room for interpretation when elaborating a test strategy for your product.
Furthermore there are a lot of partly contradictory definitions of Unit, Service and Integration Tests and variations like “Test Diamond” and “Test Trophy” make it even more confusing. So, how do we get from the Test Pyramid to a concrete test strategy?
In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to obtain a test concept tailored for your product. Examples taken from a recent project will demonstrate how this approach balances test coverage, maintainability and development costs.
What would your first thought be when you are told there is no testing or quality structure in a team? How would you inspire a team to follow vital processes to thoroughly test a data science model?
I would like to share my knowledge about testing a model in a data science team.
Data science is a very interesting area to explore. It presents testing challenges that are quite different from “traditional” software applications. I will share my journey introducing testing activities to help build quality into a data science model.
Target Audience: Testers, QA, Developers, delivery managers, product owners, scrum masters, everyone is welcome
Prerequisites: QA, Testing
She has been awarded a Business Computing degree from Queen Mary University Of London. She thoroughly enjoyed the technical aspects of the computing side of her degree applied those skills to the business side of her degree.
She will bring an innovative and valuable contribution to any programme through her aptitude for IT, her interest in the business world and interpersonal skills. She is and will be a practical and valuable member of any team, as she is able to work effectively and efficiently with others to complete any given task.
She has excellent communication skills gained from both academic and non-academic environments.
Raiffeisen Bank International (RBI) started in 2017 with “Group Digital Solutions” a journey in order not to oversleep the digitization of the banking industry.
Due to new approaches such as DevSecOps & Continuous Testing, the topic of software tests, whether manual or automated, had to be completely redesigned and implemented.
This talk gives insights into the test strategy & the fullstack test automation architecture that were used.
Target audience: testers, developers, architects, managers
So that Raiffeisen Bank International can keep up with digitization in the banking sector, the company relies on the use of native apps, microservices and REST APIs in the Amazon cloud when implementing its mobile banking strategy.
In order to support the DevOps mantra "Automate everything", a full stack test automation strategy was developed that is based on open source tools and takes all components of the system architecture into account.
The independent services of the microservice architecture make additional interfaces visible that are not available in a monolithic architecture. The advantage is that they can be deployed and tested independently of each other.
Testing these systems is much more complex than testing a conventional monolithic application and needs additional demands on test automation, with classic integration tests being even more important for the overall structure.
These integration tests were usefully supplemented by consumer contract tests. But end-2-end tests should not be missing either, since an effective test strategy must take into account both the isolated testing of individual services and the verification of the overall system behavior.
Aligning test automation with the classic test pyramid is a very useful approach if the individual layers are seen as the basis for “what is being tested” and not as a measure of the number of tests. Because the old wisdom still counts: “Quality over quantity!”.
Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.
Target Audience: Testers, Quality assurance, Architects, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: Testing basic know-how
Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. There are many open questions about the validation of autonomous systems: How to define reliability? How to trace back decision making and judge afterwards about it? How to supervise? Or, how to define liability in the event of failure? The underlying algorithms are difficult to understand and thus intransparent. Traditional validations are complex, expensive and therefore expensive. In addition, no repeatable effective coverage for regression strategies for upgrades and updates is available, thus limiting OTA and continuous deployment.
With artificial intelligence and machine learning, we need to satisfy algorithmic transparency. For instance, what are the rule in an obviously not anymore algorithmically tangible neural network to determine who gets a credit or how an autonomous vehicle might react with several hazards at the same time? Classic traceability and regression testing will certainly not work. Rather, future verification and validation methods and tools will include more intelligence based on big data exploits, business intelligence, and their own learning, to learn and improve about software quality in a dynamic way.
Verification and validation depend on many factors. Every organization implements its own methodology and development environment, based on a combination of several of the tools presented in this presentation. It is however relevant to not only deploy tools, but also build the necessary verification and validation competences. Too often we see solid tool chains, but no tangible test strategy. To mitigate these pure human risks, software must increasingly be capable to automatically detect its own defects and failure points.
Various new intelligent validation methods and tools are evolving which can assist in a smart validation of autonomous systems.
This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.