| COLUMN |
SOA application testing a combined effort |
 |
By John Scarpino
05 Nov 2008 | SearchSoftwareQuality.com
|
When multiple systems are located in different areas and do not share the same structural backbone, they can quickly become difficult to manage. Usually the best course of action is to implement service-oriented architecture (SOA), which will reveal the applications that make sense to keep and which ones require integration. The ideal result from an SOA framework is a workflow that is easily managed by the business and requires little maintenance.
SOA is a software solution that brings systems together that for various reasons would not traditionally be integrated. Sometimes, two systems can create a greater output by working together than individually, where they are known to perform slowly. The goal of SOA is to improve communication channels for the business process and the systems that the framework manages.
Business process testing (BPT) can become a significant add-on in terms of SOA, especially if the application's functionality is unchanging. This would require a software quality analyst to create tests that gauge the system's logical business process and weigh it against what the system was originally intended to do.
On the other hand, having subject matter experts create business tests allows the "business process" test plans to be documented without much intervention from a quality analyst, who would undoubtedly feel the need to create detailed test plans for those functionalities. Where a quality analyst's test plans would be necessary for testing the details of a database, they are not needed for SOA implementations. The SOA framework is select, championing integration, security, and performance.
It is also important to note that the software quality analyst should sign off on all business process tests to ensure that it not only tests the positive functionality of the application but also the negative functionality.
Utilizing subject matter experts and BPT to test an unchanging system makes sense because it cuts the time needed to have software quality assurance (SQA) intervention (depending on if the system already has "good" quality). However, BPT procedures that are created by subject matter experts should not be used as the sole justification for a test plan. The main purpose of BPT is to test processes -– and it is a perfect method for testing against back-end changes like SOA and Electronic Data Interchange (EDI). This also applies to a front-end user perspective, as long as the other risks to what is being changed and implemented are tested fully by software quality analysts.
Architects hold an integral role when it comes to SQA implementation. The architect is the analyst that reviews the entire system to determine which business systems and processes need to be changed, configured, or substituted. They then put into place the SOA framework based on how the systems should communicate. Software quality analysts must work with this individual so that they can determine which system holds the highest risk and in what way they should perform an analysis for testing. Prioritization of the system would then be made so that quality analysts can work with subject matter experts for functional testing.
To learn more about my SQA involvement in the implementation of an SOA framework, listen to this webinar "A Practitioner's Perspective: TelCove on SOA Best Practices."
-----------------------------------------
About the author:John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.
|
|
|
|
