Identifying risks - Whiteboard notes

(Mark) #1

Thanks to everyone who came to last nights session on Identifying risks. There were lots of good questions and debates as well as some fantastic reports from the groups after the exercise. I’ve taken the ‘What are risks’ mind maps we created in our group discussion and added them below

What are risks .png1024x345 24.3 KB

Group exercise:

So what next? I encourage anyone reading this to try out this exercise:

  1. Pick a site you’re interested in
  2. Spend 5 minutes identifying different risks that could affect the site
  3. Spend another 5 thinking of testing activities you could carry out to mitigate those risks
  4. Share your findings, tell us what was easy, what was hard and what tools you might have used to help you
(Rufus) #3

Hi Guys, Please let me know if you have any feedback as I’m still learning.

Target application - www.next.co.uk

This is not a comprehensive list of potential risks, Below I have jotted down barely a few things that could go wrong in an e-commerce web application of this category.

  1. During checkout a lot of personal information is captured to make life fast and easy for returning customers. While this improves customer experience. It also leaves us with the need to look at security risks more seriously. Security Testing has to be performed to look at Applications security from different perspective.

  2. How easy it is for a user to accomplish tasks matters. When customers have great user experience they are more likely to return. Also improving accessibility of the website helps increase the target audience. Usability and Accessibility Testing may sound simple, However they help reduce the risk of loosing sales.

  3. When catering to different locations/markets. It is important to check that the website works in all supported languages and currencies. There are many situations where the website works for one locale but not for the others. Localization testing has to be done to address the above including other aspects of localization.

  4. Customers access the application through a range of devices and browsers.
    Unless made compatible the website might not be usable on certain platforms.
    Based on stats, compatibility testing has to be done to cover all supported platforms.

  5. Integrating with external applications/systems comes with some risk. In this case when system is integrated with a Payment service provider, Integration Testing has to be done with reliable test data to cover all supported payment methods for all possible scenarios.

  6. While shopping, apparently, nearly half of us won’t wait even four seconds before we give up to go to a competitors site. Graphically rich pages might take much time to render on slow networks. There are also many other factors that could affect the response time. Performance, Load and Stress Testing has to be done to check if system functions at optimum, can handle expected peak load and can fail and recover gracefully under unexpected load.

  7. Data enters the system through different sources Frontend, APIs etc.
    This data could get corrupted, lost or might appear in places where it is not supposed to.
    Although we might not be able to categorize this as a type of testing I have listed this separately as it needs special attention. Database Testing should be done to ensure data integrity.

Tools to support testing:
BrowserStack, Google Analytics, New relic, Load runner
I’m sure there is plenty more tools.

(Mark) #4

Excellent submission @rfstest you’ve really captured a range of different risks that could affect the site.

Some follow up questions for you to think about?

  • What tools/techniques did you use? Were you aware you were using any of them?
  • You say you ‘jotted down barely a few things’. Did you feel there were more risks to raise? What made you think that, the site itself or the tools/techniques you used?
  • Now that you have identified these risks, how might you go about communicating them in a way that is clear to others?

There’s a great thread mentioned below where others are trying to define what they feel risks are within 5 minutes, why not give it a try: Take the 5 minute challenge! What are Risks?

(Rufus) #5

Hi Mark, Thank you so much.
Below please find my answers to your questions. I have also added my thoughts on the What are risks thread. Please let me know if I could have taken a different approach.
1.On evaluating the website, I thought about some risks based on my experience and some others using heuristics.
2.I think that gaining knowledge of the underlying system architecture and technology will help us to uncover many other potential risks.
3.I would want to find out the probability of it happening and the resulting impact.
Based on this Risks can be prioritized and explained clearly to stakeholders.

(Michael) #6

Hi, Rufus…

What you’ve produced here is mostly an interesting list of coverage areas; ways of modeling and looking at the product that you might want investigate during testing. That’s good! However, that’s not quite what Mark asked for; in several of the categories above, you’re getting ahead of yourself. Mark was happy with what you produced, which is fine. I’m pointing this out because, as you’re still learning, it might be important for you to remember to respond to the mission that your client has asked, rather than some other mission. Mark’s a super-nice guy, so you got away with it this time! [grin] I want you to be prepared for those cases in which you have a less forgiving kind of environment.

A risk is “a bad thing that could happen”. “Graphically rich pages might take much time to render on slow networks” is a good example of that. “This data could get corrupted, lost or might appear in places where it is not supposed to” is too; ditto for “Unless made compatible the website might not be usable on certain platforms”.

In the Rapid Software Testing namespace, there is a name for your #7; we’d call this “interface coverage” or “interface testing”. Fairly generally, for us, “X testing” is “testing focused on risk related to X”.

(Chris) #7

Not really a reply, just a thread-related point, but when I write a list of risks I get all sorts of things that are nearly risks or not risks. To help me categorize and action them I often use the list from Solution #2a on this: http://www.satisfice.com/articles/rbt-trouble.pdf.

(Rufus) #8

Hi Michael,

Thank you so much for your feedback. This will surely help me out in the future.
It is important to review the findings to ensure that it is in line with the mission.
Thanks also for clarifying Interface Testing.

(Rufus) #9

Hi Chris,

Thank you for sharing your thoughts. I found it very useful.