In the world of software testing, there are many testing techniques. The primary objective of a testing technique is to help the tester do some actual testing. Every technique has its strengths and its weaknesses. Some techniques can help decide who does the testing (e.g. unit/user/beta testing), other techniques can help identify which areas to test, but not one technique can help in every way.
One technique that gets a lot of air time in the software testing industry is Risk Based Testing (RBT). There are two ways that RBT is used and described. One is where you have a set of tests in mind and you use a risk approach to prioritise the tests. The higher the risk, the higher the priority and the sooner you execute the test. The second way is when the tester (or project team) generate a set of risks that may apply to the application under test, and then they test the application to see if the risk does apply (please Google RBT if you want a longer and better description). The thing that annoys me about RBT is that some people think it’s the be end and end all. It’s not, it’s just a technique, an approach, it has its strengths, but it also has weaknesses. For example, it’s not very easy to get a reliable idea about feature or code coverage using RBT. You might have good coverage on the risks, but you may be concentrating on one area of the functionality. The risks themselves are heavily influenced by the people or testers analysing the risks, so you could end up with a narrow focus (tunnel vision) of the risks. Another weaknesses is that RBT doesn’t tell you how to actually do the testing – should it be heavily scripted or use a more exploratory approach. Also, who’s to say the risks are realistic, maybe the risks are too farfetched.
With that in mind, I want to introduce the perfect software testing technique. As far as I know (and I know a lot), this technique has no weaknesses, it is pure strength! The technique is called “Know your bugs” © 2011.
With this technique, the tester images or visualises how a bug could appear in the application (the tester becomes the bug). With this in mind, the tester executes a test to confirm or reject the bug exists. Pretty simple really. And please don’t confuse this technique with RBT, it’s totally different.
I can see how the know your bug method could be helpful with an application you are familiar with but how about if you are faced with a functionality you have never seen before? (For instance if you had specialised in testing an Outlook plug-in) and then got a job testing testing something like transactional financial application?
ReplyDeleteOK, so you've found a flaw in my test technique. It didn't take long! :)
ReplyDeleteWhen ever I test anything, to do a thorough job, I need to understand the application, how it should work (gain domain knowledge). With this in mind, then the technique could still apply... but yeah, it's not perfect... like any other technique ;)
In fairness, I was being a meanie with that remark as obviously, no matter what the type of software, there are functional strands that are common to all. For instance, it must launch, users should see *something* upon launching the app, users should be able to log in, menus should open the correct screens when clicked on etc etc.
ReplyDeleteSometimes I wonder if the energy the testing industry devotes to techniques, methodologies, thinking them through, justifying them, advocating them and all that just takes up time that could actually be devoted to testing.
There is a question for you. What bring better value to testing, just doing it or thinking about how to do it best?
Hello I am the devil and this evening I will be my own advocate :)
Good question. The value comes in doing the testing. BUT to get GOOD value from doing the testing, you need to think about the testing and how to do it better.
ReplyDeleteI guess we can think about the testing in between projects when it's a little quieter or we can hear/read what the 'testing experts' are saying - although that doesn't mean everything the experts are saying is right.