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

Using Amazon EC2 and S3 WSDL interface is easy. We ‘re impressed with the interoperability displayed between a web services client tool, Soap Sonar and Linux based products such as Amazon EC2 and S3. The interoperability is evident across a couple of aspects.

1: Class platform WSDL generation and consumption

2: WS-Security x.509 profile generation by .NET and consumption by the Amazon Platform.
The WSDL based interfaces provided by both EC2 and S3 are powerful for quick integration within existing web services aware management and provision products. We would like to see these APIs aggressively enhanced to include performance related operation calls, listing multiple instances much like the command line interface, and better authentication characteristics. At a minimum, the WSDL based API should be always kept par with command line interface.

Highlights of QA Role in Requirements Analysis Phase:
1. Pro actively participate with Business Analyst in requirements gathering.
2. Help the Business Analyst in preparing requirements specification document.
3. Help the Business Analyst in preparing Functional specification document.
4. Plan and organize requirements document and conduct formal and informal reviews.
5. Pinpoint ambiguous statements in the requirements document and discuss them with relevant stakeholders.
6. Help the Business Analyst in documenting Business Rules.
7. Plan and organize the formal and informal reviews of the Business Rules document.
8. Plan and organize the inspections of all requirements documents.
9. Prepare minutes of the meeting of every formal review and assign action items to relevant stakeholders.
10. Plan and organize formal walk through of all the requirements documents.
11. Separate functional and non functional requirements.
12. Plan and organize database architecture walk through on white board and write minutes of meetings.
13. Help the Business Analyst to prepare UML diagrams such as use case diagrams.
14. Discuss assumptions for non functional requirements with all relevant stake holders.
15. Make sure that all preventive measures are taken.
16. Prepare test strategies and test plans when requirements have matured.
17. QA scope identification and scheduling coordinated by the development manager. QA’s timelines are added in the master project schedule.
18. QA team plans internal audits.
19. Plan the number of testing cycles required.
20. Prepare application acceptance criteria.
21. Test Case preparation.
22. Test Scenario identification.
23. Test Data Preparation.
24. Test Bed preparation.
25. Prepare test data scripts.
26. Ensure test first development in Agile projects.
27. Prepare testing life cycle.

QA Role in Requirements Analysis Phase for Agile Projects
i. Help to communicate if user stories are not well defined.
ii. Suggest adding stories related to testability.
iii. make sure that people are creating good unit tests and/or write unit tests
iv. write tests for stories for test first development.
v. add stories for improving usability.
vi. verify the completion of stories as they are completed.
vii. Actively Participate in life cycle of AMDD(Agile Model Driven Development).
viii. Give suggestions to Business Analyst for improvements in Requirement Engineering protocols and practices.

QA Envisioning in the Analysis Phase:
1. What will be built?
2. When it should be built?
3. In what order should we build it?

Highlights of the QA Role in the Design Phase:
1. Plans and organizes design review meetings
i. Primary design review
ii. Critical design review.
2. Makes sure that process and protocols are followed.
3. For web applications, ensures that the design is w3c compliant and works fine in all web browsers.
4. Discuss application flows with Design Architect and Business Analyst and suggest them user friendly flows.
5. If issues are found in design review meetings, QA logs those defects in a bug tracking tool.
6. Assigns action items to relevant stakeholders and follows up with them.
7. Identifies possible concurrency issues for web applications.
8. Identifies possible deadlocks for web applications.
9. Updates design defects statuses and minutes of meetings.
10. Adds or updates test scenarios.
11. Assists design architects in design web applications with respect to web 2.0 standards.
12. Helps development teams to write/update unit test cases.
13. Plans and organizes unit test review meetings by coordinating with the development team lead.
14. Ensures company processes and protocols are being followed in every level of the Software Development Life Cycle.
15. Documents all the work being done by the developers in the form of data flow diagrams.
16. Helps in preparing the Design Specification document.
17. Makes sure that all preventive measures are taken.
18. Plans and organizes inspection of design document.
19. Prepares minutes of the meeting and logs them into the organization’s bug tracking tool.
20. Assigns action items to relevant stakeholders and follow up with them.
21. Make sure that all corrective actions are taken on design level issues before hand over to development team.

Highlights of QA Role in Coding Phase:
1. Prepares checklists for developers that contain standards and guidelines for them.
2. Ensures test driven development protocols are being followed and suggests unit tests to write.
3. Prepares documents containing coding practices and standards for the development team lead.
4. Ensures that defined coding standards, procedures and protocols are followed.
5. Ensures that code is properly commented.
6. Prepares conventions document for variable declaration, file names, file type, database table names and database field names.

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.