Tips from fellow testers for finding easy defects

veryangryman

Hi.

Most testers are rated on the # of faults they report that are later fixed.

With this in mind, i was thinking of easy ways of finding faults.

Some handy ones...

-> do a find on the "/" character of the doc, you can test whether the path to script etc is correct.
-> Check if right click functionality works
-> Check tool tips are accurate
-> Check tabbing
-> If an application becomes available in more deployments, ensure that its name is now more global.
-> Check for null values in error messages
-> Check that the versions of software on launch pages match what is officially delivered

Anyone got more to share?

stevenmu

• Test recursion terminates in all circumstances
  • Test recursion terminates in all circumstances
    • Test recursion terminates in all circumstances
      • Test recursion terminates in all circumstances
        • Test recursion terminates in all circumstances
          • Test recursion terminates in all circumstances
            • Test recursion terminates in all circumstances
              • Test recursion terminates in all circumstances

...etc

AARRRGH

I know this isn't really the answer you're looking for, but if you read the spec from the business analyst and know it well, it'll be obvious which areas the programmers are going to skip, so you can immediately home in on them...

Ginger

Check if the devs used TDD when developing and get their tests from them and run them and verify what they are testing.

Then start looking at what they missed

Zulu

Humm, not a bad question at all! I’d argue that a really good tester would pre-empt/prevent the bugs in the first place!

What level of testing were you thinking (ie: unit/integration/system/UAT)?

I guess starting from the outside working in:

For UAT: Take a look at the ambiguous requirements the business analysis inevitably left open to interpretation. Find out what they’re really supposed to mean, and get cracking on these.

For system testing: Take a look at all the interfaces. What happens if/when an interface is not responding? Useful error message? Total self-destruction? How does the system recover?
Take a look at the logging functionality. What happens if/when permissions are changed?
Take a look at required resources. What happens if/when these are locked/unavailable?
What happens when load is applied to resources/interfaces?
Boundary analysis. What happens at 12:59:59 on the 31/12/09, what happens at 00:00:00 on the 01/01/10 & what happens at 00:00:01 on the 01/01/10?
What happens legacy data?
What happens on state changes?

In code analysis: redundant code branches, how are branches accessed, data flow.

If it’s web testing – different browsers/tabbing/accessibility

Sorry, it’s early and I’m getting scattered…

Ginger

On of my simplest checks for dates

Change you date on your machine to anything greater than the 12th of the month.. a lot of systems have incorrect coding on the database or some other layer and it tries to use the US date format which fails when you put a 13 or higher in what it thinks is the month field

Zulu

Bloody good one! I like that, Ginger.

Ginger

Tell me about, thats why ended up changing our testing process from the start of the month to the end when doing anything that required dates...

NeverSayDie

On any field that takes keyboard input, make sure you try a few punctuation characters, this can quickly expose bad handling of input internally - special characters not being escaped, that kind of thing. Good ones to try are single quotes - as in names like O'Brien (that can mess up database queries if it's being injected straight into them, which would a bad idea and a good thing to catch) - also angle brackets (can mess up XML or HTML if it's being handled in the raw, again a good bad thing to catch).

If it's a web app, messing with the query string in the browser is always a good idea (eg, for some Product X you're not supposed to have access to, try entering an address you saw earlier for Product Y, changing it so ../deleteProduct.php?product=X). There are many more and more sophisticated ways to test that area, but URL fiddling in the browser is a very basic thing that even non-technical users are liable to try at some point, so it's an early catch for some pretty basic and serious problems.

veryangryman

Sorry to bump but just in case anyone new to forum has any new tips/

I do End to End Testing btw

Zulu

When testing date ranges (say a report that pulls from 5 years) test for 5 years to the date (ie: 25/3/(+/-5)2010) and test to the year (ie: 1/1/(+/-5)2010).

The amount of times I've come across the business wanting from the start of the year, and the dev running from the exact date....

Seth Brundle

Dates as mentioned.
Data entry validation (number fields only contain numbers, etc.)
Divide by zero errors!
Test on older PCs (e.g. win2k) - an app may look fine on newer PCs but on older ones with poorer graphical support, etc, it can look different (vista type graphics, etc)

Civilian_Target

Yep. The best thing is testing the opposite: if something is supposed to not display an error for a certain type of input, check as many other inputs as you can that should produce that error. If something fixes an error, check other cases where that error should occur.

Some other good ones I learnt:

- Set your regional settings to Turkish, and start putting in a combination of small and large letter I's
- Put commas in with numbers in numeric fields
- Divide by zero errors, put zero in everything except one field
- Change your system path, browser or default font size, and see if the application still works

Evil Phil

If you're using use cases this is a good approach for black box testing. For each use case work out the data required to complete the success scenario, this is your success fixture, your oracle is the use case goal.

Now write up the fixture for each extension. Run the success scenario test, if this fails pretty much all the extension test cases will also fail. If it doesn't you still get to go through your test cases. If you uncover a bug write a test case to generate that bug, and add it to the test suite.

It might also be a good idea to ask the devs what kind of exceptions they're handling and raising, find out scenarios that will raise those exceptions and see if they are actually being raised, if not you've found a bug.