I'm inspired to think about risk based testing. I've been working with a lady from Finland with 15 years of deep experience (she's brilliant) who is about to do her public speaking debut in a few weeks and I can't, for the life of me, understand why she's kept to herself so long. She's about to do a great session on her experiences on risk based testing, growing from the telecom world to the safety-critical devices.
With all the good advice she had to give in delivering a trial version of the talk, something left me thinking. And the something is that it is so clear and evident that we live in different worlds, and I don't miss her world one bit. The difference is agile.
Many of her experiences talked about not having enough time and thus needing to prioritize based on risk. Her later experiences talked about safety-critical making time for testing all risks classified serious. And her later experiences resembled my world a lot more.
With agile and continuous delivery, I have all the time I need, with risk-based assessment of where time is useful in testing, to test against whatever information I feel I could or should provide. The natural fall-offs tend to be types of testing that require special skills (performance & security in particular) and there I feel we don't do all we could/should. But if they were just tasks over major learning efforts, they'd be included.
Risk-based testing is no longer a technique for me, it's an overarching principle. Find information that matters - that's risks. Find first information that matters for schedules. Find then information that matters for all kinds of stakeholders, with less schedule impact. Big impact on development first.
It's like playing a game of nightmare headlines. Writing all the bug reports (in my head mostly) that I never want to write in real life.
I struggle much more with my risk blind spots. The need of giving myself chances of learning that all my brilliantly crafted lists of ideas to do and things to test are still incomplete. And that new things that emerge may actually be higher in priorities with the idea of minimizing the late impacts.
Then again, with agile, the impact profile is so different. I remember Vasco Duarte talking about this, so I went and googled what he's repeated for the years I've known him work on agile.
With all the good advice she had to give in delivering a trial version of the talk, something left me thinking. And the something is that it is so clear and evident that we live in different worlds, and I don't miss her world one bit. The difference is agile.
Many of her experiences talked about not having enough time and thus needing to prioritize based on risk. Her later experiences talked about safety-critical making time for testing all risks classified serious. And her later experiences resembled my world a lot more.
With agile and continuous delivery, I have all the time I need, with risk-based assessment of where time is useful in testing, to test against whatever information I feel I could or should provide. The natural fall-offs tend to be types of testing that require special skills (performance & security in particular) and there I feel we don't do all we could/should. But if they were just tasks over major learning efforts, they'd be included.
Risk-based testing is no longer a technique for me, it's an overarching principle. Find information that matters - that's risks. Find first information that matters for schedules. Find then information that matters for all kinds of stakeholders, with less schedule impact. Big impact on development first.
It's like playing a game of nightmare headlines. Writing all the bug reports (in my head mostly) that I never want to write in real life.
I struggle much more with my risk blind spots. The need of giving myself chances of learning that all my brilliantly crafted lists of ideas to do and things to test are still incomplete. And that new things that emerge may actually be higher in priorities with the idea of minimizing the late impacts.
Then again, with agile, the impact profile is so different. I remember Vasco Duarte talking about this, so I went and googled what he's repeated for the years I've known him work on agile.
Agile is a game changer. I wonder why we write so little nowadays of risk-based testing - did agile change it so that it needs a relevantly different way to describe it? Or is it just that we understand that risk, just as exploratory, is just a word that describes any good and skilled testing?Agile = the best risk management *strategy* currently known for Software development #agile #scrum #kanban— Vasco Duarte (@duarte_vasco) April 18, 2016
