Level: Introductory Scott Laningham (scottla@us.ibm.com), Podcast Editor, IBM developerWorks
17 Jul 2007 Brian Bryson, technology evangelist for IBM®
Rational® Quality Management tools, talks about quality management of Web services-based
applications.
developerWorks: You're listening to a developerWorks podcast. I'm Scott
Laningham. Our guest is Brian Bryson, technology evangelist for IBM Rational Quality
Management Tools. He joins us to talk about quality management of Web services-based
applications. Brian, thanks for your time today.
Bryson: You're welcome, Scott. Pleasure to be here.
developerWorks: So I guess if we're going to have a discussion about testing SOA
applications, maybe we ought to start right at the top by quickly defining exactly what an SOA application is.
Brian: Yes, that's a good idea. Since SOA seems to be, it's becoming one of
those ubiquitous buzz terms that, you know, IT gets thrown around a bit as a kind of a
cure-all for all the ailed software, software development. And it's a bit of a nebulous
term. You know even if you go to Wikipedia, they don't even have a formal definition
for it yet. So I'll take a crack at it. And the sort of common definitions are, I guess,
it's basically an architectural style that builds systems by assembling loosely coupled
independent Web services. And those are kind of the key points: loosely coupled Web
services are kind of at the core of SOA applications.
 |
