Following is 4 most important testing guidelines for testers:
1) Bug testers are not looking for what works
A bug tester needs to realize they are not looking to see if something works. That’s the wrong way to test. What they are trying to do is figure out any way possible to break the system/website. They should try to do bad things, stuff that shouldn’t be allowed and then see what happens. Just some simple examples:
- That’s a date field? What happens if I manually type in a date, type it in wrong instead of using the date selector, type a date that doesn’t exist, miss-spell a month, type in data that isn’t a date like special characters or letters etc…
- That’s a number field? What happens if I type in letters into it, or special characters, or type an insanely large number or a negative number, or perhaps decimal numbers instead of whole numbers.
- There’s a form to fill with fields? What happens if I fill in no fields, how little can I get away typing in, can I leave most stuff blank, what happens if I do, can I cause something to break.
- There’s a form to fill in? What happens if I take forever to fill it in like don’t finish for 6 hours, or what happens if I bookmark it, what happens if I try to use that ‘create new’ form that probably should only be used once a second time, what about if I click ‘back’ and use it again after I complete it.
Basically, a tester primarily needs to think of different ways to break the system. If a tester tests in this manner, they will catch a lot more bugs and more importantly while they may catch many bugs that would never happen in reality, by fixing those bugs and being careful it will have an automatic effect of making sure real things that would have been bugs will not ever happen a lot more.
2) Test all scenarios, even what shouldn’t happen
Just because you programmed some system or database doesn’t mean you know how a client will use it. Just because there is that ‘step 1, step 2, step 3’ and the system was laid out to follow that order doesn’t mean that it’s how a client will use it. Clients do stupid things. Try to do stupid things as well, such as doing step 3 first before doing step 1, or trying to test every scenario that could possibly happen, whether or not it ‘should’ happen.
Example:
If as a tester I see a control that looks like the above one, I should think to myself on testing it:
- There’s 3 X/Checkmarks, lets see if I can get every combination of them working (X/X/X, C/X/X, C/C/X, C/X/C, C/C/C, C/X/C, X/C/X, X/C/C, X/X/C)
- It seems to show 2 facilitators, what about showing only 1, or zero, how about showing many more if it could be done.
- It seems to show a group name, what about showing super long group names, or group names with weird characters in it, or perhaps no group name, can I manage to get that working
- It seems to show a CS#, that looks like a number field, what about trying to use a non-number field, or mix of numbers and letters, or perhaps no CS number, or a super long one, what happens
- It seems to show a client name, can I figure out how to make that show nothing, or something super long, or a client name with special characters etc…
- It has a link for ‘send reminder’, is there some way I can make that link not work
Many of those scenarios I just mentioned shouldn’t happen, some may even be impossible to test as the system technically shouldn’t even permit it. As an example I think client name is a requirement and if someone isn’t in a group probably they wouldn’t even show in that list, but still the tester should ‘try’ to make things happen and ‘try’ to break it. That’s how you find bugs.
3) Test the different browsers
Anywhere there are functions that do unique things, like popups, or file managers or stuff that interacts with javascript, you should test on all standard browsers. In fact, every page should be tested on the different common browsers once there is good test data in the system. You are trying to find stuff that looks bad or doesn’t work on different browsers, and that will usually be in places with special features like the file manager, popups, messages, advanced forms.
For this client especially test on Internet Explorer, but also included should be a bit of testing on Firefox, Chrome, Safari
4) Test Every Item
A tester should hunt for where they can do things. No item should be left un-tested.
Example:
As an example, right on the ‘tasks’ main page there is this ‘personal tasks’ list.
A tester should be looking to try and make stuff on every page do different things. As an example in this screenshot I can see a “Personal Tasks” that shows on the page. As a tester I should see that it exists and do whatever I can to make it do something. If I can’t figure out a way to make this control do something then I should be talking with the PM or Programmers to ask how do I make it do stuff.
As an example, one of the current bugs is there is now way to make this above control do anything. The programmers entirely missed programming the ‘create a personal task” function, which means that it would be impossible to put in some personal tasks and test this control. The tester should have seen this control and marked that they couldn’t figure out how to make it do anything.
Once they can figure out how to make it do stuff, following the rest of the examples above they would do tests like:
- How little info can they put in
- Can they enter a client only
- Can they enter a date only
- What if notes is super short, blank or super long
- What if the reminder date is not set as a date
- What if the reminder date is set far in the past or far in the future
- What if I put in a client that doesn’t exist, what happens when I try clicking to that client
- What if I put in a client that exists but then change that client, like remove him from the program, does anything bad happen
- What if I try to make the personal task for a staff that doesn’t exist (or is it even impossible to do this)
- What if I make a personal task for a staff and then later delete that staff or set that staff to some other status, does stuff break?
etc..etc..etc…