Testing Services provides a platform for QA professionals to discuss and gain insights in to the business value delivered by testing, the best practices and processes that drive it and the emergence of new technologies that will shape the future of this profession.

« March 2011 | Main | August 2011 »

July 28, 2011

Service Virtualization - Completing the Cloud Story

Organizations that have applications in production are required to have atleast 4-5 different sets of pre-production environments like System Testing, Performance Testing, User Acceptance Testing, Automated Regression Testing environments, to ensure 100% validation of the different set of requirements associated with an application. This in all probability increases the CAPEX budget for the organization. Organizations typically consolidate, virtualize and share these infrastructures for validating applications across different Lines of Business (LoBs). But this exercise is also bound to have significant OPEX associated with it due to the costs incurred in terms of having dedicated teams/personnel to manage the environments, rental costs and infrastructure costs. Also, even in these setups testing teams are constrained with situations like waiting for access to expensive test tool licenses/legacy systems, external/dependent systems, etc. In order to overcome these issues in testing traditional environments, it is but natural for us to look at the need to virtualize external/dependent systems using techniques like Service Virtualization.

Let us consider a scenario, where we have a Payments Processing Engine (PPE) which is currently undergoing changes and is hosted in a traditional QA environment. This PPE systems needs to talk to two major external systems, Legacy and Data warehouse, which are not currently available and are out of scope for testing. If the organization is to test the PPE system end-to-end, then they will need to acquire access to the external systems. Further, not being available on the virtualized environment is not the only constraint that this situation has to offer. Access to legacy system is expensive and it's made available in a 2 hour time window only. Also, the Data warehouse system is not available in the pre-production environment. When there are such constraints/dependencies on external systems, delays in time-to-market and increase CAPEX requirements are bound to bring down the overall testing efficiency. The way out for Organizations faced with such situations is to adopt Service Virtualization or virtualize services for all external/dependent systems, like the Legacy and Data warehouse systems in this particular example.

Today's market dynamics forces business to be more cost effective, agile and scalable to service ever changing market demands. The advent of cloud computing has made it possible for organizations to achieve the above mentioned points, in addition to helping organizations move from a CAPEX to OPEX business model. Though this movement to the cloud brings sizable benefits and cost savings, it doesn't however answer the question of dependencies on external systems. Organizations will need to spend huge amounts on setting up cloud images for these large external systems, making the entire process unfeasible. So, how can organizations do away with the issue of external system dependences in a cloud environment? This is where Service Virtualization comes in. With Service Virtualization, organizations can create virtual models of external dependent systems and bring them to the cloud as Virtual Services (VSE), with 24/7 availability and low cost.

Let us consider a scenario to understand the applicability of Service Virtualization in a Cloud environment.  Currently, we have an Order Management System (OMS), hosted in a cloud based environment, undergoing changes. This OMS system in turn needs to talk to 3 major external systems - Mainframe, ERP and Databases - that are not on the cloud and are out of scope for testing. If the organization is to test the OMS along with 3 external systems, then they will need to spend huge amounts in setting up the external systems - Mainframe, ERP and Database, in the cloud. This will result in higher CAPEX for the organization, which could very well blunt the cloud benefits of Cost Saving and Optimized IT spending. With Service Virtualization, the organization can host the OMS application in a virtual machine in the cloud, while the external/dependent systems - Mainframe, ERP and Databases, can be modeled and used as Virtual Services (VSE) implementations in the cloud. Thus by applying Service Virtualization all the external/dependent systems are provisioned at a fraction of the overall external system setup costs. With Service Virtualization, Organizations can achieve goals of elastic capacity consumption. Organizations can also cut down significant wait times associated with effort of infrastructure acquisition, installation and setup, and with accessing of external /dependent systems from months/weeks to a few minutes.

Thus with Service Virtualization, Organizations can achieve their overall goal/ objective of moving to the cloud and being responsive and relevant to the ever changing market dynamics and demands.

July 26, 2011

The move towards a modern QA organization

Managing the agility of application development has grown in importance as a lot of my customers are competing to dominate the market. The role of Quality Assurance teams to drive these changes is becoming more and more important. The QA teams should not only do testing but also champion the process so that our customer's software products and processes adhere to the requirements and plans......

 

Managing the agility of application development has grown in importance as a lot of my customers are competing to dominate the market. During my customer interactions I observed the struggles to contend with from a testing perspective towards agility and some of them are described below:

1.       Very aggressive release schedules and testing lag behind.

2.       Multiple development vendors develop code and code reconciliation becomes very difficult. How to ensure all the functionalities are reconciled correctly?

3.       There are dependencies with Internal and external systems. Some of these system test environments may not be available resulting in partial testing which increases the risk

4.       Difficulty in automated testing and maintaining tests as the application changes

5.       Perception of poor value from QA investment - imbalance between cost and perceived benefit of QA.

6.       Business expects to use "Customer experience" as a key differentiator in the market.  

QA also needs to become increasingly effective and modernized to address complex technology needs. At the same time, QA needs to overcome its project focused heritage and turn into an enterprise wide strategy to support over a broader technology / application spectrum, in a time bound manner.  We see this shift in the QA services to be a combination of the following 3 themes:

 

1.       "Agility in testing" resulting in Faster and quality defects  at lesser cost

2.       "Advance quality to earlier in the software lifecycle" resulting in earlier defect detection and minimizing cost of quality

3.       "Strengthen SDLC processes to for better quality" resulting in Lower App TCO

Agility in testing

