In QA we look for risk and run constant calculations about what we should focus on next. Using the IETF's specification for RFC 1149, (aka "A Standard for the Transmission of IP Datagrams on Avian Carriers​," dated 1 April 1990) I'll go over how to identify the risks in a system and where to focus your attention first as a tester. I'll hit highlights of stuff that commonly goes wrong and give you some tools to find out where your risks are. Please read RFC 1149 beforehand (takes less than 5 minutes): https://tools.ietf.org/html/rfc1149

1. Risk Analysis in RFC 1149
Alison Hawke / Director of QA

2. RFC 1149
Our target system for risk analysis
“A Standard for the Transmission of
IP Datagrams on Avian Carriers”
RFC 1149 was released for comment by
the Internet Engineering Task Force on
1 April 1990.

3. What is risk analysis?
What is a risk? Where do they lurk? How do you find them?
No code is 100% risk-free.
Assumptions are bad, especially ones you don’t know about.
Trade-off sliders, what does the client really care about?
Certain areas are inherently risky because they’re hard to get right.
Hygiene factors/detractors.

4. Assumptions and “unknown unknowns”
How do you know what you know and what you don’t know?
“Reports that say that something hasn't happened are always interesting to me, because as we
know, there are known knowns; there are things we know we know. We also know there are
known unknowns; that is to say we know there are some things we do not know. But there are also
unknown unknowns – the ones we don't know we don't know. And if one looks throughout the
history of our country and other free countries, it is the latter category that tend to be the difficult
ones.”
Donald Rumsfeld, US Secretary of Defense, Feb 12, 2012

5. Trade-off sliders and risk prioritization
Who cares, and about what? Why is this more important than that?
• What does the client care about most? Ask them, often.
• Will this feature lose the client money if it’s broken?
• Will this feature make the client look bad if it’s broken?
• Nonfunctional considerations are a risk

6. Some stuff is just difficult
February 29th, 2015 and other problems
https://twitter.com/kellan/status/11110460227

7. Some stuff is just difficult
“GU2 5XH” is a valid UK postal code
• Dates, times, and time zones are complex.
• Names and addresses, especially global ones, are tricky.
• Math is hard, rounding errors happen, int’l currencies are difficult.
• If the user can enter data, the app is open to attack.
• Caching is hard, and horrible when it goes wrong.
• Nonfunctional considerations are a risk, e.g. system resources.
• What about security? Encryption? Privacy? Personally identifiable information?

8. Hygiene factors and other detractors
No-one likes a dirty bathroom
If {X} is there, it provides little user satisfaction.
If {X} is missing or broken, it is a HUGE problem.
Examples:
• Clean bathrooms.
• Caching.
• Performance.
• Encryption and other security.
• Session persistence.