I would recommend downloading both products and make sure that your WSDL load up properly first. Most products choke on sophisticated WSDLs so trying that out should be your first step. Next see how easy is it to build simple test cases. Subsequently you should try more complex standards such as WS-Security, SAML,WS-Policy, etc and see which product meet your needs.Also keep all aspects of testing functional, regression, security

DCOM and CORBA traditionally achieved what web services are now offering but with an exception to interoperability which they later provide in true sense.In addition ,COM+,DCOM (Distributed component object model) implementation from Microsoft were resource intensive and were native to specific Microsoft OS flavor.In other words,consumer and provider were mandated to be on the same version of OS.

Testing Methodology

At very basic level, one need to consider how the remote calls take place via SOAP, how the data is passed, how to test the transparent layer,discovery methods,response data,scalability,performance,integrity. Test Case execution shall be top down and bottom up respectively. Documenting test cases for the individual services can be tedious task and subject matter experts can take part in unit testing the individual service so that they are error free in down stream process. This approach facilitates meeting the high level business requirements and can also be used to create data contents for the exchange message. This will avoid the major pitfall of delivering a technically acceptable solution which fails to deliver business value. Once this is done, the data must be formatted to messages (XML) that express service service request and replies from consumer and provider respectively.

Test the Transport Layer

Due to problems introduced by latency and unreliability of the underlying transport, testing the transport layer (HTTP/HTTPS/MQ/JMS) – protocols which form the back bone  in shipping the messages around . This testing can be done in isolation initially wherein the transport is tested  with the messages sent over the transport as data files instead of actual data and consequently integrate with either side once the application is complete.

Test in isolation

Isolation can be achieved by storing message in data files . For instance , a message received  by a consumer can be saved to data file or a file. The emphasizes should be more on test the web service as an independent entity regardless  of its dependency on other web services The messages must be based on specific standard and some of the industries have already started  these activities, namely Association for Corporate Operation Research and Development, regulatory standards such as health insurance Portability and accountability Act (HIPPA) for health care related transections. Interoperability can be verified using tools available such as WSS (web service studio) for a MS.NET Implementation. The new web services studio can be used to automatically generate a compile SOAP proxy classes

Verify Complex Undo Activity

Testing the fragility  of distributed systems if incompatible updates are introduced to any participant may involve validating a two phase commit if transaction has not been completed using the entire web services involved in unit of work.XLANG verifies two phases of commit for distributed transactions wherein if transaction is incomplete, express it explicitly . Additional benefits are not limited to:

• Sequential and parallel control flow constructs
• Long running transactions with compensation.
• custom correlation of  messages.
• Flexible handling of internal and external exceptions.

Functional Integration/Testing Tool Selection

Verify the flow of application where the remote method call to the SOAP server(s), is followed in a specific order as per business rule which additionally involve verifying the nested functionality from WSDL. This may include testing for interoperability as sanity tests which validate the agreed upon semantics between the services.We ‘ve experienced that all good web services test tools share the certain features (1)Scan WSDL (file or URL) to create request and response structure. (2) Contain user interfaces to XML for request and response editing. (2.1) Response is stored as checkpoint.(2.2) Regression test compares check points to run time value.(3) Allow parametrized values for request and correspondence response (data driven) After determining the requirements of functional testing it is necessary  to examine some of readily available testing tools. we are having good expertise of using SOAPSonar for testing web services. There are following SoapSonar Setup Steps

• Download SoapSonar.
• Load x.509 & WSDL.
• Setup SOAP Authentication.
• Call EC2 Soap API

Picking a Project Management Methodology:

A short study from Vertebrae on choosing between an agile or waterfall approach for their latest software development project. We were having an internal meeting to pick a project management methodology for a web project we are working on for a new clients. As developers of commercial software, our instinct was to lean towards an agile based approach.

Metrics that Matter in Agile Projects

Agile methods need only the most important metrics: the ones that tell the whole story about the project. Metrics measure the health of a project and are by far the most objective ways by which a project manager enables all project sponsors and delivery teams to see where resources are needed or spent, or which areas of a project need more focus. So how do Agile teams determine the most important metrics?Like we ‘re collecting different metrics on different stages of our SDLC.

Agile Through the Waterfall

Many organizations have adopted Agile practices into their development methodologies and they have proved to be successful for the organization as a whole. There also are many organizations that have pockets of people who wish to be Agile, but can’t get traction within to make it a widely accepted practice throughout the enterprise. I recently had an opportunity to participate in an Open Space session where we explored how organizations that are mainly guided by Waterfall methodologies, unwittingly also employed Agile practices.

