Differentiate yourself with life cycle testing
ScottNiemann 270003Y0JB Visits (5002)
You hear lots about “testing” in all industries, as testing leads to reduced defects, which leads to quality. Automation is even better as it decreases the time testing, which decreases costs, which is expensive as it can consume over 50% of the entire cost of delivering product in some industries. In the case of telcos, this means happy customers that will be repeat customers. Customer churn for service providers is prime concern in the Telco industry on a global level.
In my experience, I’ve been involved in testing of a product in all aspects of its development. In all aspects I mean from its inception before a line of code is written, to where I’m sitting outside with a mobile phone doing actual field testing. So when I hear the term “testing” I always think, well what we are talking about? How do you test something without a line of code that you can compile and run? How can you test a complex service with so many dependencies on other systems reliably?
This got me to thinking that while there are certain savings associated with test automation practices and test virtualization, if one were to sort of put all testing practices together throughout the inception to deployment of a telecom service; one could really get a leg up on the competition in their industry. Let’s consider the software development lifecycle of a telecom service or some support system, by looking at the V-Model
Whether you do V-model development or not is irrelevant, it’s a nice way however to show where testing can be applied. Starting at the top left, there is an implication here that we are thinking about our test cases as soon as we can come up with the requirements, which of course is good. However, how do we know there are not mistakes in Requirements Analysis? There could be lot of ambiguity between what the customer is requesting and how our developers are interrupting it. In the end we don’t know unless there is a way to perform some analysis before we get to coding something. Enter the concept of model driven development, which is applicable also to the telco space. One can create models using a formal language that has formal semantics that can be executed and validated against customer expectations. This type of technology has been around for over 10 years, but using it at the level of requirements specification is relatively new in some industries. Using a language such as SysML or UML to model the use case of the systems, and intended scenarios of the service, how it will interact with other systems in this complex environment can be modeled and simulated in order to prevent ambiguity further into the design cycle. This is called reducing defects early… way early. The earlier they are reduced, the less impact that will have later on, and much less costly to fix.
Now developers know how to unit test, but it gets a little tricky when we need to start integration testing in complex environments. In enters test virtualization for services. Why do you need test virtualization in the telco world? Well complexity. A typical investment to build a single test lab for a Fortune 500 company can range from 5-30 million USD, and the amount of test labs required increases year to year. Some of the key issues addressed:
· Costly 3rd party access fees: Developing or testing against Cloud-based or other shared services can result in costly usage fees
· Impractical hardware-based virtualization: Systems are either too difficult (mainframes) or remote (third-party services) to replicate via traditional hardware-based virtualization approaches
The benefits of test virtualization are as follows:
· Virtual Services simulate the behavior of an entire application or system during testing
· Virtual Services can run on commodity hardware, private cloud, public cloud
· Each developer, tester can easily have their own test environment
· Developer and testers continue to use their testing tools (Manual, Web performance, UI test automation)
In both the above cases, model driven development and test virtualization, IBM Rational has a strong focus on this area for both IT and embedded systems, but now focusing on the third area of testing that is important for telecom service providers as well as network equipment manufacturers, IBM has partnered with Spirent to support the concept of collaborative infrastructure testing This would be the upper part of the V-model, where you really need to test the service in the presence of the network environment which can also be virtualized with their technology.
To summarize what I’ve written here, just thinking about the available areas within a typical SDLC of a telco service, there are technologies that are relatively new, and those that have been around for a decade that this industry can utilize so that you are truly doing continuous testing in all aspects of design lifecycle, at the macro level as well as in each phase, as they all have a sense of iteration amongst them. While one can be used in isolation and provide quality and cost benefits, using all three could be a true differentiator.