XML, SOAP, REST Testing for SOA and Cloud Computing

SOA Testing

Subscribe to SOA Testing: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA Testing: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


SOA Testing Authors: Mamoon Yunus, John Savageau, Tim Hinds, SOASTA Blog, Hervé Servy

Related Topics: SOA & WOA Magazine, Java Developer Magazine, Software Testing Journal, SOA Testing

Article

Making a Case for a Test Case

You need to balance the limitations in terms of resources and time, with the need to ship the highest quality product possible

For software testers to create a detailed test case during the QA process can be tricky: sometimes it's not an option; sometimes it's wasted effort. Here are ways to help make that decision.

Part of the skill set required to be a good tester involves the ability to assess a software project and decide when it's worth putting in the effort to create really detailed test cases. Sometimes the software will lend itself to unstructured testing, sometimes the development methodology will dictate a specific approach, and sometimes every possible facet will need to be covered. If you plotted projects on a graph you would get a bell curve because most of them fall somewhere in between the casual and the comprehensive.

How Do You Decide?
There are various factors that are going to weigh on any decision. Some of them leave no room for ambiguity, for example:

  • There are legal compliance requirements or contractual obligations that require documentary evidence.
  • Any bugs in the software would be potentially disastrous, such as with air traffic control or medical software.

These are special cases and they make the decision to write detailed test cases easy, but most projects are not so straightforward.

Consider Your Testers and Audience
How much experience does your test team have? Novice testers may well need the guidance provided by a set of clear and concise test cases. If they are more experienced, then you can trust them to do a thorough job without so much direction.

The intended audience for the software is also an important factor. If this is business software aimed at specific professionals, and you can envisage clear use cases, then a well-organized test plan with detailed test cases will help the QA department. If, on the other hand, the software is aimed at the mass market and it's tougher to predict exactly how people will interact with it, some less formal, agile exploratory testing could turn up important bugs that a more formal approach would miss.

It's also worth bearing in mind that rigorous, detailed test cases, with no room for intellectual input or creative thought, can be dispiriting and even demotivating for testers. Talented testers welcome the opportunity to flex their brains and they can use their experience and their intuition to uncover flaws in the software. If the approach is overly strict and you fail to leverage your tester's skills, bugs will end up slipping through into the final product.

Match the Development Methodology
Modern software development encompasses a number of different approaches and no two teams or projects are the same. If you start out with a vague set of requirements and the developers take an agile approach, then you may not even have the necessary prerequisites to write detailed test cases.

It's also not uncommon for projects to change direction frequently during development and these changes could render your test cases obsolete within a few weeks of them being created. It may be necessary to talk directly to designers or the customers generating the requirements in order to keep abreast of where the software is going and how best to test it, but it's not always possible to get answers to all of your questions.

At the other end of the spectrum a traditional waterfall approach to development, where everything is agreed and signed off before the project begins, will enable you to create test cases with confidence.

It's About Efficiency
Ultimately it's about finding the most efficient approach. You need to balance the limitations in terms of resources and time, with the need to ship the highest quality product possible. Longevity has to factor in - if the project is only scheduled for three months, you won't get much value from a detailed set of test cases, but an ongoing enterprise platform that will be in use for years definitely merits an upfront investment in test cases.

Think about what will offer the best return on investment. Writing test cases is a time-consuming task and it requires the attentions of your most experienced testers. Before you pull the trigger on a detailed test plan, take the time to consider whether it's the most efficient use of their time.

Sometimes it will increase your effectiveness and have a big positive impact on the software, sometimes it won't. The trick is to find the right balance.

More Stories By Vu Lam

Vu Lam is founder and CEO of QASymphony, developers of defect capture tools that track user interactions with applications. He was previously with First Consulting Group and was an early pioneer in Vietnam’s offshore IT services industry since 1995. He holds an MS degree in electrical engineering from Purdue University. You may reach him at vulam@qasymphony.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.