Welcome to the XCellAir Blog! A few promises:

  1. Self-promotion will be kept to a minimum and if the occasional blurb on some achievement is jotted down, it’ll be accompanied by a market or technology-related piece or two.
  2. We’ll be posting regularly…otherwise, what’s the point?!
  3. Periodically, the blog will have nothing to do with industry stuff. Our team is comprised of interesting individuals and we’d like to let you see behind the curtain.

Enjoy the reads, join in on the conversation and come back often!

Guerrilla Engineering Part 1

Posted by Todd Mersch on 26 April 2017

Much of our blog space is taken up with commentary on market trends or new technology, which is good, but it certainly is not the whole XCellAir™ story. That’s why I’ve decided to start a little series of blogs sharing some stories from the trenches titled, Guerrilla Engineering.

One of the best and most refreshing aspects of a start-up is the freedom team members feel when in a small organization. Everyone is empowered to take actions they see that can benefit the company. It’s not that anything I’ll share in these short blogs is impossible to do in a larger organization – it’s more that the culture and processes often dissuade these behaviors.

For our first installment, I’m sharing the genesis of our automated regression testing tool. For any engineering organization regression testing is critical to ensure new features do not break existing capabilities and automating this process is increasingly the best practice. For XCellAir, the challenge is a bit unique. We need to be able to simulate the dynamic behavior of dense Wi-Fi networks at scale.

Like many of the best engineering achievements, regression testing was not the original intent behind what ultimately became our tool. We were getting ready to go into a field trial with a network operator and one of the Engineering team members was concerned. It would be our first field trial and the system’s initial exposure to the unpredictability of Wi-Fi in the real-world. Instead of just being worried he decided to do something about it. But what?

He asked himself a few questions:

  1. What’s the best way to test against a real-world environment if you cannot deploy in that environment yourself?

Gather the data from that environment and figure out a way to pump that into the system.

  1. Where is the best place to get that data?

From the location or one very like the location you plan to field trial.

Turns out that the field trial location was within a reasonable driving distance from our offices so he grabbed a couple Wi-Fi routers, spun up an instance of the XCellRAN™ server on a laptop, and drove over to that location. To be able to automatically optimize performance the first thing our software does is gather detailed data about the radio environment – so why not do your own little recon mission? That is exactly what he did. Over a few days he gathered a ton of detailed data about the target field trial location.

Armed with that data he then created a tool that would play this data back into the system while randomizing the behavior within boundaries that aligned with the overall data set. This allowed us to harden the system prior to that field trial. Eventually, it became clear this tool could be tied into our overall develop ops / continuous integration strategy – and hence the birth of the automated regression tool.

Having this capability is invaluable to a small engineering team delivering releases to customers at a rapid pace. It ensures we are able to do so without any regression and continued high-quality, a feat teams ten times the size of ours struggle to accomplish. It all comes down to an Engineer being worried, taking the initiative to do something about it and answering a few questions when local law enforcement is wondering why you have Wi-Fi routers on the roof of your car.

This is just the first of a few stories we will share. Any stories you want to tell? Feel free to add them to the comments below!

Leave a Reply

Your email address will not be published. Required fields are marked *