| || |
Life-cycle for testing SOA projects
Can someone explain the Life-cycle for testing SOA Projects?
(What are the actions need to taken at phase of developing SOA Projects)
Thanks & Regards,
Re: Life-cycle for testing SOA projects
Without more specific detail on your situation I can only give you some thoughts from my experience. I spent 2007 leading an integration test team in an SOA project which incorporated XML over message queue. Project consisted of front end portals (new consumers) calling back end legacy applications (existing providers) using an XML services via an Enterprise Service Bus (new) as the interpreter. My team used a test harness to send, trace and receive the XML service calls and had no interaction with the front end portals.
Testers MUST be in on the individual requirements reviews from day one. Strange as it may seem, most of our issues stemmed from the lack of communication between the dev teams of the consumers and providers. I.e. the specifics of what the providers needed to process requests were not documented requirements to be sent by the consumers. So ensure that all attributes are represented in the schemas and vise versa.
We wrote our tests by researching what services are to be requested by the consumers and when, then compiled the content of those tests by how the providers will be processing them.
We attained coverage using two matrix: 1)service flow v test cases and 2)test cases v attributes.
Some things to note from an integration testers perspective:
1. If unit tests don't verify the mapping of each attribute in each service through the interpreter (ESB), the integration testing MUST cover them all before system testing.
2. Each service will need to be tested individualy before composite testing (multiple services calling other services) can begin, sounds simple but you will find many inconsistencies so when raising defects be very carefull defining which service the error has occured in and when, could be multiple. **You do not want to go light on the details and have the developers fixing something that actually works?
3. If the framework doesn't validate responses against the schemas before sending back to consumers, validate manually, 30% of our defects stemmed from incorrect response population.
4. Boundary tests should be a low priority as the consumers (front ends) will uncover most of these bugs.
I hope this is relevant to your cause.....