CMMI and Agile: Opposites Attract

The myths surrounding the compatibility of CMMI and Agile have recently been debunked by SEI. Learn how these seemingly opposing strategies can be paired to foster dramatic improvements in business performance! Despite the perception that CMMI best practices and Agile development methods are at odds with each other, new research suggests just the opposite train of thought. In fact, CMMI and Agile champions can benefit from using both methods within organizations, with the potential to dramatically improve business performance.

What Agile Methods Mean to Your Process, People and Products

Studies show that most successful projects were those that followed agile principles, proving that model-driven methods are not always the best when it came to managing changes, fastpaced project implementation, or even meeting market demands. The concept of agile development is not new. However, many technologists still stick to the age-old notion that software development can be easily designed and the outputs predicted without giving much
thought to the more dynamic factors of projects, such as communication lines, people, and change.

Which Life Cycle Is Best for Your Project?

When choosing a development life cycle, don’t just trust your feelings. Decide based on factors that really matter. Which life cycle will work best for your project? This is an important strategic question because making the wrong choice could lead to disastrous results of catastrophic proportions. Think about delayed deliveries, unhappy clients, project overruns, and cancelled projects.

Can We Combine Agile and Waterfall Development Strategies?

While there are likely as many unique Project Management approaches as there are Project Managers, there are two well-know production cycle methodologies that have been the topic of much discussion in PM circles – agile and waterfall methodologies. As I evolve in my own area of expertise, I am constantly reinventing small aspects of what I consider best practice. Most recently, to address the incredibly complex requirements of a large client imitative, I
challenged myself to come up with a “super” Project Management process that would not only improve the way in which we deliver, but what we deliver at the end of the engagement.  I determined there was a way to combine the best features of waterfall development disciplines with agile principles for superior results.

The Blending of Traditional and Agile Project Management

Traditional project management involves very disciplined and deliberate planning and control methods. With this approach, distinct project life cycle phases are easily recognizable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. For example, in a construction project, the team needs to determine requirements, design and plan for the entire building, and not just incremental
components, in order to understand the full scope of the effort.

As the project takes shape our testing team aims to explore and learn more about it. At the end of each iteration we look for bugs, missing features and also suggest improvements to our clients. We believe that a piece of software cannot be properly understood by us until we have thoroughly used it.During the course of the entire project our software testing cycle goes through the following steps:

Step 1
This includes a formal and informal inspection of all the documents required for software development and entails the following activities:
• All documents related to the customer’s requirements and business rules for software design and development are handed over to QA.
• QA reviews these documents to locate any discrepancy and raises it in review meetings with the developers, designers and the customer.
• Once the document is finalized QA prepares a Test Plan and shares with the relevant stakeholders.
• QA also writes test cases based on the requirements specified in the documents and then generates test data.
• The QA team Lead prepares traceability matrices and verifies test cases with actual requirements using these matrices.
• The team then prepares acceptance tests and shares with the developers, designers and the customer.
Step 2
At Mindblaze Technologies we emphasize test driven development. Our development team writes unit test cases first and then starts the actual programming. The QA team assures that all development protocols are followed and code is properly commented.
Step 3
If automated unit tests are successfully passed the development team then deploys the source code on the test servers for QA members. The development team clearly explains the testing environment to QA. This usually includes the following information:
• Tools that will be used to benchmark the testing server.
• How to take updates and install the latest builds on the test server.
QA then starts requirements mapping on the actual application by using traceability matrices, test scenario and work flows documents. The test duration is usually decided by the customer, QA Manager and the Project Manager based on scope of work.
Step 4
Depending on the needs of the project the Quality Assurance team may perform all or a certain subset
of the tests given below:

Step 5
A comprehensive Bugs Report is prepared by the Testers and review/verification is performed by the QA team lead before handing over this report to Development Team. In case any clarification is required on the bugs submitted, the QA Team lead discusses the bugs with the assigned developers.The development team responds by providing time estimates for fixing the bugs and apprises the QAteam of any changes that will be made in the software during the course of these fixes.The testing team then retests or verifies the bugs fixed by the development team and also performs a ripple analysis and runs planned regression cycles for assurance. During this entire process test reports
are submitted to the QA Manager and Development Manager. The criterion for ending the regression cycles is defined by the relevant stakeholders including the customer and the QA team lead.
Step 6
Once the software has stabilized and the customer is happy with its performance QA prepares an application stability report and shares it with everyone in the team. At this point the entire team also carries out a lessons learned exercise to understand any problems faced during the project and how to improve the entire process to better serve our customers.

