SOA in details

SOA (Service Oriented Architecture) is an Architectural style, which is modular, shareable, distributable, and deals with defined interfaces. It is about the design of the business, focus on Business Processes / Business Driven; hence it is more than Web services!

Prior to SOA, a user or Financial Advisor needed to get into the business process of logging in, checking the credit, and getting into the loan quotation service and so on, which in response led to legacy/third party segment, i.e., the communication was possible via mainframe and its network, but now with the advent of SOA and Web Services we have an interface to the outside world.

The business risks involved are, increased costs, early joiner – when there is little knowledge, no business commitment and resource available, no overall picture of business processes and ability to prioritize, quality – single point of failure, the industry decides that the future isn’t SOA after all!

While the benefits are: reuse of code, reduced IT spend, and above all faster time to market.

Main Challenges and tips to face them

SOA fundamentally changes the traditional testing approach, and hence the testers face challenges like, scope and boundaries, changes to composition of test team, increased knowledge required of testers, technical knowledge (WSDL), domain knowledge, use of tools, governance and the need for standards, and increased focus on negative and non-functional testing.

To address the challenges, the Test Design should follow a top down approach, Test Execution should follow a Bottom up Approach starting at the individual service level, and the current testing methodologies should be extended to support the use of services in an SOA solution. Adding to it, the testers need to execute Functional and Regression Testing, Performance Testing, Security Testing, Integration Testing, and Interoperability, by meticulously planning the process.

Conclusion

SOA is here to stay for the foreseeable future and this will mean a different relationship between IT and the business and as a result testing will need to change. Hence, SOA will change the organizational testing methodology, and hence the testers’ skills and the approach will need to change accordingly.

Exposing systems to the internet increases the risk that security weaknesses in those systems will be leveraged to compromise the system or the underlying data. Further, the organizations risk direct financial loss, loss of reputation and legal repercussions. It is therefore necessary to examine the actual business risks this brings, understand the basic difficulties in implementing “secure systems”, and adequately test internet applications for security, as well as functionality and load performance, before they are exposed to the net.

Testing, the security testing in particular is a solution to mitigate these risks. Security testing of internet solutions provides two fundamental services, it allows cost-effective selection of security controls at all stages of the project cycle, allowing proper integration of security measures (procedural and technical) into the final solution and gives the Management a firm evidence of the level of security provided, showing that, in the event of a security breach, “due diligence” was exercised, which may limit damages claims or criminal liability.

Testing a system involves a number of separate checks. The infrastructure design should be implemented to allow secure operation, site functionality should be examined to ensure that access to sensitive information and administrative functions is protected appropriately, services necessary for the business process should be running on web-facing servers (the more different systems, the greater the likelihood of a serious flaw), network traffic should be monitored to check for plain text transmission of user names and passwords (whether related to site users or to back-office functions such as databases).

If flaws are found, detailed analysis should follow, which will attempt to identify software patches, replace service daemons or applications, or additional technical issues.

The new Regulation National Market System (Reg NMS) has brought in major changes in the structure of the equities markets in the USA. As the original NMS framework dates back almost three decades, it is obvious that the old framework cannot fit into the intricate trading systems of the present era. The present modernized and strengthened structure has brought in four major rules, The Order Protection Rule, The Access Rule, The Sub-Penny Rule, and The Market Data Rule, which necessitate the organizations to place quality at the forefront of the implementation. To achieve the desired quality, organizations must adopt a meticulous and rigorous testing approach across the program, and this in return will provide two significant benefits:

• Compliance with the new regulations for Reg NMS
• An application/infrastructure that is robust.

IT spending on Reg NMS compliance technology is estimated to be more than a hundred million USD ($100mn). This has clearly revealed the significant impact the new regulations are having on the trading companies. However, as with most initiatives driven by compliance, it requires organizations to invest wisely – both financially and in time – to implement a quality system that will provide additional business benefits. In making these significant changes, it is imperative that the organization places quality at the forefront of the implementation.

AppLabs believes that quality products are the key factor to assess the level of readiness in terms of compliance criteria and achieving the substantial business benefits of a robust system. Organizations should be very careful when implementing the new trading system; by understanding the detailed requirements of Reg NMS one will be able to formulate a comprehensive testing approach to meet the required business objectives.

