We often receive requests from our customers, most of which are professional testers, to work with them and show them how to use Testuff when using a specific testing methodology.
Usually after a short dialog, they find the best way for them to use Testuff. We’re quite proud that Testuff does indeed fit with many different methodologies. However, the question I always wonder about is: Why do most people (i.e. testers) think that somewhere, over the rainbow, there’s a magic methodology which flies…. In my mind, it is almost obvious that no methodology can replace common sense.“Common Sense Is Not So Common”, Voltaire
Keeping the testing process efficient, simple and manageable is sometimes more important than finding and adopting a methodology, which doesn’t necessarily fit in with the company, its processes, people and attitude.
This post is not intended to be philosophical and does not attempt to create yet another testing methodology. The intention is to simply try and describe my “common sense” testing approach for those who want a simple 5 step guideline.
5 Steps to follow
The first two steps involve some preparation:
1. Get your requirements! no mater if you are a one-man-band or a global multinational organization, if you don’t have any requirements, you can’t test. You can even have “The site should not crash, and it should be accessible using FF and IE” as your only requirement. But if you have nothing, you may be able to do a great development work but not when it comes to testing.
2. Write a simple test script for each requirement. The test script is an instruction how to ensure the requirement is fulfilled. You can write it in a simple language: “Check that all links work”, “Check that all links have a proper title when the mouse hovers over them”. You could also use any format of step/expected result. Just write something easy to understand. I don’t have any particular advice on how to organize your test scripts. Some prefer to group them by requirement (each test under its requirement), some by the product areas, some by type (GUI, DB, etc). I prefer to put them in a place where I can find them :)
The third step is a mental step, just to bring you to a “testing” mode and make sure it is done correctly. Think zen.
3. Freeze the test environment. No matter if you have separate environments for development, testing, release and production or if you use only one environment for all (which is probably a bad idea). The golden rule is to freeze everything before and during testing. If someone changes your test environment whilst testing, all your effort goes down the drain and you might as well not do any testing at all. Now for the actual testing process.
There’s a little twist that will make your testing better on every cycle:
4. Start testing (and improve your scripts). Just run the Application you test and follow the test scrips you wrote in step 2. If the Application fails on a particular step of the test script, simply open a defect to be fixed later by the development team. If you test something that was not specified on the script and find a defect then (This is the continuous improvement part) add it to the script and fail the test. If you find the script irrelevant or not up-to-date then update it.
* Sub-step #2 enables you start with a very basic test script, even an empty one! and fill it in as you progress with testing.
That’s it. All done.
Another step, to be carried out outside of the testing cycle, which will help you to get better coverage of your application is:
5. Prepare for the next testing cycle. Whilst running the application in production, you will no doubt find some defects. Don’t worry! everybody does… The key is however to avoid these defects on the next release of your application. You can make sure you improve by updating the relevant scripts for the processes in which the defect was found in the first place. This way, next time you test the application you make sure to check that the defect was fixed. It also serves well for sanity / regression testing purposes.
The testing world has some great methodologies, and I’m sure you can improve this “common sense” five step process. The main reason for writing this post was to encourage you to start testing your application! Instead of hiding behind “it’s too complex”, “I don’t know how to”, “We need an expert to drive our strategy” excuses, simply jump in and get started. This is what Testuff is all about.