18.Combination of supported development environments (like Java version).

19.OS specific cases.
20.Test with multiple user accounts and login as different users at different times.
21.Concurrent usage scenarios if applicable.
22.Performance boundaries -> Which variable effect performance of the product.
23.How can we verify accuracy or consistency of the system? (Is client and server
compatible, is repository data consistent etc.).
24.Are there explicit date conditions? Current date, future date, invalid dates, range of dates, expiry Dates.
25.What can cause corrupt inputs and how does system respond

Highlights of the QC Role during the Testing Phase:

1.    Executes testing strategy described in the test plan.
2.    Executes end to end testing cycles known as regressions.
3.    Performs acceptance testing.
4.    Performs black box, white box, integration and system testing.
5.    Performs load and stress testing.
6.    Performs usability testing.
7.    Performs concurrency testing.
8.    Performs security testing.
9.    Performs Alpha and Beta Testing.
10.    Performs Ad Hoc testing.
11.    Performs scalability testing.
12.    Performs usability testing.
13.    Performs sanity and smoke testing.
14.    Performs browser compatibility testing for web applications.
15.    Creates and presents test log reports and test incident reports.
16.    Logs defects in bug tracking tools.
17.    Assign bugs to relevant stakeholders.
18.    Performs regression testing.
19.    Maintains bug reports and categorizes them into in various ways. Category examples include:

• logic level issue
• GUI issue
• Database level issue.

20.    Performs ripple analysis when changes are incorporated into the code.
21.    Prepares ripple analysis report.
22.    Calculates DRE (Defect Removal Efficiency).
23.    Prepares bug sheet.

Highlights of QA/QC Role in Deployment Phase:

1.    QA prepares CRF (Change request form) template.
2.    Prepares installation/deployment guide.

Alpha Release

The first semi-functional version of the application is available for testing, mostly done at the unit level by engineers. Additional QA Resources are acquired to help with the testing cycles and the application is deployed in a separate QA environment for testing.

Beta Release

Software is considered beta quality when the features identified in its scope are complete and it has stabilized. At this point, development is exclusively targeted at fixing defects. Fixed bugs should outnumber new and open bugs. Defects continue to be found & reported and fixes are verified or rejected.

GMC (Golden Master Candidate)

This is usually the final build candidate and all severity level one and two defects are retested and verified. Severity level three and four defects are also tested to make sure the extent of the problem is known.

GM (Golden Master)

This is the final build where all severity level one and two defects have been fixed and all severity level three and level four defects are understood. QA signs off on the product and confirms that it meets all performance and functionality requirements.

A Tester’s role on Agile Projects:

First let’s take a look at testers in the traditional software development life cycle. Some examples of what we usually find are:

1. A separate QA group.
2. The tests are derived from detailed requirements and specifications.
3. QA may or may not participate in planning sessions, but is not usually privy to design considerations until after they have been finalized

Now, if we observe a tester in an agile project, we find that the tester:

1. is part of the team and attends all team sessions.
2. is an integral part of the planning game.
3. practices pair testing, i.e. collaborates with the developers to get good tests

Agile Testing Values

The four values that are part of the XP philosophy can be applied to testing as well. We will discuss what this means, and how they are applied to the tester role.

• Communication
• Simplicity
• Feed Back
• Courage

Understanding the tools

What tools does an agile tester need? Many of them are the same that a traditional tester would use, but applied differently. Some of the questions are listed below. I can explain them in comprehensive and precise way based on the demand of the customer:
1.    Can the same skills be applied that were learned in the traditional QA role?
2.    What is the difference between unit tests and acceptance tests?
3.    What is testing Life Cycle.
4.    What are different stages of testing cycle.
5.    How QA pro actively participate in requirements gathering phase?.
6.    How do you write an automated acceptance test?
7.    When would you do manual testing?
8.    Why use a risk-based approach to testing?
9.    What do we mean by Context Driven testing?

The Role of QA in Agile Projects

An interesting question in Agile Development is “how do you incorporate QA?” I guess this depends on what you see as the role of QA. For instance, if you have your QA people involved from start to finish, then you really wouldn’t have to change a thing. For instance, a QA person can:
•    Help to determine if your stories are well defined
•    Suggest adding stories related to testability
•    Make sure that people are creating good unit tests and/or write unit tests
•    Increase your code coverage by adding more automated tests
•    Write tests for stories for test first development.
•    Organize usability testing
•    Add stories for improving usability
•    Do exploratory testing on early builds
•    Verify the completion of stories as they are completed

