January 28, 2012 Comments Off on Building a SOAP or RESTful service? Take advantage of the cloud for distributed load testing
Comprehensive load testing is one of the most important responsibilities when developing a SOAP or RESTful service. Furthermore, if the service will be accessed globally, it’s also essential to conduct distributed load testing. Otherwise, running in-house load tests alone will not present realistic results, since there’s no accounting for global network latency and other factors that can only be evaluated through full load test distribution.
Yet many organizations don’t properly perform this essential task, for a variety of reasons:
- Lack of time
- Lack of budget
- Lack of expertise
- Lack of tooling
This deficiency is unfortunate, because failing to conduct well-planned and fully distributed load tests during the QA phase will almost always lead to mysterious, costly, and hard-to-fix runtime performance issues.
Luckily, modern load testing software working in concert with inexpensive, easily configured, and widely dispersed cloud computing resources makes it easier than ever to perform distributed load testing. In upcoming posts, I’ll be describing how to deploy SmartBear’s loadUI software in tandem with Amazon Web Services to construct, deploy, run, and monitor sophisticated distributed SOAP and RESTful service load tests.
January 6, 2012 § 1 Comment
In this episode of the continuing series of common technical marketing mistakes, I point out why it’s so important to create marketing content using a well-designed methodology.
In our experiences at Think88, we’ve observed that the majority of organizations – big and small – don’t have a comprehensive marketing content delivery methodology.
This isn’t a surprise: it can be difficult to reconcile the creative aspects of content creation with the often-rigid demands imposed by a methodology. And process is the first thing to go out the window when time and/or money gets tight. But in the absence of a methodology, the end result usually ends up disappointing everyone involved, including marketing, sales, development, and most importantly: prospective customers. Plus, ad-hoc procedures usually means vital marketing content takes longer to get delivered.
Consequently, it’s a really good idea to invest some time and design a methodology that meets your needs, and then follow it! It can (and should) be updated from time to time, and it doesn’t have to be fancy or very time consuming. However, it should be logical and tailored to the business.
At a minimum, a marketing content methodology should include these steps:
- Advance consultation with sales. Remember that this means more than just field sales reps: don’t forget telesales and sales engineering.
- Estimated results and ROI. How else will you know if your efforts were worth it?
- Outline or storyboard. This should include enough time for a thorough review. After all, it’s always easier to fix an outline or storyboard than the finished product.
- Comprehensive materials review. This should cover accuracy and clarity.
- Customer feedback. You want to know if you got your point across correctly, and if it matched their experience with your product or service.
- Integration with your marketing content roadmap. You do have a roadmap, don’t you?
In future posts, I’ll provide some examples of the building blocks that make up a well-designed methodology.
A final cautionary note: be careful of the ‘paralysis by analysis’ trap that can be engendered by a cumbersome methodology: the goal should be to create effective, high-quality marketing content that increases sales, not get caught up in an endless development cycle.
January 4, 2012 Comments Off on Improving operational scalability with Sybase Adaptive Server Enterprise
If you’re responsible for the care and feeding of a Sybase database server, you might be interested in an article I wrote about how to achieve better operational scalability on that platform.
January 2, 2012 Comments Off on What Google Health’s demise says about the cloud and your data
I’m an enthusiastic advocate and user – both professionally and personally – of cloud-based services. But I’m also a realist and fairly cynical, especially when it comes to looking out for my own information.
Every so often, an event occurs that validates my concerns. You may have missed this, but Google has just completed the shutdown of their cloud-based Google Health service. Even if you never used this service (and apparently not enough people did), this event should give you pause for thought.
If even Google eventually shuts down services for business reasons, can you ever count on storing vital data in the cloud indefinitely? At least Google has the courtesy to tell you how to download your data. What happens when your cloud provider doesn’t offer an easy way off their platform? Or goes out of business in the middle of the night? Or is acquired?
Fortunately, there are a number of simple things you can do to safeguard your data from provider shutdown. I’ll describe some of these guidelines in a future posting.
Testing SOA, Web services, or REST services? Here’s a free, very helpful educational website to build your skills
January 1, 2012 Comments Off on Testing SOA, Web services, or REST services? Here’s a free, very helpful educational website to build your skills
It’s surprising, but many of the students that take our SOA and soapUI classes are fairly unfamiliar with the most important underlying concepts and technical foundations necessary for optimal QA productivity.
To help them come up to speed, I always suggest the excellent W3Schools website. It provides a collection of very nicely written tutorials on a broad range of topics. If you’re tasked with testing SOA, Web, or REST services, I recommend following this track: