In today’s growing digital landscape, the need for projects to be delivered faster to market is becoming paramount for organisations. But still issues persist in delivering projects on time and within budget.
In a typical project lifecycle, the highest proportion of time and budget is allocated to software development and testing A project risk management approach will always try to mitigate risks that could turn into issues later in the Software Development Lifecycle (SDLC), leading to unexpected costs and increased time for delivering a solution. Some of the most critical issues faced by projects relate to the availability of integrated systems, environments and components, which is where service virtualisation (SV) can help.
This paper will discuss some of the benefits of SV and provide tips and tools to help Project Managers use this to deliver projects faster, both in DevOps environments as well as more traditional environments.
SV is a concept that can facilitate today’s software methodologies, helping to accelerate application development and testing to provide high quality products-to-market faster and allow for earlier engagement in the SDLC. It simulates unavailable integration points, removes third party constraints and eliminates project dependencies by simulating the expected application behavior before it has been developed, allowing teams to virtualise the end product’s functionality without the added overheads associated with having the integrated system in place.
SV facilitates the provision of continuous feedback to projects and can help plan for change, especially in Agile projects where design and scope is constantly being refined. The initial setup cost for SV can be low, and virtualized services can be re-used throughout the project’s evolution whilst being applied to many projects at the same time.
What is Service Virtualisation?
“In software engineering, service virtualisation is a method to emulate the behaviour of specific components in heterogeneous component-based applications such as API-driven applications, cloud-based applications and service-oriented architectures.” [Wikipedia]
A Virtual Service is an endpoint that simulates the expected response generated by a system. The virtual service endpoint processes incoming requests and mimics the expected response that the real system would generate. This means that if the application under development and test integrates with another system, that integration can be simulated by deployment of a virtualised service, meaning that application integration testing can proceed without the need for the integrated system to be in place.
Having an imitation of the required response from a system or application allows developers to effectively unit test code as soon as it’s written and iron out any potential integration problems at the same time. By removing integration dependencies, SV concepts are used to facilitate the Agile methodology and promote Development Operations (DevOps), encouraging projects to ''Shift Left'' in the SDLC.
The term 'Shift Left'' essentially means testing earlier in the SDLC and allowing iterative development cycles to refactor and test code.
Common Project Issues
During the lifecycle of an IT delivery project, project managers face a number of issues that can either delay the time-to-market or increase the project cost.
Below is a brief description of common issues a typical project might face during the SDLC and a summary of the ways in which SV can help mitigate each issue.
Third Party Integration Constraints
An application may have a number of integration points, some of which could be outside the organisation and not available when required during development and test.
I addition to this, third parties will potentially charge the project to stand up their environment for development or testing, so having a virtual service in the project’s hosted environment means that testing and development can continue to the required rate of change without external time and cost dependencies.
Having an imitation of the required response from a third party system allows developers to effectively unit test code as soon as it’s written and iron out potential integration issues at the same time.
Dependencies on other Projects
Implementing new solutions or enhancements can involve a number of projects working together or in collaboration. Often projects can be interdependent on product delivery, especially when technical solutions are required or shared amongst teams. SV can represent expected behaviour required for each specific project, eliminating the need to wait for other project teams to deliver their end products/solutions.
Application Dependencies Applications are usually dependent on services or architecture components being available in order to test code. In most cases an application under test needs to be fully integrated in order to understand how it will behave in the production environment. Providing a Virtual Service for an architecture component (e.g. database, file system) can eliminate the need to have the full system stack available, because the responses required can be simulated and integrated to the application using SV tools.
Environment Dependencies
Working in enterprises where each team is utilising the same development/test environment, it can be easy to run into issues of inconsistency or limitations on utilisation of these environments, leading to delays in development or testing. Virtualised services can be spun up quickly independent of environment availability, enabling testers and developers to continue coding and testing, providing constant feedback of the proposed solution.
Changing Requirements
As projects increasingly move towards Agile methodologies, teams work in more iterative fashions, and can be constantly refactoring and refining application designs. SV can play a key part in this process in order to help prototype design ideas from a service / architecture perspective. Additionally, it is not always possible to deliver technically requirements from the business in the timeframes required (Concept of Technical Debt in Agile). Rather than spend time on coding changes that have not been fully finalised or scoped, services can be built to test whether the architecture is able to support the underlying design. SV can help architects to fully understand the best solution for the application under development.
Time / Budget
The need to keep up with market trends in technology and deliver on time without compromising quality puts additional strain on project budgets and timelines. It is important to consider new methods and tools for product delivery that assist acceleration of application development and testing where possible. Using SV tools can help provide feedback earlier in the DLC ensuring that the risks are identified and eliminated earlier. The earlier the defect is detected the cheaper it is to fix.
DevOps & Service Virtualisation
What is DevOps?
“DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasises the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.” [Wikipedia]
DevOps is a philosophy, as well as an organisational change, that utilises new methods and tools to increase collaboration within IT departments and with the business, and to accelerate deployments. The business is the key driver in how technology is delivered and now more than ever requires project managers to include new methods of increasing productivity and increase the speed to market. In order to deliver faster without compromising on quality SV can be used to drive some of the key DevOps concepts.
Figure 1 illustrates a typical iterative development project from development to production. The system under test (SUT) in each phase of testing may have a number of iterations in each phase to develop and test code, and the integrations around the SUT are either virtual (Orange) or real (Blue) showing the use of SV tools in place of real integrations where they are unavailable or still under development. As can be seen, despite integration constraints and dependencies, the product can still reach production under the planned time frames and approach as we have considered the use of Virtual Services, providing feedback to each phase of testing and development.
Figure 1
DevOps provides a number of working practices which in turn help to bring products to market faster without compromising on quality, some of which are listed below, along with an explanation as to how SV assists with the described practices:
Continuous Testing and Feedback
Continuously testing code as soon as changes are committed allows for faster and more consistent feedback of the end product. SV can provide an environment that can be tested in isolation of integrated systems, therefore ensuring testing can continue even when systems are unavailable. Using SV also provides stability and consistency in the testing, as the response from a virtual service is static and the data used can be the same each time without amending the back end environments / databases.
Continuous Integration (CI)br /> Continuously integrating new versions of code allows projects to test the changes to code with a fully integrated product. Given that changes have previously been tested against a virtual service there is a high confidence level that it will work against the real service correctly. Again this ensures that defects are found earlier in the SDLC, eliminating any risks late in the delivery cycle.
Continuous Delivery (CD)
The objective of Continuous Delivery is to deploy products to production faster. Service Virtualisation helps us to test/develop earlier in the SDLC, thus faciliatation the delivery of high quality products to market sooner.
Automation
Test automation is a key aspect of DevOps, and much like development and testing, automation should be possible without having to rely on other systems, especially third party applications. SV will simulate the responses required from these systems in order to proceed with automated regression testing and sanity checking the code more frequently.
Automation test specialists do not need to wait until integrated systems are available in order to start building frameworks or begin scripting test scenarios. A virtual service can be used to simulate the expected responses from a system and provide the business logic required before coding has even began, allowing automation to begin earlier in the life cycle.
Business Benefits
SV provides a number of business benefits and contributes to a number of areas of the SDLC.
According to 2015 industry data, many organisations still have not experienced the benefits of service virtualisation in replacing costly or constrained systems, with 41 percent not utilising this valuable technology.
This is set to change, as organisations realise the power of service virtualisation in resolving bottlenecks in test environments - an issue identified by 60 percent of industry respondents. Moreover, service virtualisation is riding the Agile and DevOps boom, as more organisations leverage its ability to enable earlier testing and integration. [Planit Software Testing Index, 2015]
Infrastructure
Virtual services can be used instead of real services on a much smaller hardware footprint whether that’s a virtual or physical environment – a service can be simulated quickly without the operational or CAPEX overheads required for enterprise infrastructure purchases.
Performance Testing
Using virtual services can assist Performance Engineers with creating simulated scenarios that mimic system behaviour, allowing them to script and code earlier in the life cycle. It is common for performance engineers to have to wait until the application is fully integrated and is almost at the stage of deploying to production before being able to start any performance analysis. SV can help bring this aspect of testing forward in parallel with other SDLC activities saving time on the overall project plan.
Manual Testing
A number of permutations of response data can be achieved with SV tools in order for Developers to unit test their code and for testers to start testing the system before the point of integration and early in the SDLC providing Continuous Testing conditions. It also gives manual testers more testing time that will increase software application coverage as well as provide time for exploratory testing to uncover more defects.
In some cases, this can help tester’s prototype environments in order to write more accurate test scripts and help design the test approach including permutations of data responses.
Shift Left
In line with Dev Ops, SV allows us to test, build and deploy quicker to market much earlier in the SDLC allowing us to find defects before integration of applications. The term shift left essentially just means testing and developing earlier, moving the phases of development/testing as close to the requirements phase as possible, overall shortening the length of the project, without compromising on the quality of the end product to market.
Quality
SV encourages bringing products to market faster without compromising on quality. By providing the continuous feedback with development and testing we ensure that products reaching production have been through a series of feedback loops ensuring defects are not found late in the delivery cycle. The SV tools on the market are able to accurately behave just like the real system, allowing for intelligent stubs and variations of data scenarios.
Test Data
One of the key benefits of SV is data. In complex projects, data setup and configuration can be the most difficult of tasks to enable development and testing. Using SV tools, data can be re-used and scaled without impacting the actual systems. Data scenarios can be setup in line with project requirements and can ensure consistency throughout the development and testing of an application/system.
Data can also be used to drive the particular manual or automated testing. Business rules can be implemented in the SV tool, allowing for testers to complete aspects of testing without the reliance on other systems / environments.
Digital
The Digital industry is maturing rapidly and it is becoming more important to be able to deliver at speed and be the first in the marketplace for a feature or service that the customer wants. It is also imperative for brand reputation that digital solutions develop and deploy a quality solution that is compatible across different OS’, platforms and multiple devices. SV can help ensure device testing can be carried out on all platforms to simulate integration and resolve network related / compatibility issues.
Software Development Methodologies
In most SDLCs, projects conform to one of the methodologies listed below or will work towards a custom variation of the types mentioned. The methodologies are described below with respect to their use and benefit of implementing SV solutions.
Agile
Agile projects aim to deliver code in iterative development cycles, meaning small pieces of code are delivered to production faster. In order to facilitate this type of methodology as well as Automation, SV is a key driver. Agile encourages continuous feedback when coding and testing the product, in order to ensure defects are found earlier, helping to eliminate potential risks found late in the project lifecycle. Using SV enables this capability allowing developers and testers to have a real simulation in place of a system or service. During the iterative cycles, it is unlikely that an integrated system will be available, however the application under development / test requires accurate testing and feedback to ensure it will meet the target deliverables.
Figure 2: Agile Software Development Methodology – Iteration Example
Figure 2 above shows an example of a typical Agile iteration. Within a short development cycle virtual services will provide benefit because the end product would not be developed or completed in just one iteration. From as early as the requirements phase virtual services can be implemented to interact with the application under development, providing the feedback required to plan for the next iterative cycle or release ahead.
V-Model
As shown in Figure 3 below, the V- Model has phases of development and testing split up into the core areas of the SDLC that are dependent on each other with respect to the testing of the end product.
Figure 3: V-Model Software Development Methodology
Test plans and documentation are written at each phase of the SDLC. SV can specifically be realised at the unit and integration testing phases of the product.
Waterfall
This software methodology is more traditional in nature and works in a sequential process from requirements to delivery and maintenance of an application.
“The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.” [Wikipedia]
Figure 4: Waterfall Software Development Methodology
Even during more traditional software development methodologies, SV tools can be used during the design, implementation and verification phases shown above in Figure 4 to ensure testing proceeds without waiting for development to completely finish.
Service Virtualisation Tools
Market Trend
There are a number of market tools available that can create virtual services without the need to have complex technical knowledge. The idea is for the tools to do all the hard work and simulate real system behaviour. Some tools today provide the capability to turn technical specifications to virtual services, minimising the development effort in which to create a virtual service. The majority of tools on the market provide end-to-end integration testing solutions, specifically for testing and developing API’s/Microservices.
The tools range from well-known providers to open source. Forrester carried out some research on the capability of SV tools in 2014. Figure 5 is taken from the Forrester Wave report and demonstrates the industry’s leading tools for SV. In today’s market, we can fairly say the trend remains the same with a few additional competitors following as strong performers.
Figure 5: Q1 2014 Forrester Wave Service Virtualisation Tools Comparison
Service Virtualisation Products
Table 1 below shows a list of the available commercial tools and products on the market. The cost of setup for the tool is relatively low if considering the return on investment across projects and the overall time saved. Most tools offer an end-to-end testing solution allowing for testing of the integration of applications as well as testing of services, whether real or virtual.
SV tools in today’s market are specifically aimed at the integration services area, i.e. Middleware, ESB’s, API’s and Microservices, however are not limited to these areas of the architecture.
Vendor
|
Tool
|
IBM
|
Rational Integration Tester 9.X
|
CA
|
CA DevTest Solutions 9.X (Formerly CA LISA)
|
Parasoft
|
Parasoft Virtualize
|
HP
|
HPE Service Virtualisation 3.8.X
|
SmartBear
|
ServiceV Pro & Ready API
|
Tricentis |
Orchestrated Service Virtualisation (OSV) |
Table 1: List of Service Virtualisation Products
There are also a number of open source options available, which are a good fit for smaller pieces of SV work such as component stubbing or mocking, but will potentially require a large amount of customisation and maintenance should the wish be to leverage the SV solution enterprise-wide.
Types of SV Solutions
Today’s SV Solutions range from simple web services to tackling more complex areas of the architecture. The lower level virtualisation costs more for a project, however, will provide a stronger return on investment across an enterprise. Lower level virtual service solutions can cater for a wide range of projects across an enterprise, whereas virtualising at the API or application layer means we are creating solutions for specific projects or applications. It is important to ensure an organisational strategy approach is considered to ensure maximum return on investment.
Figure 6 below demonstrates examples of the types of SV solutions that the leading market tools can provide. The tools available can provide complex and intelligent virtual services that not only mimic the live service but provide added functionality in order to simulate business logic.
Figure 6: Types of Service Virtualisation Solutions
Cloud Solutions
For projects that only need SV on an ad-hoc basis, there are cloud solutions available and can act as a ‘pay as you go’ option to suit the budget and needs of projects, without the cost of implementing a tool into the enterprise architecture. Installing and configuring tools within the company can be expensive and time consuming, especially agreeing on a tool that fits for all projects / teams. Having a cloud solution means teams can be in control of the cost and time and gives the project the flexibility to scale as and when required.
Conclusion
To conclude, the paper has discussed a number of project areas of where SV solutions could be implemented. Regardless of the methodology, there are benefits of using SV tools as early as the design phase of a project. Using SV as part of the SDLC will enable higher quality products to market and ensure common projects issues are eliminated.
It is recommended that SV tools are considered from an enterprise level in order to receive the maximum return on investment as well as think about the toolsets that have already been purchased within the company. One of the largest benefits of SV is to are remove third party constraints, particularly where there is a cost associated or time constraint for its use.
SV has proven to be a success on a number of projects throughout New Zealand, achieving higher quality products to market on time and within budget. The IT industry has started to see more growth in this area, particularly within the Digital, Mobile and Internet of Things (IoT) domain where the need for faster application delivery has become increasingly competitive across vendors.
Find out more about our Service Virtualisation capability.
References
- Sharma, S. Coyne, B. (2015). DevOps for Dummies®, Wiley Brand (e-book). IBM 2nd IBM Limited Edition http://www.wiley.com
- Kaufman, M. Hurwitz, J. (2013). Service Virtualization for Dummies®, Wiley Brand (e-book). IBM Limited Edition http://www.wiley.com
- Lo Giudice, D., Gualtieri, M., Hammond, J.S., Curran, R. (2014) Service Virtualization and Testing Solutions, Q1 2014 The Forrester Wave™
- Testing Freak (2016). What is V Model in software testing and what are advantages and disadvantages of V Model, (Website) http://testingfreak.com/v-model-software-testing-advantages-disadvantages-v-model/
- Wikipedia (2016). Service Virtualisation, Wikipedia (Website). https://en.wikipedia.org/wiki/Service_virtualization
- Wikipedia (2016). DevOps, Wikipedia (Website). https://en.wikipedia.org/wiki/DevOps
- IBM (2016). Service Virtualisation Solutions, IBM (Website). https://www-01.ibm.com/software/rational/servicevirtualization/solutions/
- CA Technologies (2016) CA Service Virtualisation, CA (Website). http://www.ca.com/us/products/ca-service-virtualization.html
- Parasoft (2016). Service Virtualisation, Parasoft Virtualize (Website). https://www.parasoft.com/product/parasoft-service-virtualization/
- SmartBear (2016). Service Virtualisation, ServiceV Pro (Website). https://smartbear.com/learn/software-testing/what-is-service-virtualization/
- SpectoLabs (2016). Hoverfly Open Source Service Virtualisation, Hoverfly (2016). http://hoverfly.io/
- Tricentis (2016). Orchestrated Service Virtualisation, Tricentis (Website). http://www.tricentis.com/tricentis-tosca-testsuite/orchestrated-service-virtualization/