The sixth edition of the Project Quality Day has the theme “quality throughout development – and beyond.” Enter your talks about quality from a developer’s perspective, quality for modern pipelines, testing in continuous delivery, testing in production, testing in the cloud, and integrating tests and testers into modern processes and technologies.
Do you want to engage your team in their testing efforts? Do you want to generate feedback from your stakeholders and/or users in an interactive way? Do you want to make your testing efforts more fun? Or are you looking to train your users in a different way?
You can achieve all of the above! Really!
While driving our car on the highway we know that we can switch lanes, we know what speed we are allowed to drive and we know what our car can do for us on the highway. A lot of times we know that in our subconsciousness, but what if you look at that from a conscious level? Would you maybe act differently at certain moments?
Everything we do takes place in a certain context. Whether it's doing grocery shopping, developing software or driving your car. The context determines how we look at things, how we interact with them and it even determines how we behave.
Do you know what you need to test? Do you bring focus to testing within your team? Do you prioritize in the right way?
In this hands-on workshop, you will find an answer to the following question:
"How do we test the risks that affect the aspects of our product that matter most?"
We will give you a way to create a test strategy, a way to distinguish issues that matter from those that don't matter that much.
We will give you a way to substantiate your test approach, and a way to discuss this with the business and the team.
We’ve all seen it: development work is done and the testing column is full. It’s a common experience that many stories are ready to be tested just in the last few days of the sprint. Even though it feels like the sprint is finished, the stories are not done and testing seems to be the bottleneck. It’s frustrating for everyone.
Handling Open Source Software in a compliant way requires a good Open Source Management that keeps you busy already. On the technical side, the component often can be downloaded, integrated and functionally tested within minutes. But what about the so called non-functional requirements.
It does not matter, if you work in a waterfall or agile working environment, at one point the focus of continuous improvement (you do improvements, right?) becomes your test infrastructure. It needs to grow, evolve and scale with you, otherwise it will slow you down and become a bottleneck.
I had the opportunity to observe and participate over three years how a company changed their test infrastructure in terms of overarching concept and underlying technology base.
Quality Assurance is Verification & Validation.
Verification – Are we building the product right?
Validation – Are we building the right product?
While there is a lot of emphasis on validation, we need a scientific way to improve our verification process.
With Agile principle in place, when we release a Minimum Viable Product to the customers, we get a feedback that helps us with validation. While validation is important and the core emphasis of practices like DoD, Acceptance criteria, System Demo.
When I started at my current employer five years ago the CI system consisted of an outdated Jenkins installation on a PC which was located under the desk of a developer. Builds were triggered three times a day, so a developer had to wait multiple hours after a commit until the feedback arrived. The builds couldn’t be reproduced locally, so debugging was at times done via console logging on the CI system.