Guest: Brian Bryson
Brian Bryson, technology evangelist, IBM Rational Quality Management, is a
member of the quality management team that plans and delivers IBM
Rational's software quality toolset. Prior to joining the IBM Rational
group in 1995, he spent several years in QA. Holding various positions from
tester to QA manager, he studied and developed the best practices required
to implement effective quality automation. A certified management
accountant and former instructor at Carleton University in Ottawa, Canada,
he has delivered IBM Rational's message of software quality throughout the
life cycle to students and quality professionals.
|
|
developerWorks: OK, and you're going to talk about testing here a bit. So what
is SOA testing, then, after you follow on that definition then?
Bryson: Right. So for following on from that definition, the key concern for
testing SOA applications becomes the actual testing of these Web services that are at
the core. And you know, it's really no more — well, it's really no more
simple or more complex than that.
Essentially, you take the Web service, you feed it some inputs and then you ensure that
that Web service returns an expected output for that set of input.
developerWorks: It sounds a little bit like business as usual for testers, but
I'm assuming there's a little something more to it. So what makes SOA testing different or unique in your mind?
Bryson: Yes, right. So for testers, that is a very business-as-usual method of
operation — sort of provide input, validate output. But it does get a
little more complicated when you factor in that an application might quite possibly use
a Web service provided by like an external entity.
So you're not going to be developing all of your Web services; you're going to be using
other people's Web services. And in those cases, you have no guarantee of the quality of
that Web service. You know, if you're building stuff internally, you can trust your own development team
to provide quality. But if you're relying on someone else, you know, that guarantee of availability and quality, it just isn't there.
And that's where this gets tricky. So let's say I have a Web service that takes as its
input the output from another Web service. Now, if that first Web service goes down and
never returns a result to my second Web service, I've got a problem. And all this comes
from the whole loosely coupled part of SOA applications. It's really the core issue
here. You know, the implication for a tester, then, it becomes, for Web service
testing, you need to account for a lot more potentially bad or missing data that if you
were building a system based on your own development, you wouldn't have to rely upon.
And then it gets even worse. By definition, you're testing a system of components.
You're effectively doing unit testing.
So for your typical QA types, your typical QA professionals, they're more comfortable
from functional system regression testing. All these people are sitting down running
through test scripts, driving a GUI. So the paradigm of Web services testing, unit
testing, it can be daunting. It's not that it's exceptionally difficult, but it's a
method or mode of operation of testing that they're just not familiar with.
developerWorks: OK. So it sounds like, you know, the loosely coupled nature of
SOA applications is a benefit to organizations maybe in terms of reuse and flexibility.
But it also sounds like it can be a burden to testers in that it requires additional
testing which might be unfamiliar to them. Is that kind of what you're talking about?
Bryson: That's right. That's exactly right. But you know, the news isn't all
grim. The testers do get some reprieve here because of the nature of Web services.
So Web services are a W3 consortium standard. The good news there is that means Web
services have a clearly defined communication mechanism. Every Web service is called
the same way. That Web service might be built in Java™ or
Microsoft® .NET, but it presents the same interface, and the results are returned the same way.
So because of this standardization and this, the Web service communication contract,
you might call it, because of this tool support is very strong. There's no ambiguity.
The tools know how to communicate with a Web service. There's no two ways about it; there's one way to do it.
So this really simplifies the task of having to create tests and test cases to deal
with this unfamiliar test approach, having that standardized method just makes it, gives testers a break, essentially.
developerWorks: OK. So go into that a little bit if you would. Talk about the
tooling and how that helps, if you can.
Bryson: Sure. So IBM has a couple of tools for testing Web services. Probably
the most prominent one is the IBM Rational Tester for SOA Quality. And so with this
tool, you point it at a Web service, and what it will do is it will create a graphical
user interface, or a GUI, that testers can use to interact with the Web service.
Now what's great about that is that solves the first problem for the testers of working
in an unfamiliar paradigm. With the tool we're artificially creating a GUI environment
that's familiar to testers. We're letting them test the service by driving a GUI as
opposed to interacting at a unit-test level.
So using that interface, the tester provides the input data and then sends that off to
the Web service, and then the Web service returns a result, and then the testers use
what we call verification points to verify that the results from the Web services are
correct. You solve that first problem of the unfamiliar paradigm by making Web services
testable in a manner that's more common or typical for the QA tester.
Now, once the test is complete, we provide an interface for the testers
to supply additional data to the Web service. And this really gets at our second problem of the focus on data, of having to test more
cases the situation where one Web service goes down — how does the second Web service
react? By giving the tester this interface to provide more data, instead of having to
create multiple tests to validate the Web service, the tester creates one test that
cycles through multiple sets of data to validate all sorts of data input combination.
And so the icing on the cake here is that all this is done without having to write any
code or having really to understand any of the intricacies of a Web services architecture.
developerWorks: So you're talking about functional stuff there. Now I'm
wondering about performance testing because obviously, this stuff is delivered over the
Web. So there have got to be some performance considerations, right?
Bryson: Right. A good point, actually. And performance is absolutely key for SOA
applications. Like in a situation like I was describing before, where we have Web
services depending on one another, you have the situation where the first Web service
goes down and causes problems for the second one.
But a similar situation can arise with a slow response time. And a slow response time
from a Web service can be as bad as not getting a response from a Web service.
developerWorks: Right.
Bryson: There are definite performance and scalability concerns here. Now, one
of the nice things about our solution is that the same test that the tester creates for
functional testing can be used for performance testing. So we've got a second tool
called the IBM Rational Performance Tester Extension for SOA Quality, and it's the
performance testing cousin to the first tool, the Rational Tester For SOA Quality.
They're built on the same architecture, and they use the same test and data. So we're
even following that Web services concept of reuse. We're even getting reuse with our
tool.
developerWorks: Yes.
Bryson: Now, the difference is on the performance side, instead of taking that
functional test and running a single instance of it, on the performance side, what the
tool will now do is let you run X simultaneous instances of the tool. So I could say,
you know, run 1,000 simultaneous instances of this test and tell me how long it takes the server to respond.
developerWorks: So it sounds like with these couple of tools here, you've got a
pretty good handle on SOA application testing. Would you say so?
Bryson: Yes and no. We certainly have, you know, in the tools I've described, we
certainly have our functional side covered and our performance side covered. So, yes,
we do have a good grasp on the SOA application testing. But as Web services, you know,
a test that passes today may very well fail tomorrow. We're not just relying on
software here. We've got hardware as well, right? If a given server goes down, a test
that works today may not work tomorrow. So one of the additional complexities of Web
services is ensuring quality host deployment.
So it's probably worthy of discussion for another day, but it's a key aspect for
consideration here. And we have an offering called the ITCAM for SOA Quality that
ensures that post-deployment monitoring. And that really plays an important role in the success of SOA deployment.
developerWorks: Sounds like you're lobbying for another podcast here.
Bryson: You know, I like to talk. [LAUGHTER] So if you give me the soapbox, I'll hop right up on it.
developerWorks: We'll do that. We'll do that. Now as a wrap-up here, resources
for people that want to dig more into this. We obviously with the SOA and Web services
zone on developerWorks. Great zone with a lot of good content and tutorials and
articles. Is there something else you want to specifically point people to here before we wrap up?
Bryson: Right. So the zone would be the No. 1 place to go. And maybe one thing
that I'd specifically highlight is the trial version to this software that we have
available online. So you can go out and download from that zone or straight from
IBM.com, you can get to it either way — 30-day trial evaluations of
Rational Tester for SOA Quality if you want to do the functional testing, or a 30-day
trial evaluation of the Performance Tester Extension for SOA Quality if you want to do
both functional and performance testing.
So both of those are out there, 30-day trials, fully functional, download and go. And
try it on your own SOA applications to test your own Web services.
developerWorks: Well, Brian, thanks so much for taking some time out of your
day to talk with us about all this.
Bryson: Oh, my pleasure, my pleasure, Scott.
developerWorks: Brian Bryson is again technology evangelist for IBM Rational
Quality Management Tools. Check the show notes for this podcast for helpful links
related to quality management for Web services-based applications. You can find the show
notes at IBM.com/developerworks/podcast. This has been a developerWorks podcast. I'm
Scott Laningham. Thanks for listening.
Resources Learn
Get products and technologies
About the author | 
| | Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician. |
Rate this page
| 
