Research & Development for 3D & the Web

Introduction to Testing

Testing is a very important part of any kind of software development cycle. Having software tested in the right way throughout the development cycle can save a company and their clients a heap of time and money. Finding issues can happen at any point in development, from as early as the proposal stage to as late as someone calling in with a support issue which turns out to be a bug in the software. Finding a possible issue in the proposal document is much more ideal than having to have a developer re-work a heap of code that they have already spent many hours on.

It’s important to remember that software is never 100% perfect. That’s just the nature of the beast. It will ALWAYS ship with bugs in it. Every project has a budget and that budget determines how much time can be allocated to completing the project.  Testers are responsible for identifying as many of these issues as possible during this time and deciding which of the issues really requires attention by the developers again. One of the worst things a tester can do is to bog down a project with an endless stream of minor issues, this is not a good approach and will usually cost you company and clients money rather than save it. If there’s time at the end for some extra bug fixes, great – pass them on to the developers.

Identifying as many issues as you can and listing them somewhere along with a priority level is not a bad idea, that way if you are looking a particular area and you find something that does require attention – you could always slip a minor issue that you’ve recognised into the same issue report if it’s related and won’t cost your team too much extra time.

A tester is generally an all-rounder. They have a good understanding of a lot of things, however not necessarily an amazing understanding of everything due to the broad nature of the field. They might have a very good understanding of some areas in which they have had a lot to do with or worked in the past but they most likely will never know EVERYTHING that there is to know about all technologies. For this reason good communication is required with the rest of the team – project managers, developers, designers and other testers as well as great deal of tact. The key to a good working relationship with the rest of your team as a tester in my opinion is tact. Testers are typically the least ‘liked’ people a lot of the time. This comes with the role – you’re quite often telling someone that they have produced a monster of a baby, or that their baby is slightly deformed.. How would you like to be told that all the time by someone? If you can’t communicate this with a good level of tact and professionalism, it will never go well for you as a tester.

So far in my limited experience as a tester, I can usually put developers into one of two categoris. Those who see the importance of testing and appreciate it for what it can mean in the long run (IE. narrowing down the possibility of revisiting old code in the future and ensuring their work is of the highest possible standard) and then there are those developers who tolerate testers (because they have to) but generally dislike the whole process of being given something they’ve worked on back with dirty red pen all over it. Both of these groups need to be handled differently which again comes down to tact and generally being good and thorough at what you’re doing so they can’t get on your back about things.

Writing “this is crap, everything keeps breaking here and here and here and here” is probably not going to score any points, whereas a more professional or light hearted comment such as “I’ve had a look over this and it appears that this and this aren’t quite meeting the requirements. Is there anyway we could try this instead..” makes all the difference. I’ve also found that as stupid as it sounds, sometimes offering a possible solution which gets disregarded can work well. I think developers are the brightest people in the team and they like to know this – so for them to be able to go ‘oh no, I know a way better way to do that” to an idea you’ve suggested already has them feeling better about things and can entice them into proving just that to you. Aaaaand you never know. Perhaps the ideas you suggest will sometimes worthwhile too…

Asking questions is hugely important as a tester. The written proposal may sound nice, but you never know what difficulties may have been encountered when developing the item in the proposal. This will often mean sitting down quickly with the developer and finding out exactly what that was and why it was changed and more importantly how it SHOULD work now. Without this, you can end up sending back issues which waste time because you don’t have the complete understand you really should have. Understanding is first required before you can properly look at something and say “no this is not quite right”.

Warning: This brain dump will soon be followed by many more.