To increase competition and consumer protection in investment services, there emerged MiFID (Marketing in Financial Instruments Directive), a highly developed version of ISD (Investment Services Directive), a harmonized regulatory regime for investment services, intended to create a more open, competitive, and transparent market for financial services across the European Union.  With the deadline for MiFID looming large, many organizations operating in the financial markets are compelled to think about the systems they will need in place for them to adhere to this new legislation.

With technology underpinning MiFID concept, it stands a mandate that companies fall well within its compliance limits.

However, in implementations of this nature, many often fall short due to inefficiencies in quality assurance and testing. And if the loopholes appear in MiFID strategies due to inadequate testing procedures, serious problems like financial penalties, damage to the company’s reputation, the start of a problematic relationship with the FSA and above all, failure to adhere to this legislation could result in legal consequences for the business.

For the MiFID compliance, AppLabs ensures that the coverage and prioritization of testing meets the needs of the business and reduces the inherent risks involved in making high-impact changes on IT systems. AppLabs analyzes, re-engineers, upgrades or even replaces the key applications. AppLabs provides the new levels of regulatory reporting and transparency, timely provisioning and testing of such systems, which ensures a definite edge in the marketplace. In addition, AppLabs performs interface and integration testing for matters such as publishing ‘firm prices’, getting data for the best execution and transaction reporting, audit trail and so on. Performing of comprehensive regression test suites, automates the extra information required for the new Suitability and Appropriate Tests, customer categorization information, changes to the underlying database structure and so on. This provides tremendous benefit to an organization introducing new functionality in a faster pace.

AppLabs is significantly enhanced to satisfy the new demands of MiFID to support the Best Execution directive. To avoid further risks, AppLabs, in addition to the comprehensive regression test on existing functionality, conducts performance testing, as at this stage it is fundamentally important since Best Execution relies on market data being available in real-time with trading systems and market feeds potentially under heavy load. Capacity planning and so-called database bulking are also the important parts of this testing process.

Compliance with MiFID hence implies major rework and enhancement of a variety of IT systems within many investment companies across the EU, and above all the pressure of the deadline. It has therefore never been more important that affected companies plan and execute thorough regression and performance tests, while also deploying monitoring technology to ensure compliance with MiFID once new or enhanced systems go live.

Securitization is a means of raising finance secured on the back of identifiable and predictable cash flows derived from a particular set of assets. Almost any assets that generate a predictable income stream can be securitized. Securitization allows a company to separate financial assets from credit, performance and other associated risks. The result is the reduction in the amount of capital required to finance the company, which helps in removal of pooled assets (the assets which are securitized) and related debt from the balance sheet, funding at lower costs than otherwise available and in the improvement in liquidity, investors get secured debt instruments as against unsecured corporate bonds in traditional finance and the borrowers get an indirect access to the securities market and benefit from the increased availability of loans due to enhanced liquidity of the issuer.

To set up Securitization, certain mechanisms like, data capture and reporting, securitizing the Pool, setting up and running the Special Purpose Vehicle (SPV) or Issuer, and maintaining the Pool in line with the select Securitization model, must be identified, developed and implemented. With these mechanisms in place, the Securitization stages like, identifying what Business can be securitized, taking the Pool to the Market and securitizing and maintaining the Pool are achieved.

As the whole process deals with value of the business and risks to the business revenue, an intensive testing of the process for all the phases is mandatory.

AppLabs, with its hugely successful track record of testing in the Financial Services sector, can produce rigorous, risk-based and gap-less test processes that will greatly reduce the risks in a Securitization program and, in particular, identify and correct any invalid entries in the Securitization Pool. This consideration alone may well produce a Return On Investment (ROI) which is many times the cost of testing.

Static Testing is a well-known and beneficial concept within the testing space, but tightened budgets and looming deadlines can hinder the benefits. Here are few suggestions on how taking a risk-based approach to static testing can help realize the benefits.

