Need tips for testing DSL connectivity
Does anyone one have, or know of somewhere, that I might find test case templates on testing DSL/broadband connectivity? I am testing front and back office systems, so anything would help on getting me started.
Re: Need tips for testing DSL connectivity
Well, you do not mention the type of DSL - ADSL, RADSL, G.Lite, HDSL, SDSL, IDSL, etc. So just bear in mind there are some differences of what you could do or look for in various contexts. And, of course, that variety of contexts makes it difficult to answer this with any specificity particularly since you do not limit the scope of your query. For example, providing DSL means testing the devices and drivers that make it work along with everything else. Simply working with DSL might mean just testing peformance. Working with DSL in the context of your organization might entail more security testing. So knowing what you are testing in terms of DSL would be helpful.
In general, and most obviously, you should test the basic connectivity, such as the throughput. Your DSL provider should have Service Level Agreeements (SLA's) for inbound and outbound traffic so you can check for that. As an example, assume a low-end DSL of 256 kilo-bits per second. This connection is thus 256,000 bits per second. You can easily check for that. Note that I said kilobits per second - not kilobytes. You should test for kilobits and then refer to kilobytes. So this means that you have to consider: 256,000 bits = 32,000 bytes = 31.25 kilobytes. (Also remember that it is hard to send pure information over a DSL line. The transmitted data is "packaged up" in shells to ensure the integrity of the information, as well the additional protocols necessary to route the data over ethernet, ATM, or whatever. So this means about eight percent of your bandwidth is taken up by routing overhead - something to consider.)
Getting into more technical venues, if you are doing full-route testing, you might consider loop testing (for performance of the local loop). You can use narrow and wide-band testing processes to work with loop testing, such as determining the frequencies the loop can tolerate (a sort of boundary test). You can also use this to measure data throughput and latency. So, really, you are still dealing with performance.
You can also consider testing for security, such as routers and firewalls that the DSL will have to account for. But since we have no knowledge of your setup, I trust just mentioning security will give you a lot of ideas. You can also look at routers in terms of line packet loss testing.
If you are talking more from a provider perspective, then the first thing is to test remote customer loops from a central command center or network operations center. This is usually called single-ended testing and it will help you look at the loops for the service and look for any "disturbers" in bound groups. If you are talking about actual installation, you are going to want to look at the DSL access multiplexer (DSLAM) as well as looking at putting a test access switch in place between the main distribution frame (MDF) in whatever your central office is and the DSLAM equipment.
I figure that is not your scope of testing but I bring it up simply to show that more clarification is always better than less. As a general user of DSL, the testing is pretty much obvious: performance (throughput and latency being your biggest killers). You are also going to want to look at the security aspects of having a DSL in place. It sounds like you are not installing or providing DSL, so I would concentrate on those. However, answering that in more detail (such as how to test for throughput or latency) might be a better question for the Performance Testing forum.
Re: Need tips for testing DSL connectivity
We do DSL testing in-house for our peer to peer application. Essentially, our product is a p2p network serving up video and audio content, so is thus pretty much targeted at broadband users. Quickly into our development though, we realized that we were only testing in-house over our internal networks, and nothing was being tested over "real life" lines.
We decided to install two DSL modems, both of which were, of coarse, completely outside our company firewall. This made testing complicated because we have to open up internal test environments to the outside. A couple of safeguards we put in place were only opening up specific ports that were to be used, and only opening them up to the IP of the DSL machine. Security must be maintained.
Jeff may have explained it, but when testing over different connection speeds (DSL, modem, LAN, etc...) the major thing to look for are timing issues. What may run great at a 400k/s LAN connection will fail at a 56kbps modem connection because of timing issues like data not being served up fast enough (thus the app may close connection or some such behavior). Through connection testing like this, we have found several bugs that would not have been found testing only over fast internal lines.