top of page
Writer's picturetakery reddy

Software Testing Company in Boston

Do you consider the risks associated with the current component testing it? When you look at some of the anomalies while testing, do you ask yourself "What can go wrong here"? Did you try to imagine the worst-case scenario after breaking features while testing? Are you including the risks that may be related to a bug in the bug report?



If one of your answers to the above questions is yes, then you've done a risk-based testing! To that end, while testing the majority of testers perform some type of risk analysis and risk-based testing either consciously or unconsciously! Risk-based testing has some additional benefits as well in addition to the obvious benefits! I will try to prove my point with my real life testing experience.

Once I was testing a login page from an online auction site. Login page has three main areas - User Type (drop-down list box), User Id (text box) and Password (again text box), which received critical user input. While testing, I found that the User Type drop-down list box that accepts text input, such as the combo-box! In other words, I can type text directly into the User Type drop-down and it accepted it as a valid input! How do you rated behavior like that? I'm not sure if there is a tester will consider calling this anomaly as a bug at all! At least, I was not ready to log the issue to the bug tracker yet, because I was not comfortable with the severity of the (very low!) From this bug. So I would like to investigate more about this bug before logging it.



1. Because I can type entries into the field, I try to incorporate some type of invalid users to the field instead of selecting from the drop-down menu. [FYI, there are three types of valid users - Admin, Power Bidder and the Bidder Lite]. I enter a valid User Id and Password and try to Log In. Fortunately, the application is quite strong (!) To pass this test and did not allow me to login.

2. This time I enter a lot of character to the drop down text and continue testing. [All this time, I used a valid input in the User Id and Password field]. However, it does not allow me to login. But I continue to increase the number of characters in the input text in the User field type. I input the text size is more than 35,000 characters now and Bang! I get "HTTP Error 500 - Internal server error" and the app crashed. Further investigation revealed that when the size of the text input go past the 43 679 characters (with spaces), the application always falls with internal server error!

Now that the bug is good enough to log into the bug tracker. But at least there are some important things (from the point of view of the tester) to record.

a) Although the User field type should not accept text input, it still has got the upper limit seems critical, crossing resulting in an accident because an internal server error.

b) Speaking of risk, this may look like a server-side error innocent. But as this accident resulting from a possible buffer overflow / overrun, the risk of high system security breaches. A malicious user could be injected input is specifically designed to execute malicious code or to create the program operates in a way which is not desirable. The risk is great considering the fact that the fields involved are intended to receive the "User Type"! Just think of a scenario when a hacker will exploit the weakness by logging into the system, emulating an "Admin" user! After a successful login as an Admin user, anyone can master the entire site! Worst still, being an online auction site, the financial aspect of security vulnerabilities is too high to compromise with.



See how the bug that seems less important (editable drop-down list) is actually a serious security threat as far as risk assessment was concerned. Not to mention, it is regarded as a top priority issue and fixed it immediately. I wonder whether this issue will be considered as serious, if I had been posted without the associated risk factors!

It is certainly not possible the best example of a case in which the risk analysis should be a lot to do with the fate of the bug, but I'm sure some of you may also face the same situation. Please feel free to share your own story about a risk-based testing by leaving a comment.

0 views0 comments

Recent Posts

See All

Comments


bottom of page