Friday 17 December 2010

Service-Oriented Architecture (SOA)

What is SOA?


SOA stands for service-oriented architecture. SOA consists collection of services and these services communicate with each other. A service is a unit of work done by a service provider to achieve desired results for a service consumer. The main idea behind developing services is to achieve re-usability. A service will be designed or build by the service provider and that service will be used by the consumers depending on the need. For examples a payment gateway is an e-commerce application service provider that authorizes payments for e-businesses. Payment gateways protect credit card details by encrypting sensitive information to ensure information is passed securely between the customer and merchant

SOA and Integration testing 

There is impressive rise in the use of SOA and integration to provide better business process visibility to organizations mainly Insurance and Banking sectors. The ease and low cost of integrating new systems together makes SOA a well-organized and valuable business asset. However challenge remains in testing SOA as its architecture coupled with many systems and services. So how can the testing world ensure all those crucial parts are working properly?

Integration testing is a crucial phase in SOA testing where it will give more insight to see what’s happening inside the SOA environment, communication, message flows, transformation rules. End-to-End testing identifies defects and corrects them before the defect causes serious workflow interruptions

SOA Integration testing challenges 

Defects in the SOA environment is very difficult to diagnosis because data in the messages is transmitted in protocols which is inaccessible to the typical tester as a result these defects usually aren’t seen until the full system can be tested at the very end of the project which is more costly to fix

Data will be usually transmitted in the form of XML messages. Testing team has to understand and verify the various sections in the XML messages by validating against the transformation rules defined for the systems

Data communicated within the different systems will not be the same as data will be converted bases on the systems and services

SOA and integration environments are made up of many components like Web Services, enterprise service buses, legacy systems, databases and files

Role of the testers
  • Testing team should understand SOA architecture 
  • Use of test harness to validate message transformations and business rules
  • Understand XML schemas and preparing test data based on the schema, transformation rules and business rules
  • Closely working with development team some time need to become a communicator between different development teams to validate transformation rules 
  • Testers must be much more technical and understand how to work with SOAP, WSDLs, networking & telecommunication concepts and various platforms and technologies (Java vs .Net, Windows vs Unix/Linux vs. mainframe, etc.)









Saturday 20 February 2010

Decision Making - Open Source Tools Vs Commercial Automation Tools

I found very difficut to make my strength of mind to choose between open source and commercial automation testing tools for any given application to test. Usually, it’s best to do a feasiblility study on both commercial and open source solution so that we can choose a best fit for any project/application. However, there are some basic points we can use in our decision making.

I see three key points that make difference between Commercial and Open Source tools - Support, Price and Easiness

Commercial Automation Tool Benefits

Support: Commercial Automation tools provide incredible support to the corporate world. If we need support in cruch, commercial support is the best way to go

Cost: Commercial tools are high-priced which is justifiable for the kind of support they provide

Easiness: working on commercial automation tools is much simplier than open source.

Open Source Tool Benefits

Support: Self-support, if your company allows it, you can fix the bugs you find in the tools yourself. No need to wait for a third party to get around to fixing them. Opensource basically implies that you can customize and tailor the tool exactly to your specific needs

Cost: it's hard to compete against free .Open Source per definition does not mean free of charge or worse or healthier than commercial automation. However, it gives a clear indication that besides the commercial tools, there are lot of free open source alternatives

Easiness: Open Source projects tend to adapt open standards more readily than commercial products