If you’ve used SOAPUI for any length of time, you’ve probably concluded it’s a really useful tool!  Automated API testing has been figurative manna from the heavens for the testing crowd at AVIO Consulting.  So, since everyone loves a good list, here are 3 more tips to make your experience in SOAPUI an even more productive one.

The first 3 tips (part 1) centered on navigation, ease of use, and best practices (link below). The last 3 (part 2) will be based on lessons learned.

Ready?  Here we go!

4. Disable/enable for on-the-go Customization
5. Flexible Outcomes for the Win
6. Crash and … Wait, Don’t Crash

4. Disable/enable for on-the-go Customization

As a part of our normal testing strategy, we write an end-to-end test of the BPM process for a given functional area.  However, it’s not uncommon for a bug to occur at the UI level some “distance” into the BPM process.  As a tester, this presents a conundrum with two likely possible ways forward:

1. Create a new test to test a specific bug.
2. Manually test the BPM process in the UI to reach the reported issue.

Neither of these options is always an efficient use of time.  So, why not get a little creative with a third option?


If you’ve found yourself in the same situation, consider saving a little time by doing the following.

1. Identify where the reported issue lies in the BPM process.
2. Find the closest human task to the reported issue (if applicable).
3. Disable all test steps in a given test case after the reported issue is alleged to occur in the UI.
4. Log in to the UI to test the issue.

This scenario is rather common for us.  If your functional tests look like the portion of the test case shown above, this strategy will save a lot of manual testing.   

5. Flexible Architecture for the Win

As functional tests grow in complexity, maintenance becomes increasingly time-consuming.  So as to maximize productivity, consider a functional test architecture that allows human task outcomes, task activities, and even BPM roles to be changed/updated at will in SOAPUI.  

It may take more time up front, but coding on the presupposition of change affords easier test compliance and re-usability down the road.  

Here’s what I mean.



In the example above, the (top), (middle), and are each interchangeable with other pre-defined values in our system.  

Prior to the implementation seen above, these activities, roles, and outcomes were sourced from an audit export file and hardcoded.  What a drag!  Now, test case maintenance goes far more quickly than it used to.  

6. Crash and … Wait, Don’t Crash

Perhaps you’ve been unlucky enough to have SOAPUI crash while testing — I certainly have.  As our test cases grow longer, SOAPUI shows a little more of its “character.”  To avoid unwanted application crashes due to memory constraints, try the following.

1. Identify problematic test cases to modify.
2. Double-click each problematic test case and open the settings menu (gear icon).
3. Check the “Discards successful TestStep results to preserve memory” box.
4. You’re done!

There may be more sophisticated ways to preserve system memory and/or stabilize SOAPUI while running lengthy functional tests.  However, this has worked well for us.  We think it’ll help you out, too.  

As always, we want to hear from you, our readers.  Which of the tips above helped the most or the least?  Are you already using these in your daily testing practice?  How can the above be improved for greater productivity and usefulness?

Be sure to check out our other blogs and check back often for more content!

Other [Somewhat] Helpful Blogs:

• 6 Tips to Make the Most of SOAPUI — Part 1
• Optimizing User Stories for Efficiency
• Always Strive for Better
• Scrum Crumbs: Three Things I Think I Learned