I noticed a certain heuristic I have been using for quite a while now, without realizing it. So today I decided to explore it’s applications and, most importantly, give it a name.
I call it the Instance Heuristic.
Whenever I find a bug, I ask myself where else a similar problem might occur. I think of the bug as an instance of a mistake made because of code reuse, improper use of libraries or frameworks, object oriented programming or even object oriented thinking. Then I try to find other instances of the same mistake.
Continue reading »
The situation:
A game developer has been making continuous expansions for its game. Introducing cool new features, creating better immersion and giving players new ways of having fun in the sandbox.
With one of the latest expansions they also included a smaller update, fixing handful of small things that had been in the game for more than 3 years. And when I say small things I mean small things like:
- Showing a tool-tip in a accounting window
- Option for autominimizing a small menu window when activating a feature
- Ability to drag-select instead of shift or control select in certain cases.
- Moving information from one tab of info screen to the main part of the info screen.
You get the picture now. Very small changes in the huge game-world. And what happened?
Let’s take the same concept from the first part of the article even further.
Let’s say that viewing
/users/id/104/edit
(or some other random numbers) gives a permission denied error.
So, viewing the edit profile page is not allowed. However, that does not necessarily mean it’s not possible to edit anyone’s profile information – it just has to be done without without viewing the edit profile page. You’re going to need a tool for that.
There is a class of dangerous security issues that can be found by .. just looking around. You don’t really need technical knowledge to identify these issues, just the regular exploratory testing skills. Sounds good, right?
Take a look at OWASP Top 10 Application Security risks. Specifically, A8 – Failure to Restrict URL Access.
This is a very simple class of problems. The developers simply forgot to authenticate users properly before letting them do something. (Creating new users with administrative privileges, for example. True story.)
A “classic” software testing exercise usually looks like this (.pdf file, exercise from “The Art of Software testing” by Myers). If you don’t fancy downloading another pdf file, here’s a rundown:
- Imagine a triangle (it’s always a triangle).
- Now test it.
- Using black box testing.
- Using white box testing.
- By drawing a pretty picture.
- Using method X.
Although this kind of approach is good for conveying fundamental testing methods, it often fails to inspire thinking outside the box or creativity – which to me are core testing skills that have to be honed as often as possible.
Recent Comments