Some current trends in network product DevTest practices
December 01, 2014
Video
I have had the pleasure in the last year-and-a-half of gaining a lot of exposure to how network technology vendors, telecom operators, systems integrators, and IT networking teams are performing their devtest processes. There are a few key trends that I see occurring pretty clearly:
1. Turning Labs into Clouds. Well, to be honest, most devtest teams don’t really say it this way, as engineers aren’t prone to use trendy buzzwords so much. However, this is, in fact, what is happening in a lot of cases – there is a definite trend of investment to turn manually operated devtest labs into infrastructure as a service (IaaS) clouds that offer self-service catalogs and zero-touch operations. After all, it doesn’t take a lot of thought or analysis to realize that manual lab operations are tremendously wasteful. If you’re trying to develop and test functionality over a network topology scenario, the manual way of setting up that topology is scary. We’re talking walking around a lab or data center, pulling up tiles, yanking cables, and inadvertent test breaks because you remove the wrong cable from a patch panel or switch. Then you start typing and downloading images and configuring devices and software. This process can take days. There are multiple reasons why test labs are moving away from manual processes:
a) They’re sloooooooow. ‘Nuff said.
b) They cost a lot in under-utilized capital, power, and cooling. On average, manually operated labs only utilize the infrastructure at about 20 percent. This kind of thing makes CFO’s blanch.
c) The pain of the process causes engineers to hoard equipment, making it harder to even access the right gear for your environment. Revisit points a and b, rinse, and repeat to infinity.
For an example, check out a nice brag video made by Hitachi Data Systems’ technical operations team.
2. A Renewed Zest for Test Automation – Test automation is one of those projects that can be awesome or a total nightmare, depending on approach. When started on an ad-hoc basis with easy promises and without a disciplined methodology and sound platform or framework, it can quickly devolve into a mountain of smoldering scripts. However, with a sound methodology such as a building-block approach and GUI tools that work for non-programmers (because let’s face it, most network engineers are not professional software programmers) you can build a test automation practice that really scales. It typically takes at least one or two zen master programmer types to anchor this type of success. One great example I know of, though I can’t call them out by name without permission, is a major cable operator that was able to deeply automate its video quality of experience (QoE) testing and achieve amazing improvements in test coverage and cycle time compared to the manual testing method it used to use – with untrained, non-technical contractors literally sitting in recliners clicking on physical remotes.
3. Continuous Integration – This is more challenging, perhaps more aspirational, but it’s still something that ambitious networking organizations are actually accomplishing. An example is a mobile backhaul network manufacturer that has achieved a 24-hour continuous integration cycle over complex network topologies consisting of embedded systems products. Quite a feat. This requires a close coordination between infrastructure, continuous integration (CI) server, and test automation processes, but is clearly doable.
So, those are a few trends I’m seeing. Where is your organization at with achieving higher productivity, faster workflows, and greater resource efficiencies? How are you going about it? I’d love to hear your comments and feedback.