Build Strong Edge Test Cases

Build Strong Edge Test Cases

If you are a software engineer, there is a lot of effort in software testing.  With management demanding more and more quality, there is a strong push to create efficient test cases which prevent defects occurring in production.  In my 15+ years of software testing, I have found that most organizations do a very good job in covering your happy path scenarios.  I have however found that creation of negative test cases and development of edge test cases are very limited.  The main reason for this is that there is often very little time but more importantly, a lack of creativity to build these scenarios.

Creating strong edge test cases requires a very creative mind.  Sure, you need to be able to understand how the system works, but you also need to think outside the box and ask the hard questions in your test case workflows.  If you only go by a rigid set of requirements and never deviate outside of that you aren’t going to find any edge scenarios.  Building strong edge test cases requires solid application knowledge.  For example, it is important to know what will happen when the same user tries to access the same information and perform an update on it.  Will the record get locked?  Which person will update the record?  These are the types of questions that have to be answered.  Here are some additional potential edge scenarios:

• Have a user login and disable the user to see what happens
• Have two users try to update the same record
• Disable the connection between the application and database
• Have the same user try to login from two different computers

There are many more possibilities when building edge scenarios.  Over a period of time, you can begin to identify these edge test cases a lot easier, and you will begin to see tendencies which will cause these conditions.  Chances are pretty great that if the application will allow you to do something, your business user is going to try it.  These edge scenarios are also the ones that the development team is not typically going to think about, so they often will not program for it, and it will really require some thinking on their part.  These edge test cases will often stir up a lot of controversy, because these are often things that are not spelled out in the requirements.  Some of them will usually result in some significant frustration from a business perspective because it can cause a lot of uncertainty and could impact downstream processes because it wasn’t identified.

Edge test case can also typically be negative scenarios.  They could be automated, but they may not be the best candidates, because they are often complex in nature.  These are the types of things that requires deep thinking and creativity.  The testers that are the most creative, will always strive to get to the edge of coverage and push beyond in order to prevent business users from finding defects.  The good thing about edge testing is that you can perform these types of test in waterfall, agile or other SDLC cycles.