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.
Also Read : Software
testing Company in California
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.
No comments:
Post a Comment