Implementing Static Testing
For implementing static testing, it is advisable to create a small dedicated implementation team with specific roles. It should include the Process Champions who would be backing the process, the Trainers, and most importantly the Implementers, who will need to develop and document the process; examples of the process materials and collateral required are, Static Testing Policy, Strategy; Review Process, Review Techniques and Guidelines; Templates – Review Logs, Review Metrics, Document Review Matrix; Training courses. The other factors to consider for the implementation are, verifying the internal materials by using the process and templates and involving people from different projects/teams in the development of the materials.

When actually implementing Static Reviews, experience has shown that a phased approach is often best, both in terms of minimizing the impact and also being able to demonstrate early benefits as a result. For this reason AppLabs recommends an approach making use of a pilot and then a full implementation:

The strategy behind the pilot approach is to provide a least risk environment which will allow early demonstration of some or all of the benefits of Static Testing. Having experienced at first hand how this approach can provide a successful basis for further implementation(s), AppLabs has recognized some essential factors that will contribute to success.

• Target small area/project that is ideally in (or not much later than) start-up phase;
• Establish implementation plan;
• Train nominated project staff;
• Execute Review techniques on selected documents;
• Evaluate success of process, training and process materials, and identify areas for improvement;
• Rework process and training materials as appropriate and create baseline set for publication.

The full implementation of Static Testing should build upon the success of the pilot and it is particularly important to document and publicize the benefits demonstrated by the pilot.

Risk-Based Static Testing
While conducting a risk based approach to static testing, identify the product. Compile a list of all the deliverables that are going to be created or changed by the work that you do. For each of the identified products consider the associated level of risk, assign a rating to each product accordingly. Establish a product review matrix, and then plan a review technique- formal and informal. Include Inspections, Structural Reviews and Walkthroughs while conducting the formal review. And for the informal review employ “Buddy Checks”, a simple peer review of the artifact and Desk Checks. A pre-requisite to any review should be that the artifact in question has been quality checked by the author. Most importantly, identify the right people to involve in reviews – rotate responsibility to encourage cross-skilling, and to keep the process ‘fresh’.

The major purpose in Risk Based Static Testing is early mitigation of risks with the most appropriate use of time and resources. Industry statistics have demonstrated that identifying and correcting defects at the source document stage is several orders of magnitude less costly than correcting them in the development or dynamic testing stages. The British Computer Society estimates that for a 3% investment of the overall project budget in Static Testing, 70% of defects can be found by eradicating assumptions and ambiguity from documents before a line of code is written or a system is configured.

As trading has become electronic, trading applications need to be reliable and effective; emphasizing more on the speed of delivery with peaks and troughs in demand. And the answer to these demands is Performance Testing, a beneficial testing strategy in terms of cost -the cost of fixing a performance defect (flaw) is many times more compared to fixing a functional defect which could just involve rewriting a few lines of logic (code).
AppLabs, with its wide spread experience in this arena, has conceptualized certain strategies to help clients in addressing all the risks related to performance testing of trading applications. This successful test strategy hinges on the following aspects:

Fit for ‘purpose’
Ability to address all the pain points

AppLabs has implemented ‘TRADES’ Heuristic Model to help strategize performance testing for trading applications. This model promotes a structured ‘thought process’ whilst taking into account critical drivers; ‘business needs’, ‘performance objectives’, ‘risk’ and ‘budgets available’, thereby helping to choose the ‘right’ test types and techniques to be employed.

A careful analysis of the technology and application stack that is within its control can help identify the performance bottlenecks and come up with recommendations for right infrastructure, configuration and tuning. Challenges in building a real time performance test environment may be overcome through emulators and simulators. Additional probes may need to be written to augment the performance metrics capture capability of Commercial Off The Shelf (COTS) performance testing tools. Only competent performance test analysts can draw inferences from the performance test results and come up with recommendations to meet the performance objectives.

AppLabs, with a decade of experience in performance testing, is a leader in this space. Our extensive expertise in market tools, simulators, emulators and custom scripting needs of complex performance testing engagements has provided business benefits to a number of banking, financial services and insurance enterprises.

