Software Testing is a broad area. You can not have set directions about how to test a certain software system. However, you can always generalize some tips and tricks that are likely to work in most, if not all, situations. All these lead you into knowing the software system better which plays a vital role in better testing of the software. The order of these general tips defines the order in which you should approach the getting to know part.
This is the most important one. When you begin testing, DON’T look for designs or specification documents. All you need to know is the basic idea about what the system under test is supposed to do. How it does it should be for you to figure out.
This gives you an opportunity to look at the system the way a new user would. The idea is that a large majority of software users only look at instructions on how to operate it, if they can’t figure it out themselves. If a user can’t figure out how to use your software then you should be concerned about its usability.
In this step, you should be able to figure out a good percentage of how the system works, what are the major functionalities and how many ways each functionality be interacted with.
This is the part where you do look for those design and specification documents. Go through everything you have about the system and compare it with your findings in the previous step. See if you can find any conflicts. A feature might not work the way it is supposed to. There may be a difference in the design specified vs the actual design.
By this time, you have pretty much all the knowledge you need to test a software system. The same two steps are applicable when a new version for the same app comes out. If you’re going for automation, I suggest doing it at the end of this step.
Communication and Feedback
I always include ‘communication’ in all the lists I make and I cannot ever emphasize enough the importance of communication.
It is very important to have good communication with your developers and project managers. There is a lot that can be achieved more efficiently with better communication. You can talk to your team about critical functionalities. You can ask them about the functionalities that they think might fail and hence need rigorous testing. They might even tell you about the ‘hot-fixes’ they did that might not last long enough. You can, in turn, share any unexpected behavior you saw but didn’t report because it didn’t reproduce. They being the creators of the software, might know what could have gone wrong.
You can provide your feedback to your PM about improving the overall quality of the system by introducing or removing some functionality, or about how usability can be enhanced.
Take previous incidents into consideration
By incidents, I mean anything and everything. It may be crashes or bugs or changes in features. Basically, anything that changed. The idea is to hit it where it hurts. Keeping these things in consideration will help you test more extensively around those incidents and see if the changes or fixes break anything. There can be many approaches to this depending on the system. A good and widely used approach is automating the regression tests and running them every time a software comes in for testing after a bug fix or a feature change.
There is a lot of difference in the way you test a system when you recently start on that project and when you have been testing it for some time. The key is to go into the right direction and doing things in the right order. The more you know about your system, the more fruitful your testing will be. This might seem like negating the ‘play around’ part but that in my opinion is a challenge the testers have to face where they have to approach the system like a new user would despite knowing a lot about it (that is, having tested it before!).