News Stay informed about the latest enterprise technology news and product updates.

Tech Data wants you to step outside

Chances are at least SOME portion of your business comes from wireless networking at this point, but I’d bet most of it is of the indoor variety. Well, Tech Data is throwing down the gauntlet to some of the specialized wireless distributors through its new relationship with BIG Wireless, which sells various outdoor wireless technology and services.

The deal, which points back to Tech Data’s Wireless Specialized Business Unit, will let Tech Data VARs “purchase, brand and resell” BIG Wireless’s services. The company’s specialty is outdoor wireless for municipalities, corporate campuses or universities. These include wireless site surveys, point-to-point path studies, voice/video over wireless, GPS location, Federal Communications Commission licensing compliance and so on. Many of the more obscure requirements for outdoor wireless that a traditional solution provider might not have been able to invest in. If the reseller chooses, they can brand BIG Wireless’ services as their own.

How much business is in outdoor wireless? My gut is that it’s going to be sort of like Wi-Fi adoption: It will creep up in adoption for the right reason, it helps people do their jobs better. There will be some debates over format of course (ala the WiMax specification I wrote about in January), which is all the more reason why you might choose to team up with a company like BIG rather than investing in your technical skills right now.

Heather Clancy is a widely published business journalist and strategic channel communications consultant with SWOT Management Group. You can reach her at hclancy@swotmg.com.

Join the conversation

20 comments

Send me notifications when other members comment.

Please create a username to comment.

What has been your greatest challenge in automating software testing?
Cancel
The complications involved in automation will uncover only once it is started , we may face issues in handling many of the control types in the application.
Cancel
Estimation is already a big challenge and then complexity of coding adds more challenge into keep estimation intact.
Cancel
given little resources to do it though everyone seems to want it!
Cancel
Selecting the best tool for automation test
Cancel
Not when to automate but how to automate. Designing an automation solution that will fit with source control and our work flow.
Cancel
Managers are too “stupid” to realise its benefits. Changing the status quo is like the world coming to an end for them
Cancel
The greatest challenge for me recently has been dealing with latency and "flaky tests". It's frustrating when a test run fails as a whole suite, but passes when the failures are un individually. Hunting for the dependency or state condition that may be causing the issue can be a waste of time, simply because running the same order of tests a second time results in a pass. Running tests in parallel helps, but even then there's enough variation to drive one to distraction. 
Cancel
The greatest challenge for Automation are two things: 

1. Moving Target Syndrome
2. Poor planning on Dev team to provide hooks to easily setup for Automated Tests

For 1: many automation projects necessarily lag behind development, and require constant maintenance and upgrading.  Michael alluded to the problem of flaky tests.  Flaky tests are part of the equation, but there are always gaps in a programs development that automation sometimes has to work around. 

For 2: Over reliance on UI for set up and tear down of tests makes testing not just slower, but also, less reliable.  I've seen better success on teams where APIs are available for setting up data (and I think that's preferable to tests that write directly to the database, but sometimes you don't have a choice)
Cancel
Selecting the right automation tool depending on the requirements.
Requirement to automate the database testing for processes like schema verification, verifying structural changes, data updation, etc.

But now I can say that these challenge is no more a big challenge.
Cancel

The expectations made up by people that only read about the benefits of test automation but do not know anything about test and test automation in general.

Cancel
It's hard to decide when start and automate tests scripts
Cancel
coding scripts is not easy.
Cancel
Coding Scripts so it entails QA's skills
Cancel
Interesting
Cancel
Well put problems of QA teams
Cancel
I like to add another Guiding principle: Make the reuse of your test automation artifacts an important aspect of your consideration, share your creation with yourself (in futre use) and with others.
Cancel
Testing business scenarios/Agile stories/use cases is probably the most challenging. Even with Agile, QA still doesn't get a real sense for how customers use the software we test. When you add the dimension of dynamic data changes in multiple required systems in your test environment, automation becomes quite arduous.
Cancel
I think guiding principal number 7 should be "treat your test automation work with the same level of value and care that you do your course code development. If the same level of care, revision control and code review goes into automation as goes into source code creation, then there isa very good chance that test automation will be successful (much more so than if this approach is not used).
Cancel
Number five in this list is possibly the most important one. Automation can be an effective measure for working on regressions and discovering if a commit has broken something, or if a fundamental change has been introduced that requires rework of other scripts, but it cannot test for things it doesn't already know about. That's where humans have to continually inform and help update the suite with new findings and new information.
Cancel

-ADS BY GOOGLE

MicroscopeUK

SearchSecurity

SearchStorage

SearchNetworking

SearchCloudComputing

SearchDataManagement

SearchBusinessAnalytics

Close