acceptance criteria

The Business Value of Quality

/ Finn Lorbeer / Leave a comment

Traditionally, when talking about the quality of our software, of our product, we discuss how we can ensure a certain level of quality. In this context quality is seen as a minimum requirement. The business value of quality from this perspective is in the prevention of potential losses, e.g. by downtime of a platform.
Today, we can see that this picture shifts dramatically. More and more companies move to a devops culture and we can see the same “shift left” happening in the QA space. Likewise, today’s businesses need to react fast to changes in the market. New technologies emerge faster than companies can pick them up.
We want to talk about a high quality product in this context. The high standard in our products does not just ensure our business and mitigate potential risk. High quality in our software allows us to build better software faster. It makes today’s product more resilient to changes in the future. We change our perspective and do not think how to ensure a certain (minimum) level of quality. But how high quality enables our business.

This talk is a shared effort with my colleague Nina.

Joint forces of the analysts: improving the quality of software even before its built

/ Finn Lorbeer / Leave a comment

Sometimes people say that QAs are the headlights of a project. The developers are the train engine and the BAs are the map of the surrounding area – they know where the train in the night shall ride. And it will somehow get moving. But with headlights that inform you early on about potential obstacles you can maybe find another route on your map.

Screen Shot 2019-02-15 at 20.05.02.png

Source: wallpaperpulse.com

Sometimes people say that QAs and BAs and devs work on the same product – just in different times: The BAs have really good idea what is coming next. They are constantly thinking about the product in one month – rather in the future. Devs are working on the product of the next days, max. next week – thus the immediate future. And you as a QA usually know best how the product behaves today – you know about the present product.

When it behaves unintended you talk to the same stakeholder as a BA who identifies intended behavior changes to be implemented. It is incredible useful to bring these perspectives together!

Usually, QAs know their way around today’s product in details and can point out weaknesses that can be fixed with new requirements as well as shortcuts when introducing new features. That is all incredible valuable for the BA. The outcome for the QA? If you consequently collaborate on analysis and story writing (to some extent, it’s not necessary to type the story together) you can think about weird edge cases and scenarios already long before the story is implemented and discuss the desired behavior with the BA right away. Baking quality in can be so timesaving!

Again, you cannot make up all possibilities in your head, you will still need to conduct some creative, exploratory testing. But by working with BAs at the beginning you reduced this effort by 60, 70 or sometimes 80%. Your work load after development decreases, because quality already increases before the software is developed. Well done!