For any hypothesis to be endorsed in today’s technological age there must always be a consequential upshot to refer to, whether as an artifact or a theory it must at least demonstrate some degree of relative proof that is worth trying.
Traditionally software-testing life cycle would include unit, integration, systems, and user acceptance testing but unfortunately the life cycle will not work for Service Oriented Architecture (SOA) that requires a high degree of agile methodology because of its incremental development approach, especially that SOA focuses on incremental builds, deployment, or code releases.
The incremental approach in SOA requires a matching testing plan (others would use strategy) that may be complicated to fulfil because of the limitations from the testing environments. The test environment problems that may confront a SOA project team in most instances would be because the environment required may not be available for a long time use. The provision and configuration of a test environment that can not mirror the production environment is a disaster waiting to happen, but having to change the test environment most frequently because of a SOA project will not only be a financial burden on the project stake holders but may also derail the project itself because of the testing iterations required. Certainly, the regression testing of every build to ensure that new code drop has not broken existing functionalities would be a challenge to the SOA project team.
Software quality assurance engineering is not about just testing the application under development but validating the application to meet the business requirement, hence requirement analysis is crucial to the testing process and life cycle, as the test and use cases developed by the tester must validate the actual user requirement expected to be delivered by the developers or project. It is therefore essential that the business requirement is simple, unambiguous, and testable.
The problem therefore arises when the test cases drawn from the business requirement become part of the SOA project life cycle, especially as an expected deliverable. It is highly likely that at that point there would be a brick wall to overcome by the testing team because the test cases execution would almost become unachievable.
To overcome the barrier it is highly recommended that SOA framework and test tools meet some functional requirement in order to accomplish the end-to- end testing that automates the business processes and supporting architecture effectively.
Simulation, Test harness, and stubs: It is highly likely that not all modules or adaptors will be completed or available during the initial development and testing phases, it is therefore imperative to simulate applications. Using test harness or stubs is a likely option. Some automation testing tool that can accomplish this approach effectively but are expensive, open source is not expensive but the security risks are the grey areas.
Interfaces: There must be a minimum requirement or expectation from every interfacing module in order to reduce the risk of improper integration to the lowest risk level. The messages going across must also meet a minimum requirement, all these must be criteria set by the quality assurance engineer.
Pass and Fail criteria: there are always two integral parts of a SOA project. The application and the data storage functionality on one hand and the component that supports the messaging on the other. The quality assurance engineer or tester must draw up detailed test steps that validates these two integral part of any SOA project.
Automating and messaging: the test scripts designed from the automation tool must be properly managed to deliver the required validation for the SOA project. The record and replay functionality in most automation tools may suit this purpose.
Taking the complexity of the Service Oriented Architecture (SOA) projects into consideration, the importance of message-based quality assurance framework cannot be over emphasised because of the ability to build set of services. The challenge of designing a message-based SOA for the testing team can easily be turned around as the message interactions between the component and the tools is established through interface messaging of repute. This is where the expertise of a good automation tester is required, if the rudiment that forms the foundation of the automation is missed from the onset the whole validation process may be in jeopardy. The understanding of what to do in SOA projects will help the Architects to define the messaging and interactions requirements needed to keep the validate within the scope of the test plan, especially the test matrix.
If for once we have identify a project where the traditional V-Model or testing life cycle cannot be achieved 100%, it is the Service Oriented Architecture (SOA), where integration and regression testing are the only relevant phases in the quality assurance life cycle.