Resource
Article [7182]
General
[1032]
Acceptance
[63]
Ad Hoc
[28]
Agile, Scrum
[231]
Black Box
[117]
Bug, Defect
[258]
DB, Test Data
[274]
Environment
[42]
Functional
[115]
Glossary, Term
[74]
GUI, Usability
[98]
Integrate test
[46]
Interview, FAQ
[285]
Manual Testing
[117]
Methodology
[231]
Metrics
[327]
Mobile, Embed
[153]
Performance
[327]
Process
[194]
Requirement
[124]
Review, Static
[102]
Risk
[99]
Security Test
[215]
Standard, ISO
[179]
Test Automate
[348]
Test Case
[341]
Test Design
[69]
Test Plan
[311]
Test Manage
[227]
Test Script
[56]
Test Technique
[265]
Tool
[175]
Tool- Jmeter
[40]
Tool- Selenium
[125]
Unit Test
[166]
Web Test
[258]
White Box
[70]
Ebook [1164]
General
[278]
Acceptance
[3]
Agile, Scrum
[24]
DB Test
[76]
Development
[137]
GUI, Usability
[17]
Interview, FAQ
[9]
Java Test
[68]
Metrics
[17]
Mobile, Embed
[14]
Performance
[49]
Process
[11]
Requirement
[55]
Review, Analysis
[8]
Risk
[7]
Security Test
[71]
Standard
[20]
Test Manage
[85]
Test Automate
[84]
Tool
[8]
Unit Test
[67]
Web Test
[60]
Testing Tool [2276]
Acceptance
[25]
Agile, Scrum
[42]
Bug Tracking
[127]
Build, Release
[27]
Environment
[58]
DB, Test Data
[83]
Functional
[240]
GUI, Usability
[79]
Java Test
[71]
Metrics
[57]
Mobile, Embed
[79]
Network Test
[67]
Performance
[222]
Requirement
[62]
Review, Static
[105]
Security Test
[111]
Test Design
[52]
Test Manage
[208]
Unit, Debug
[224]
Utility, Capture
[97]
Web Testing
[234]
Video [622]
News [2773]
Webinar [914]
Certification Resource
CTAL [271]
CTEL [35]
CSTE, CSQA [198]
CSQE [41]
CMMI, TMMI [135]
PMP [114]
ITIL [67]
Six Sigma [41]
Other [81]
Forum
Forum [1935]
Book
[56]
Certification
[48]
Conference
[64]
ISTQB
[158]
QTP
[92]
Software Test
[1062]
Standard, ISO
[89]
Testing Tool
[287]
By the way, risk analysis is quite a big word. It is not specific to
software industry, and depending on what's you're looking for you can
get very different results.
So, let me define what the purpose of conducting risk analysis in software testing is. My 2 cents definition would be "activity of understanding the impact of malfunctioning of the application." And the severity of the impact of each malfunction scenario will determine priority and intensity of the testing.
One thing I like to call out is that application malfunctioning is not only about use cases failures defined in spec. There are always implicit requirements that is not written in spec.
But normally, I start with use cases defined in spec.
Go through each use cases and find out the impact of malfunction. For example, you are testing login page. There are several use cases for this.
- Login with activated user with valid user name and password
- Login with invalid username
- Login with invalid password
- Login with not activated user name and password.
- Forgot password
- Register link
Now let's define risk and impact of each malfunction
- Failed to login with activated user name and password (high impact)
- Login success with invalid user name(high impact)
- Login success with invalid password (high impact)
- Login success with non-activated username and password (medium impact)
- Forgot password not working (medium impact)
- Register link is broken (high impact)
This is just an example of this. You can argue with different level of impact on each malfunction. But you have an idea about this approach. Here is another post for checking business impact and fault likelihood. Let's go into more details
- Login failure message not specific enough (medium impact)
- Already logged user going to login page and still require login (medium impact)
- Login process taking too long (medium)
- Logout link does not work (high)
- Login username and password text field is too small (low)
- Password text field showing the password not dots (medium)
- on and on.....
Now you have three different buckets of test cases (high-medium-low). And then you decide what to test first and how intensively test those test cases.
So, let me define what the purpose of conducting risk analysis in software testing is. My 2 cents definition would be "activity of understanding the impact of malfunctioning of the application." And the severity of the impact of each malfunction scenario will determine priority and intensity of the testing.
One thing I like to call out is that application malfunctioning is not only about use cases failures defined in spec. There are always implicit requirements that is not written in spec.
But normally, I start with use cases defined in spec.
Go through each use cases and find out the impact of malfunction. For example, you are testing login page. There are several use cases for this.
- Login with activated user with valid user name and password
- Login with invalid username
- Login with invalid password
- Login with not activated user name and password.
- Forgot password
- Register link
Now let's define risk and impact of each malfunction
- Failed to login with activated user name and password (high impact)
- Login success with invalid user name(high impact)
- Login success with invalid password (high impact)
- Login success with non-activated username and password (medium impact)
- Forgot password not working (medium impact)
- Register link is broken (high impact)
This is just an example of this. You can argue with different level of impact on each malfunction. But you have an idea about this approach. Here is another post for checking business impact and fault likelihood. Let's go into more details
- Login failure message not specific enough (medium impact)
- Already logged user going to login page and still require login (medium impact)
- Login process taking too long (medium)
- Logout link does not work (high)
- Login username and password text field is too small (low)
- Password text field showing the password not dots (medium)
- on and on.....
Now you have three different buckets of test cases (high-medium-low). And then you decide what to test first and how intensively test those test cases.
Service
New
Popular Documents
Monthly
Yearly
Popular Download
Weekly
Monthly
Twitter
tag
Sample Exam
mobile testing
mobile application testing
Software
software qa service
conference
Automation
Test management
Manual
tool
HP
tester
framework
agile
Quality
Test Case
software testing company
security
Test
outsourcing software testing
mobile
QA
Development
Test Automation
ISTQB
agile testing
Interview
Metrics
Plan
Certification
Questions
Exam
Performance Testing
testing
PM
Selenium
QC
Software Testing
web testing
Guide
test plan
security testing
Management
web
performance
process
Template
Bug
QTP
Unit Testing
Sql
Visitor
Member Login (IP)
233992
32822
203312532
Yesterday
Today
Total

 
 
vivekjog