All three practices are part of agile methods such as Scrum and Extreme Programming, but you don’t need to be doing these methods to take advantage of these practices. All of them are relatively inexpensive, and the return on investment for these practices is HUGE!

Without further ado these three practices are:
1.    A proper Team Room.
2.    Short Iterations.
3.    Test Driven Development.

A proper Team Room:

This is astonishing: you can expect a 60% boost in team productivity from this single practice! The cost of re-stacking your cubes or office space is trivial compared to the benefits. At MindBlaze Technologies we have created nice, open-concept layout with lots of windows etc. A single team has a low wall separating them from each other. Because of poor layout that would block communication paths, their new setup would actually be worse than their old setup! Some research has shown that you can expect as much as a doubling of productivity. It’s one practice you don’t want to let your competitors pick up before you do! We have some tips on agile team room setup.
1.    Light, Air, Nature
An appropriate amount of natural light, air circulation and live plants are excellent ways to make a space suitable for human occupation. The lack of these things can subtly but surely slow down and demoralize a team.
2.    Layout
People need to be able to face each other and work beside each other. They also need a semi-private space to have discussions or make phone calls. The walls of the space need to have large areas that can be used for white boards.
3.    Ergonomics
It is just not worth it to have a high-performance team hampered by a poor workstation setup. Good chairs, tables at an appropriate height, and the flexibility to allow individual ergonomic needs to be accommodated.
4.    Privacy
Every member of the team needs to be able to get away for short amounts of time. Some organizations provide separate mini conference rooms. Others allow staff to keep a private cubicle away from the team room.
5.    Personalization
The area of space that a person occupies needs to be flexible and personalized. People need pictures, toys, plants, and other incidentals to help them make a space of their own.
6.    Visibility to Outsiders
Other people in the organization need to be able to walk by to see and hear what is going on with the Agile Work team. Open doors, windows, formation of cubicles all allow this.
7.    Convenience
The space must be located so that washrooms, coffee, printers and other common services are easily accessible. It should not be set off and isolated far away from everything else.
8.    Noise
The team will be noisy. Make sure that other people outside the team room are far enough away or isolated in some way from the noise. It can be hard to balance this with convenience and visibility.

Short Iterations:

Once you have set up your team room, it is critical for your team to have something to do! The fastest way to get your team doing something is to start using short cycles of work (iterations, sprints) to deliver valuable results such as working software. Many software development projects use iterations that are two weeks long or even a month long. We strongly recommend iterations that are only one week long. Again, the benefits are incredible: your team will move through the stages of team development (forming, storming, norming and performing – much more quickly than with longer iterations or no iterations), thus leading to high productivity much sooner. The value here is in the time gained. This chart demonstrates how this works:

Test Driven Development:

The short iterations provide a certain type of pressure that forces team and project crisis to happen quickly. However, because iterations deliver working, valuable results, the pressure is not demoralizing, instead it motivates teams to get through the crisis and reach the norming and performing stages of development quickly. Again, to make this work, there are some critical success factors including methods of allowing team commitment, self-organizing and obstacle removal.
There is a myth that speed and quality are mutually exclusive. This comes from the idea that you need to slow down to make stuff high quality or that you need to sacrifice quality in order to go fast. It is true that initially you might get gains through these approaches. The really amazing thing happens when you try, deliberately and systematically, to do both high speed and high quality work. In software development this is best done through test driven development. In informal polling that I’ve done with teams I’ve worked with, test driven development produces a noticeable long-term productivity gain as well as a simultaneous increase in developer and end user satisfaction due to a substantial reduction in defects discovered after the code leaves the developers. I have seen teams doing this that reduce defect rates to 5% (or less!) of what they once were prior to test driven development… while at the same time delivering projects faster than expected. Since substantial expense is squandered on defect management (tools, support teams, user training, lost productivity, etc.) and since staff turnover is also high in IT and high-tech, the results of test driven development on the bottom line are substantial.

Benefits of All three steps:

If a team and an organization adopt these practices and get through the initial cost of learning them, then I would like to suggest that your teams can easily double their productivity if not more. For a team of 5 people working on a 100 day project this amounts to shortening the project to 50 days (save $200,000) or get twice as much work done. Clearly, an organization that adopted these practices and perfected them would save huge amounts of money and would be able to crush any competitors who are not doing this.