Top 10 Negative Test Cases

Often I hear “happy path” test cases, which is the desirable path by product owners and developers, but in the real world, as well as the positive test and of course, the team think about the negative path but are you?

As a tester, are you thinking thoroughly about the negative test cases path and the potential impact in the project if you won’t come up with them on time?

With no sorry’s or but’s, here is a comprehensive list made by the Smartbear team from the QAComplete help page that I think is worth sharing with testers and developers. Enjoy the read.

Top 10 Negative Test Cases

It is important to create positive and negative tests when developing your test library.  Positive test cases test the feature as it was designed to work.  Negative test cases test the feature in ways the designer or programmer may not have thought of.  To help with this, we have identified ten types of negative test cases you should consider when testing a feature.

Embedded Single Quote

Some SQL based database systems have issues when users store information that contains a single quote (e.g. John’s car).  For each screen that accepts alphanumeric data entry, try entering text that contains one or more single quotes.

Required Data Entry

Your Requirements or User Stories should clearly indicate fields that require data entry on screens.  Test each field on the screen indicated as being required to ensure it forces you to enter data in the field.

Field Type Test

Your requirement should clearly indicate fields that require specific data entry requirements (date fields, numeric fields, phone numbers, zip codes, etc.).  Test each field on the screen indicated as having special types to ensure it forces you to enter data in the correct format based on the field type (numeric fields should not allow alphabetic or special characters, date fields should require a valid date, etc.).

Field Size Test

Your requirement should clearly indicate the number of characters you can enter into a field (for example, the first name must be 50 or fewer characters).  Write test cases to ensure that you can only enter the specified number of characters.  Preventing the user from entering more characters than allowed is more elegant than giving an error message after entering too many characters.

Numeric Bounds Test

It is important to test for lower and upper bounds for numeric fields. For example, if you calculate interest charged to an account, you would never have a negative interest amount applied to an account that earns interest. Therefore, you should try testing it with a negative number.   Likewise, if your requirement requires that a field is in a specific range (e.g. from 10 to 50), you should try entering 9 or 51; it should fail with a graceful message.

Numeric Limits Test

Most database systems and programming languages allow numeric items to be identified as integers or long integers.  Normally, an integer has a range of -32,767 to 32,767 and long integers can range from -2,147,483,648 to 2,147,483,647.  For numeric data entry that does not have specified bounds limits, work with these limits to ensure that it does not get a numeric overflow error.

Date Bounds Test

It is important to test for lower and upper bounds for date fields. For example, if you check a birth date field, it is probably a good bet that the person’s birth date is no older than 150 years ago.  Likewise, their birth date should not be a date in the future.

Date Validity

It is important to ensure that invalid dates are not allowed (04/31/2007 is an invalid date).  Your test cases should also check for leap years (every 4th and 400th year is a leap year).

Web Session Testing

Many web applications rely on the browser session to keep track of the person logged in, settings for the application, etc.  Most screens in a web application are not designed to be launched without first logging in.   Create test cases to launch web pages within the application without logging in.  The web application should ensure a valid logged in session before rendering pages within the application.

Performance Changes

As you release new versions of your product, you should have a set of performance tests that you run that identify the speed of your screens (screens that list information, screens that add/update/delete data, etc.).   Your test suite should include test cases that compare the prior release performance statistics to the current release.  This can aid in identifying potential performance problems that will manifest with code changes to the current release.

References: QA Complete – Smatbear