The exponential growth of online transactions with credit and debit cards, though has facilitated the process, but has made itself susceptible to insecurity; it has opened the gateway to greater and devastating security risks. Thus emerged the need of curbing this issue with a set of security standards which is known as the PCCI DSS, the Payment Card Industry Data Security Standard (PCI DSS), created by the major credit card companies, intending to protect their customers from increasing identity theft and security breaches.

Virtually all businesses, regardless of their size, need to understand the scope of PCI DSS, and ways to implement network security that is compliant with PCI DSS guidelines. In doing so, they will avoid penalties or the possibility of having their merchant status revoked and potentially being banned from accepting or processing credit cards.
AppLabs, an independent software company, is such a service provider, which is compliant with PCI DSS guidelines and satisfies the PCI DSS requirements, which include security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations to proactively protect customer account data.

For the compliance process of PCI DSS, a multifaceted security standard, AppLabs conducts an annual onsite PCI and sometimes a Self-Assessment Questionnaire (SAQ), which is filled in to validate the compliance. In addition to this, AppLabs scans the network perimeter by an Approved Scanning Vendor (ASV) every quarter, submits the report and hence highlights the compliance status, network vulnerabilities and vulnerable services classified as per the scoring pattern and severities prescribed by PCI DSS. The evidences of these and  the application and network penetration tests are shared with card brands, hence proving that that AppLabs’ practices sound patch management and vulnerability management processes.

Trends like Web based  applications, Service Oriented Architectures (SOA), Software as a Service (SaaS), Wireless Technologies, Mobile technologies, with the increasing emphasis on repeatability, reliability, re-use and robustness, has opened a new path to testing, emphasizing more on Analysis and Design phases and ensuring early engagement of testing in these areas.

Analysis and design have been people based activities with Business Analysts and Systems Architects producing a combination of natural language, some structured language techniques, models and diagramming techniques, hence leading to business requirements and functional designs which do not meet the four key criteria which make the resultant systems ‘testable’. And to make the quality of the application clear, assumption free, unambiguous and complete, with the limited time, we will need a more structured and more automated analysis and design technique, which can be attained with robotizing the Static Testing.

In this new world, the Professional Tester will need to further concentrate on adding value to the business and the software development lifecycle and will hence need to operate in a new and elevated position where the combination of their structured process driven approach, creativity, destructive inquisitiveness and ability to articulate and define quality and testing criteria into the models will be critical to the success of the business implementation of technology. 

The role of the Professional Tester will now become more interesting and more essential. And so will Testing and Quality Assurance, which will become more important and add more value as we move into architectures and technologies which support the business in their goals of bringing products and services to the market as rapidly as possible, with minimal risk. We will see a shift towards testing the transformed business operation, the business processes, the way people interact with the systems and processes and the information it provides, and therefore mitigating the risks and increasing the benefits of business change.

To ensure the success of development projects in an Agile environment, engage the test teams from the start, and by the by have the previously independent contributors (Business Analysts, Developers, Testers, End Users etc.) work together in teams.

An Agile development uses a ‘Test Driven Development’ (TDD) approach. An approach where the team and the project stakeholders all contribute to kick-off meetings where the ‘user stories’ are selected for the next sprint (Sprints in an Agile project can extend to multiple levels in a complex system), which are used as the basis for a set of tests. The testers create test scenarios, which after the approval are broken down to test cases, which further offer adequate test coverage for the given functionality. The developers then write code that will pass the tests. In this approach the development and testing take place continuously throughout the sprint, for minimal defects and low implementation risk. As functionality grows with each iteration, regression testing must be performed to ensure that existing functionality has not been impacted by the introduction of new functionality in each iteration cycle. Defect fixes should also be followed by extensive regression testing.

The scale of the regression testing grows with each sprint and to ensure that this remains a manageable task the test team should use test automation for the regression suite and focus their manual testing effort towards locating new defects during the build phase. In the Release Phase, prior to releasing a product, a final acceptance test is performed before transitioning the application into production. The testing activities listed above are not exhaustive but broadly cover the areas which the testing team contributes to the Agile approach.

Engaging test teams from the beginning of every iterative development cycle and not just after the first couple of sprints will hence ensure an accelerated delivery of working software. And the testing team in return must develop the necessary mindset, wherein their own agility and flexibility will prove the key to their success in the project.