I get asked periodically what exactly I do. When I respond that I test software, most people respond with “Can you fix my computer?” or “So you make software”.
Knowing your application
Make sure that when you’re creating a test plan, feature or regression testing, or verifying a bug fix you know the application. How each of the pieces of functionality work and interact with each other. How your application communicates with the database, the tables that are applicable to the plan you are following, what security standards are supposed to be in place, what different user levels are supposed to be able to do (and when), etc…
Each of these together is one of the most important parts to creating a test plan, executing the test plan, writing bug reports, and verifying the fix. As the application gets bigger the chance of changes and fixes causing problems in the same area or dependants on the area increase dramatically. There’s a bit of a saying “When you fix one bug you create two others.” This is very true, but not entirely accurate. By fixing the bug, the other problems most likely came out of hiding. As a tester, the need is there to not only test the fix, but keep going through the remaining part of the process.
Finish the Test
One of the biggest mistakes and pitfalls that a tester can make is to not finish the test. The best way to describe this is to think of yourself working on a store’s checkout process. Let’s say the bug happens on the billing information page and it has to do with a field not showing up correctly. Now, to verify the test, you would just test each of the steps up to making sure that the field is there, right? Did you say yes? Did you think about what might happen now that the field is being displayed and the customer now try’s to finish his checkout? Does it work? You don’t know this. You need to check this.
Most developers will plan ahead on this and see that by adding that field that a remaining part of the checkout might fail with the addition of that field and then fix those parts to work with the new addition, however, if it’s crunch time, they forget this, either way, you need to check it.
One Form, Three Fields, Ten Tests
Most of today’s forms have some sort of validation against them. For example, the first and last name fields would probably be required to only have alpha characters, Phone number would probably require only numbers. Also, let’s say each of the fields are required and you don’t fill anything in. Phone numbers have a specific format which has a specific length.
Those are the easy ones. Now let’s get complex. I’ve brought up the importance of web application security before, so here goes: Most likely whatever get’s added to the form is going to end up in your database at some point. So what happens when the user puts characters in the form that are used in databases. An apostrophe is an excellent example of this. Apostrophes end values or strings in database queries, so your application should be escaping these characters correctly before adding them or looking for them inside the database.
These possible application breaking bugs are called injection attacks, or more commonly SQL Injection attacks. They can leave your database somewhat wide open for inserting other queries behind the character that initially broke the query. Also, someone named O’Malley could be trying to enter their name.
Usually with web applications you’re going to want to be able to see what your users are entering in. This creates the openess for Cross-Site Scripting attacks, or XSS attacks. These types of attacks are performed by malicious users who enter javascript into your form fields that can execute any number of actions once an unknowing admin browses the form submission. This can be anything from cookie forwarding, keylogging, or general browser take over.
Finally, there’s 8 (I grouped some). The last couple of tests are the most important, and were also the ones probably run by the developers already. What happens when a user correctly fills out the form and submits the information? Also, what happens if you aren’t allowing duplicate information inside your application and a user enters information that already exists. There’s 10.
Cleaning Up
Now you need to make sure that in your rush to submit all your bugs that you didn’t duplicate your efforts (or those of other testers). Go through the submitted bugs that have been logged and make sure they aren’t related to each other but exist in two different areas of the application. Also check your dependancies. Make sure that one bug isn’t caused because of another one or can’t be fixed/tested until another is fixed.
I’ve seen a lot of testers fail to catch the most obvious bugs because they don’t think it through. I’ve also seen a lot of developers submit things that “can’t have bugs” but end up being full of them. To think like a tester, you need to be the smartest and the dumbest user all at the same time. Screw stuff up, break it, make sure not to follow the prescribed process. And remember, if everyone always drove a car correctly you wouldn’t need insurance.
–dez