Increasingly the business will not have patience for elongated QA cycles. The objective is to bring the required agility in the testing so that we can reduce the current testing cycles by 4 X . The following principles are relevant:

1.       Standardize Test processes & practices

2.       Automate as much testing as feasible: Tap a common set of QA tools for test automation - for different layers of the component-based architecture- UI, Web services and back end databases.

3.       QA to be delivered based on pre-configured test platforms tailored to respective industry challenges.

4.       Establish specialized functions for test data, test infrastructure management

Advance quality to earlier in the software lifecycle

We have followed some of the best practices discussed below for some of our clients

1.       Establish a methodology and a testing framework that emphasizes early life cycle validation. Testing teams participation in requirements, sprints, etc enables emphasizes the testability and supportability of applications.

2.       Improving upstream quality by use of Early Lifecycle Validation Strategies. Use of techniques like Predictive Performance Modeling, assessing Quality and Maintainability of Application code through tools can enhance the upstream Static testing process.

3.       Strengthen QA by introducing more comprehensive testing services in areas that are critical to the business: usability, performance, security, and data accuracy

Strengthen SDLC processes to for better quality

There must be a close mapping of quality parameters to the SDLC processes. This will serve as a leading indicator for informing stakeholders of the progress toward achievement of quality. The following are some of the things to look out for:

1.       Projects should link quality assurance deliverables with appropriate phases of the Software Life Cycle.

2.       A configuration management process must include controls critical to quality of deliverables.

3.       A change management process must identify and evaluate the quality issues prior to decision-making.

The role of QA teams to drive these changes is becoming more and more important. They should not only do testing but also champion the process so that our customer's software products and processes adhere to the requirements and plans.

 

July 7, 2011

Service Virtualization - Where is it applicable?

Service Virtualization is the new buzz word today. My belief is that most of organizations understand the applicability of Service Virtualization but, the real challenge they face is to understand its working.

Bearing this understanding, I landed at HP Discover 2011, Las Vegas, Nevada. Besides the blistering heat what hit me was that clients were still grappling with the very applicability of service virtualization.

A sample conversation follows.

A QA director from a leading fortune 500 company  walked up to me and as I was talking about Service Virtualization looked at me and said, in a rather loud tone, that Service Virtualization would never work for him as he was not a small-time product company. He added that Service Virtualization could at best be used for critical application testing in large organizations like his and nothing else. My response to him was a simple question, "Sir, do you know where service virtualization can be used in your organization?" After a long pause, he replied that he definitely saw no use for it in day-to-day testing at least.

I didn't know where to begin correcting his misconceptions. Over a long coffee break, I did share with him that Service Virtualization was useful to both small and large organizations. It was equally relevant to complex and day-to-day testing programs. Most importantly, every testing professional needs to understand its relevance to be able to decide if he needed it or not.

I have since revisited my earlier belief that organizations understood the business applicability of Service Virtualization. Between then and now, I have put forth this question to most of my client contacts and with every response I received, I was sure that the problem with the adoption of Service Virtualization was not in the understanding of the working of the solution, but more in terms of understanding the applicability of this solution given an organizations testing requirements.

So, here we go...Service Virtualization is an approach that is fast becoming a business reality. We need to accept this. With businesses changing every minute, the demands on IT to develop, implement, test and release quality applications, within shorter and shorter timelines, is growing rapidly. All these demands are putting significant strain on the resources that organizations have to execute these business requirements. When trying to respond to the demands placed by business, IT organizations are facing the constraints of cost, quality and time at every step. All these situations are perfect ingredients for organizations to use to understand, adopt and implement Service Virtualization. 

Let us consider a scenario to understand the applicability of Service Virtualization in an organization. Let's say that we have a Payments Processing Engine (PPE) which is currently undergoing changes and is hosted in a traditional QA environment. This PPE system needs to talk to 2 major external systems - Legacy and Data warehouse systems, that are not currently available and are out of scope for testing. If the organization is to test the PPE system end to end, then they will need to acquire access to these external systems. Besides this the systems in question have other constraints associated with them. For example, access to the legacy system is expensive and is made available in a 2-hour time window only, and the Data warehouse system is not available in the testing environment. In a normal testing situation, this organization will have no choice but to deploy these dependent systems in 4-5 different environments to ensure effective development and 100% validation of the different sets of requirements associated with the PPE business application. Though this setup would increase the CAPEX flow for the organization significantly, it still wouldn't help the organization answer the question related to the availability of the associated system to enable development and end-to-end testing. These would bring down the overall implementation efficiency of the program in question. The only way out for organizations faced with such situations is to adopt Service Virtualization.

With Service Virtualization, organizations virtualize services for all external/dependent systems, like the Legacy and Data warehouse systems in this particular example in multiple environments. This helps the organization remove dependability constraints associated with the non-availability of associated systems for ensuring effective development and thorough end-to-end testing.

In fact, Service Virtualization is not something that we use for the testing of critical applications only. It is in the situations of day to day testing and development that organizations will see the maximum benefit from Service Virtualization. Service Virtualization is also perfectly suited for ERP implementations that organizations plan. Be it a claims processing system, payments system, order management system, sales order system, be it anything, Service Virtualization is the only way we will be able to ensure the 100% validation of the system, with the given time, cost and quality constraints prescribed by the business environment.

Given the ever changing and demanding business environment that we operate in, I have no doubt in my mind that Service Virtualization is THE approach that organizations, both big and small, should adopt going forward. I borrow from Yul Brenner's famous line from the movie "Ten Commandments", Service Virtualization is here to stay "So it is written so shall it be VIRTUALIZED".