Risk Analysis Strategy

Abhijeet today asked in Twitter about how to have a risk analysis strategy for the product before the product development starts. That’s a very thoughtful question, and I would answer it with a generic framework, because, you know, ‘It depends’ !

Generally I don’t go with ‘risk’ to assess a product because that gives a partial view of looking and assessing at a product only from how the product would break/misbehave. I usually go with a wholesome approach of looking at how the product should behave and then consider some additional scenarios as corner cases and address them as part of the Software Testing strategy. Primarily I call this assessment as Design Considerations rather than being risk assessment. I find it then easier to talk to the developers in their lingo to get the points across and understand how the product should behave in various situations and provide the necessary inputs as needed.

Considerations
Software has become extremely complex with cloud deployment, distributed architecture, and software supply chain dependencies. At the same time, there are software solutions that don’t use cloud deployment and distributed architecture, and may be not have many dependencies (as in a custom solution which is written from scratch without using any open source components). So, it would not be possible to provide one strategy that would work in general for all software products.

Attributes

But there are some key attributes that one shouldn’t skip while assessing a current-day product. As it would be nice to look at it pictorially, I am providing this diagram below. This is generally comprehensive, but feel free to let me know of additional things that can be considered by reaching out to me.

Framework

As you can see, each of the attributes have to be analyzed in the context of the product under development. For example, when looking at usability, we need to look at all the ways the product is usable through various channels (GUI, API, CLI). Similarly, when looking at performance, a router would have a totally different set of requirements than a e-commerce portal. So, using a generic framework as shown above as a guideline, one could come up with detailed design considerations (viz-a-viz risk factors in quality parlance).

As a Software Tester, I am quite excited to work along with developers while the architecture/design is being looked at (before the development is done – as Abhijeet pointed out), to come up with this kind of a strategy.

For designing detailed risk analysis strategy for examining and assessing the architecture and design of your product from a Quality standpoint, feel free to get in touch with me. Glad to help!