I was having a discussion with a colleague about security. In particular, we were discussing whether or not we should use standard HTML ports for an Internet-facing application. I thought we shouldn't use them because it would increase the risk unecessarily.
When I mentioned this, his response was, "you can't rely on security through obscurity."
I agreed. However, I still insisted that the ports should be changed. My logic was that using standard ports exposes your service to more people, which is insecurity through perpicuity and an unecessary increase in the risk of being attacked.
One example that is sometimes given as an argument against security through obscurity is that you can't just hide your front door with bushes, leave the door unlocked, and expect nobody to break in. This is true, but it doesn't mean that just because you think your house is secure, you should put a note outside that says, "Be back in a week, I put my $50,000 cash in the safe."
By exposing standard ports, you're guaranteeing that every port scanner, even those configured for a minimum scan, will find your server. You may think it's secure, but when a 0-day exploit is discovered, there is a window of opportunity from when it's disclosed to when the patch can be applied on your server where you are vulnerable. No matter how closely you track security vulnerabilities, 0-days are always a risk.
If you're using standard ports, the number of people who are aware that you're running a vulnerable service is going to be many times higher than if you were running on non-standard ports. That means your risk of being attacked before you can patch is also many times higher.
Thursday, March 10, 2011
Security in Consumer Network Products
Security is important for all software and hardware network products. However, when a security vulnerability is found in a consumer-grade product, all too often, I hear the argument that since the only attack vector is from the consumer's LAN, the priority to fix the vulnerability is low. After all, if users have intruders on their LAN, the vulnerability is the least of their worries.
Although this may be true to a certain extent, I still would argue against this. There are some reasons to investigate and address security vulnerabilities that may not be a real-world threat to consumers' data.
First, somebody could have a misconfigured wirelesss router. An attacker could get on their LAN withough their knowledge and wind up accessing their data stored on a NAS because of a bug that "nobody would realistically exploit." To be honest, this falls under the "they're on the LAN, so they have bigger problems" umbrella, but it is always an additional attack vector to consider.
Second, when the public finds out about an obvious exploitable security hole, especially one that is easily fixed, it makes the product and company look bad. People start to wonder what other problems are hidden in your product if you let out something that easy to find and fix.
Granted, not every security bug can or should be fixed, otherwise, you'd never release the product. For example, a potential Denial of Service (DoS) attack on a network device may not be a problem if that device is going to be behind a firewall. Even if an attacker gets on the LAN, are they really going to try to crash your media player?
However, regardless of the likelihood of a vulnerability being exploited, each known vulnerability should still be investigated to see how they might affect your product. I've seen cases where a DoS vulnerability was being triggered by a third-party device that was unintentionally sending malformed packets. We got reports from users that their device was crashing for no apparent reason. The logs didn't help, and we were unable to reproduce it. It was only after running a security scanner against the product that we found the vulnerability and were able to tie it to the crashes reported by users.
Of course, the stakes are raised when dealing with SMB or enterprise products. Even with consumer products, once you expose a single port to the WAN, security becomes critical, not just important.
Although this may be true to a certain extent, I still would argue against this. There are some reasons to investigate and address security vulnerabilities that may not be a real-world threat to consumers' data.
First, somebody could have a misconfigured wirelesss router. An attacker could get on their LAN withough their knowledge and wind up accessing their data stored on a NAS because of a bug that "nobody would realistically exploit." To be honest, this falls under the "they're on the LAN, so they have bigger problems" umbrella, but it is always an additional attack vector to consider.
Second, when the public finds out about an obvious exploitable security hole, especially one that is easily fixed, it makes the product and company look bad. People start to wonder what other problems are hidden in your product if you let out something that easy to find and fix.
Granted, not every security bug can or should be fixed, otherwise, you'd never release the product. For example, a potential Denial of Service (DoS) attack on a network device may not be a problem if that device is going to be behind a firewall. Even if an attacker gets on the LAN, are they really going to try to crash your media player?
However, regardless of the likelihood of a vulnerability being exploited, each known vulnerability should still be investigated to see how they might affect your product. I've seen cases where a DoS vulnerability was being triggered by a third-party device that was unintentionally sending malformed packets. We got reports from users that their device was crashing for no apparent reason. The logs didn't help, and we were unable to reproduce it. It was only after running a security scanner against the product that we found the vulnerability and were able to tie it to the crashes reported by users.
Of course, the stakes are raised when dealing with SMB or enterprise products. Even with consumer products, once you expose a single port to the WAN, security becomes critical, not just important.
Wednesday, November 24, 2010
SQA and the Scientific Method
My son has been learning about scientific method in his science class. As I've been helping him with his homework, I realized that I use scientific method when I find a bug.
For example, suppose you're testing remote access software installed on a Windows client. You're noticing that on one system, it keeps losing connection to the server. This is something I ran into once. Now, if you're a test monkey, you'll write up a bug saying, "Brokey brokey, no worky" and let development figure it out.
However, if you're reading this blog, you like making it easy for developers. So, you'll wind up asking yourself, "Why does this one system have a problem with disconnecting from the server?" At this point, you've just started approaching this from a scientific point of view.
Next, you'll do some research and elminate variables. What's unique about the one system with the problem? What could cause the connection to drop? Is it the network it's connected to? Is it a bad cable? Does it just not like me?
Once you've decided what could be causing the problem, you'll start with the first hypothesis. You'll want the simplest and easiest to test, so maybe it's the network. You'll test the hypothesis by moving the "bad" computer to the same network as the "good" computer. In fact, you could even use the same network cable that the "good" computer used. If it still fails, you've eliminated three variables (network, cable, and port on the switch). If it works, you've gotten it down to three.
If it still fails, it's back to the hypothesis and experiment loop. You'll want to keep eliminating variables until you find the cause of the problem. Maybe it's faulty hardware. Maybe it's another app. Maybe it's a feature unique to the computer.
In my case, the failing system was a laptop. After some experimentation, I traced the problem to the SpeedStep feature. If I turned that off, it worked fine. I entered the bug. When a developer got it, the root cause was found in minutes. It turned out that the API used to time the 60 second keep alive packet failed if the processor speed changed. When the app launched, the CPU usage was high, so the processor ran at full speed. Once it went idle, it slowed down, which slowed the timer down. Then, it missed the keep alive packet and the server assumed the client had disconnected and closed the pipe.
A good bug report starts with a question, then some reseach. After that, it's a cycle of coming up with a hypothesis, testing it, and repeating until you can prove a hypothesis and find the cause. Finally, you report the findings to a developer through a bug report and, hopefully, get the bug fixed.
For example, suppose you're testing remote access software installed on a Windows client. You're noticing that on one system, it keeps losing connection to the server. This is something I ran into once. Now, if you're a test monkey, you'll write up a bug saying, "Brokey brokey, no worky" and let development figure it out.
However, if you're reading this blog, you like making it easy for developers. So, you'll wind up asking yourself, "Why does this one system have a problem with disconnecting from the server?" At this point, you've just started approaching this from a scientific point of view.
Next, you'll do some research and elminate variables. What's unique about the one system with the problem? What could cause the connection to drop? Is it the network it's connected to? Is it a bad cable? Does it just not like me?
Once you've decided what could be causing the problem, you'll start with the first hypothesis. You'll want the simplest and easiest to test, so maybe it's the network. You'll test the hypothesis by moving the "bad" computer to the same network as the "good" computer. In fact, you could even use the same network cable that the "good" computer used. If it still fails, you've eliminated three variables (network, cable, and port on the switch). If it works, you've gotten it down to three.
If it still fails, it's back to the hypothesis and experiment loop. You'll want to keep eliminating variables until you find the cause of the problem. Maybe it's faulty hardware. Maybe it's another app. Maybe it's a feature unique to the computer.
In my case, the failing system was a laptop. After some experimentation, I traced the problem to the SpeedStep feature. If I turned that off, it worked fine. I entered the bug. When a developer got it, the root cause was found in minutes. It turned out that the API used to time the 60 second keep alive packet failed if the processor speed changed. When the app launched, the CPU usage was high, so the processor ran at full speed. Once it went idle, it slowed down, which slowed the timer down. Then, it missed the keep alive packet and the server assumed the client had disconnected and closed the pipe.
A good bug report starts with a question, then some reseach. After that, it's a cycle of coming up with a hypothesis, testing it, and repeating until you can prove a hypothesis and find the cause. Finally, you report the findings to a developer through a bug report and, hopefully, get the bug fixed.
Friday, May 21, 2010
Visual Studio 2010 Launch Event
Earlier this week, I went to the Microsoft Visual Studio 2010 launch event. It was informative and gave me a few ideas about how my testing is going to have to change in the upcoming months.
Microsoft seems to be pushing multi-touch screens. Testing a multi-touch screen is going to be different. At first, it's going to have to be mainly manual testing since I don't see any tools that would allow automating it. In fact, I just don't see how you can automate testing gestures. Sure, you could have some sort of simulator or even wire directly into the input stream, but a fully-automated system won't be able to account for human movement. The automated gestures would be too perfect. Touch screen interface testing is all about how it "feels," and you can't automate human perception (at least not yet).
Two more hot points are SharePoint and Windows Phone 7. SharePoint doesn't directly affect my testing, but the company I work for is moving towards it. It's going to change how I organize my test plans and testing tools as well as how I find information such as PRDs and MRDs. It's definitely much better than throwing everything in a network share, but it's going to take some getting used to.
Windows Phone 7 will likely affect my testing. I would be surprised if I don't wind up having to test some apps on that platform in the near future. It looks like it has some cool features, but we'll have to see how it does against the big boys in the mobile market. Sure, the market is expanding, but there are already some major players in there with a strong market share. Even MS will have a hard time gaining a large chunk of share, no matter how good they can make Windows Phone 7.
I did notice a couple of things during the event. Microsoft supplied lunch at the event. In with my sandwich was some fresh fruit. I thought it was kind of ironic that Microsoft chose an apple, so they wound up giving out apples at a Microsoft event.
The other thing I noticed was that just about every person giving a demo wound up lost in their own application. They couldn't find menu items. They didn't see a missing brace in the code. They didn't know where the icon to launch their demo was on the desktop. It pretty much confirms "Troy's Theory of Technical Throngs:" the amount of time it takes to find something on a computer is directly proportional to the number of people watching you.
Microsoft seems to be pushing multi-touch screens. Testing a multi-touch screen is going to be different. At first, it's going to have to be mainly manual testing since I don't see any tools that would allow automating it. In fact, I just don't see how you can automate testing gestures. Sure, you could have some sort of simulator or even wire directly into the input stream, but a fully-automated system won't be able to account for human movement. The automated gestures would be too perfect. Touch screen interface testing is all about how it "feels," and you can't automate human perception (at least not yet).
Two more hot points are SharePoint and Windows Phone 7. SharePoint doesn't directly affect my testing, but the company I work for is moving towards it. It's going to change how I organize my test plans and testing tools as well as how I find information such as PRDs and MRDs. It's definitely much better than throwing everything in a network share, but it's going to take some getting used to.
Windows Phone 7 will likely affect my testing. I would be surprised if I don't wind up having to test some apps on that platform in the near future. It looks like it has some cool features, but we'll have to see how it does against the big boys in the mobile market. Sure, the market is expanding, but there are already some major players in there with a strong market share. Even MS will have a hard time gaining a large chunk of share, no matter how good they can make Windows Phone 7.
I did notice a couple of things during the event. Microsoft supplied lunch at the event. In with my sandwich was some fresh fruit. I thought it was kind of ironic that Microsoft chose an apple, so they wound up giving out apples at a Microsoft event.
The other thing I noticed was that just about every person giving a demo wound up lost in their own application. They couldn't find menu items. They didn't see a missing brace in the code. They didn't know where the icon to launch their demo was on the desktop. It pretty much confirms "Troy's Theory of Technical Throngs:" the amount of time it takes to find something on a computer is directly proportional to the number of people watching you.
Wednesday, December 16, 2009
ISPs and Tech Support
I won't name my ISP, but this story unfortunately can apply to most of them.
Last Saturday, my Internet connection was working just fine. I went out for a few hours, came back, and went to look something up. Pages were taking a minute or two to load. I ran a speed test. It took awhile to get loaded, but once it loaded, it was fine. Speeds were good.
My first thought was DNS. So, I switched DNS servers. The problem was still there. I restarted my router. It was still there. So, I thought of latency and started doing some pings. That's when the problem became clear. Pings were low, but I was losing about 1 out of every 10 pings. I tried a few servers, including my ISP's page. They all showed packet loss. A quick test at http://pingtest.net confirmed a packet loss of 8%.
I started thinking my router might be having problems. So, I booted off a Linux live CD, cloned my MAC address to that of the router, and plugged my laptop directly into the ONT in my garage. I got an IP address and repeated the ping test. It showed 10% loss. I pinged my gateway, and it showed loss as well.
So, at this point, I figured I had done my homework. The problem was either my ONT, the ISP's gateway, or something in between. I tried resetting my ONT, but it didn't help. I decided it was time to call tech support. The problem was, I didn't have the number. Luckily, my connection was still somewhat working, and I managed to find it, after about 30 minutes of waiting for pages to load.
As soon as the support agent answered, I had a feeling I was doomed. It was Saturday night, and the call was obviously outsourced. Still, I had some faith in the system. The call went something like this:
Agent: How can I help you?
Me: I'm experiencing 10% packet loss between the ONT and the gateway. This is causing web pages to take several minutes to load, if they even load at all. I've already ruled out my router by connecting my laptop directly up to the ONT. I reset the ONT, but it didn't help. I'm going to need somebody to come out here and fix it.
Agent: I'm sorry you are having problems. I have a few things you can try.
At this point, I know I'm going to have to play along for a few minutes. After all, he doesn't know that I actually know what I'm talking about.
Agent: Could you try rebooting your router. Go to the router, disconnect power for 30 seconds, then reconnect it.
I know this won't work, but I play along anyway. "Ok. I'm doing that." My router was upstairs, and I was downstairs, so I figured about 90 seconds was enough time to have waited to tell him it was done "rebooting."
Agent: Can you try going to [link for the ISP's speed test]?
Me: Sure.
I waited for the page to load. While I'm waiting, I ran a few pings. Packet loss is up to 30%.
Me: It's still a not loading. It's a blank page. This isn't a speed problem, though. I'm seeing packet loss, and it's getting worse.
Agent: How long has it been like this?
Me: It was fine this afternoon. Three hours later, I saw some problems with 10% loss. I called you, and in the last 15 minutes, it went up to 30%.
Agent: Okay. Let me check with a network technician.
After 5 minutes on hold:
Agent: He wants you to connect your router back to the ONT, not your laptop.
Me: I already did that.
Agent: Okay. Try resetting your router. Power it off, hold down the reset button, and bring it back up.
I have plenty of port forwarding rules, firewall rules, custom DNS entries, and static DHCP entries. I'm not about to wipe all those out for something that's not even the router's problem. So:
Me: Okay, but I need to back up my settings first.
Agent: Oh, that would be a good idea.
Again, I figured a couple of minutes is enough time to have "reset" the router.
Me: Okay, it's reset. I'm trying the speed test page, and it's not loading at all now.
Agent: Let me check with the technician.
While on hold, I connected the laptop back up to see how much worse it had gotten. I didn't get an IP address. I rebooted my router. It couldn't get an IP address. I've reach 100% packet loss.
Agent: He's going to reprogram your ONT.
This sounded promising. I was wrong, but I did get my hopes up for a little bit.
Me: Okay. By the way, it's gotten worse. My router won't even get an IP address now. I'm seeing 100% loss and have a completely dead connection.
Agent: Okay. Please hold.
15 minutes later, he came back.
Agent: Okay. He wants you to reset the ONT. Unplug the power to the ONT for 1 minute.
Me: Sure. By the way, can you just connect me to the network technician so I don't have to keep waiting on hold.
Agent: Sorry, we don't have a way to do that.
Me (rolling my eyes at this point and getting frustrated): I'm resetting it. Do I have to disconnect the battery?
I knew the answer, but just had to ask.
Agent: No. Just the AC
BUZZ! Sorry, wrong answer. Unplugging the AC from a device with a battery backup inside it isn't going to do much.
Me: I unplugged it. The lights are still on.
Agent: One second.
On hold again.
Agent: Okay. Sorry. Unplug the battery too.
Me: Okay.
I unplugged the battery, and the ONT went dead. I waited 60 seconds, and plugged everything back in.
Me: Okay. It's coming up. The fail light is flashing, just like it should while it tries to connect....okay....it's still flashing. It should've connected by now...still nothing.
Agent: Okay. Please hold.
......
Agent: Hmm...can you try going to the speed test site?
Me: The ONT's not connecting. I won't be able to.
Agent: Can you try restarting the router?
Me: The ONT's not connecting. The router has nothing to do with it. My router's not even getting a link now. My connection is dead.
Agent: Please wait....
About 15 minutes later
Agent: The technician can't even reach your ONT. We're going to have to send somebody out.
FINALLY!
Me: Thank you.
Agent: Unfortunately, our ticketing system is down, so I can't create the ticket. Somebody will call you.
Me: When will that be?
Agent: I don't know. Our system is down.
Me: Well, it's Saturday night. If your system comes back up as soon as you hang up, will somebody be calling me tonight, or will it have to wait until Monday at the earliest?
Agent: Our system is down.
Me: Yes, I know, but will I get a call, say, tomorrow, if the system comes back up, or do you only call back during regular business hours?
Agent: During regular business hours.
Me: Okay. Thank you.
Agent: Is there anything else I can do for you?
I look at my phone. It's been an hour and 43 minutes since I called.
Me: No. It's been almost two hours as it is, so I don't think there's much else you can do.
Agent: Thank your for choosing [ISP]
So, at that point, after spending over 1 1/2 hours on the phone, it looked like my connection was going to be down awhile. They were going to send somebody out, which was what I asked for 2 minutes into the call.
Sunday morning, I turned on my cell phone. I had a voice mail from the ISP. They were sending somebody out at 2:00 and I needed to call back if that wouldn't work. Had I known they might call, I would have left the phone on. But, at least it was going to get fixed.
I went to the store. At 1:30, I got a call from the dispatcher saying that the technician was on his way. I started heading home. At 1:35, I got a call from the technician saying he was at my house. I told him I was 5 minutes away.
I rushed home, let him into the garage, and explained what I had been seeing. At this point, the ONT was dead. The first thing he did was replace it. It took him five minutes. I came back out in the garage and saw him staring at the ONT. The fail light was flashing. Apparently, the ONT wasn't the problem.
He stood there for a good five minutes, just staring at the pretty blinking light. Then, he started to talk to somebody on his phone. After he hung up, he said he was going to try re-authorizing the ONT and went back to his truck. He came back and said his connection from the truck was down and would have to call it in for somebody to do manually.
Irony.
A few minutes later, he rang the bell. He said the problem wasn't the ONT or in the box in the front yard. It was possibly in the hub, so he was leaving, but wanted me to know he was still working on it.
He finally came back and said it was fixed. It took an hour, but in this case, it was understandable. It was a problem in the central office. Normally, a CO problem would impact dozens of people, and they'd know the problem was there because of the high volume of calls. In this case, it was only me, so it didn't look like a CO problem. I guess I was just lucky.
Last Saturday, my Internet connection was working just fine. I went out for a few hours, came back, and went to look something up. Pages were taking a minute or two to load. I ran a speed test. It took awhile to get loaded, but once it loaded, it was fine. Speeds were good.
My first thought was DNS. So, I switched DNS servers. The problem was still there. I restarted my router. It was still there. So, I thought of latency and started doing some pings. That's when the problem became clear. Pings were low, but I was losing about 1 out of every 10 pings. I tried a few servers, including my ISP's page. They all showed packet loss. A quick test at http://pingtest.net confirmed a packet loss of 8%.
I started thinking my router might be having problems. So, I booted off a Linux live CD, cloned my MAC address to that of the router, and plugged my laptop directly into the ONT in my garage. I got an IP address and repeated the ping test. It showed 10% loss. I pinged my gateway, and it showed loss as well.
So, at this point, I figured I had done my homework. The problem was either my ONT, the ISP's gateway, or something in between. I tried resetting my ONT, but it didn't help. I decided it was time to call tech support. The problem was, I didn't have the number. Luckily, my connection was still somewhat working, and I managed to find it, after about 30 minutes of waiting for pages to load.
As soon as the support agent answered, I had a feeling I was doomed. It was Saturday night, and the call was obviously outsourced. Still, I had some faith in the system. The call went something like this:
Agent: How can I help you?
Me: I'm experiencing 10% packet loss between the ONT and the gateway. This is causing web pages to take several minutes to load, if they even load at all. I've already ruled out my router by connecting my laptop directly up to the ONT. I reset the ONT, but it didn't help. I'm going to need somebody to come out here and fix it.
Agent: I'm sorry you are having problems. I have a few things you can try.
At this point, I know I'm going to have to play along for a few minutes. After all, he doesn't know that I actually know what I'm talking about.
Agent: Could you try rebooting your router. Go to the router, disconnect power for 30 seconds, then reconnect it.
I know this won't work, but I play along anyway. "Ok. I'm doing that." My router was upstairs, and I was downstairs, so I figured about 90 seconds was enough time to have waited to tell him it was done "rebooting."
Agent: Can you try going to [link for the ISP's speed test]?
Me: Sure.
I waited for the page to load. While I'm waiting, I ran a few pings. Packet loss is up to 30%.
Me: It's still a not loading. It's a blank page. This isn't a speed problem, though. I'm seeing packet loss, and it's getting worse.
Agent: How long has it been like this?
Me: It was fine this afternoon. Three hours later, I saw some problems with 10% loss. I called you, and in the last 15 minutes, it went up to 30%.
Agent: Okay. Let me check with a network technician.
After 5 minutes on hold:
Agent: He wants you to connect your router back to the ONT, not your laptop.
Me: I already did that.
Agent: Okay. Try resetting your router. Power it off, hold down the reset button, and bring it back up.
I have plenty of port forwarding rules, firewall rules, custom DNS entries, and static DHCP entries. I'm not about to wipe all those out for something that's not even the router's problem. So:
Me: Okay, but I need to back up my settings first.
Agent: Oh, that would be a good idea.
Again, I figured a couple of minutes is enough time to have "reset" the router.
Me: Okay, it's reset. I'm trying the speed test page, and it's not loading at all now.
Agent: Let me check with the technician.
While on hold, I connected the laptop back up to see how much worse it had gotten. I didn't get an IP address. I rebooted my router. It couldn't get an IP address. I've reach 100% packet loss.
Agent: He's going to reprogram your ONT.
This sounded promising. I was wrong, but I did get my hopes up for a little bit.
Me: Okay. By the way, it's gotten worse. My router won't even get an IP address now. I'm seeing 100% loss and have a completely dead connection.
Agent: Okay. Please hold.
15 minutes later, he came back.
Agent: Okay. He wants you to reset the ONT. Unplug the power to the ONT for 1 minute.
Me: Sure. By the way, can you just connect me to the network technician so I don't have to keep waiting on hold.
Agent: Sorry, we don't have a way to do that.
Me (rolling my eyes at this point and getting frustrated): I'm resetting it. Do I have to disconnect the battery?
I knew the answer, but just had to ask.
Agent: No. Just the AC
BUZZ! Sorry, wrong answer. Unplugging the AC from a device with a battery backup inside it isn't going to do much.
Me: I unplugged it. The lights are still on.
Agent: One second.
On hold again.
Agent: Okay. Sorry. Unplug the battery too.
Me: Okay.
I unplugged the battery, and the ONT went dead. I waited 60 seconds, and plugged everything back in.
Me: Okay. It's coming up. The fail light is flashing, just like it should while it tries to connect....okay....it's still flashing. It should've connected by now...still nothing.
Agent: Okay. Please hold.
......
Agent: Hmm...can you try going to the speed test site?
Me: The ONT's not connecting. I won't be able to.
Agent: Can you try restarting the router?
Me: The ONT's not connecting. The router has nothing to do with it. My router's not even getting a link now. My connection is dead.
Agent: Please wait....
About 15 minutes later
Agent: The technician can't even reach your ONT. We're going to have to send somebody out.
FINALLY!
Me: Thank you.
Agent: Unfortunately, our ticketing system is down, so I can't create the ticket. Somebody will call you.
Me: When will that be?
Agent: I don't know. Our system is down.
Me: Well, it's Saturday night. If your system comes back up as soon as you hang up, will somebody be calling me tonight, or will it have to wait until Monday at the earliest?
Agent: Our system is down.
Me: Yes, I know, but will I get a call, say, tomorrow, if the system comes back up, or do you only call back during regular business hours?
Agent: During regular business hours.
Me: Okay. Thank you.
Agent: Is there anything else I can do for you?
I look at my phone. It's been an hour and 43 minutes since I called.
Me: No. It's been almost two hours as it is, so I don't think there's much else you can do.
Agent: Thank your for choosing [ISP]
So, at that point, after spending over 1 1/2 hours on the phone, it looked like my connection was going to be down awhile. They were going to send somebody out, which was what I asked for 2 minutes into the call.
Sunday morning, I turned on my cell phone. I had a voice mail from the ISP. They were sending somebody out at 2:00 and I needed to call back if that wouldn't work. Had I known they might call, I would have left the phone on. But, at least it was going to get fixed.
I went to the store. At 1:30, I got a call from the dispatcher saying that the technician was on his way. I started heading home. At 1:35, I got a call from the technician saying he was at my house. I told him I was 5 minutes away.
I rushed home, let him into the garage, and explained what I had been seeing. At this point, the ONT was dead. The first thing he did was replace it. It took him five minutes. I came back out in the garage and saw him staring at the ONT. The fail light was flashing. Apparently, the ONT wasn't the problem.
He stood there for a good five minutes, just staring at the pretty blinking light. Then, he started to talk to somebody on his phone. After he hung up, he said he was going to try re-authorizing the ONT and went back to his truck. He came back and said his connection from the truck was down and would have to call it in for somebody to do manually.
Irony.
A few minutes later, he rang the bell. He said the problem wasn't the ONT or in the box in the front yard. It was possibly in the hub, so he was leaving, but wanted me to know he was still working on it.
He finally came back and said it was fixed. It took an hour, but in this case, it was understandable. It was a problem in the central office. Normally, a CO problem would impact dozens of people, and they'd know the problem was there because of the high volume of calls. In this case, it was only me, so it didn't look like a CO problem. I guess I was just lucky.
Wednesday, April 22, 2009
Data-Driven Testing
A few years ago, I undertook a project to make automating printer drivers easier for QA. The idea was to use INI files to define the tests so that people who don't know how to develop can automate new tests. I wound up using a set of INI files to define applications, driver UIs, and test cases.
I didn't realize it at the time, but I was essentially making a data-driven test. Test cases were added simply by editing a simple file. It even went beyond the traditional data-driven test setup by supporting black box monkey testing, default values for most functions (such as falling back to CTRL + O to bring up the open dialog in an application), and remote monitoring and control of the test through the network.
Data-driven testing makes life easier for QA as well as the automation developer. Instead of having to add lines of code, anybody could just edit a file to add test cases. It's much more complicated to create data-driven automation, and it isn't appropriate for every test plan, but when it does work, it works well.
I didn't realize it at the time, but I was essentially making a data-driven test. Test cases were added simply by editing a simple file. It even went beyond the traditional data-driven test setup by supporting black box monkey testing, default values for most functions (such as falling back to CTRL + O to bring up the open dialog in an application), and remote monitoring and control of the test through the network.
Data-driven testing makes life easier for QA as well as the automation developer. Instead of having to add lines of code, anybody could just edit a file to add test cases. It's much more complicated to create data-driven automation, and it isn't appropriate for every test plan, but when it does work, it works well.
Thursday, April 16, 2009
Yet another "thank you" email
It's bad enough to get an email saying the interview didn't work out. It's worse when it's a form letter. I interviewed at a company in San Diego. I went through two phone interviews before being asked to come in, using up plenty of my mobile phone minutes. I drove an hour to the office, went through a 3 hour interview with 5 different people, was told they'd get back to me within a few days, sat in traffic on the way home for 90 minutes, sent some personal thank you emails, and waited.
A week later (this Monday), I got an email from the person in HR I had been talking to. She said that the team had finished the interviews and would be in touch no later than Friday with a decision. I was a little ticked because she sent it to all the candidates, but put our email addresses in the To field instead of using BCC, so everybody was able to see everybody else's email addresses and names. So much for privacy.
Since I had the email addresses of each of the other candidates, I could have done searches and got background information on each of them, then used this information to my advantage in a follow-up email. I didn't (though I wonder if any of the other candidates did). To make matters worse, it was HR that sent the email, and HR should have known better than to disclose the names and email addresses of all the candidates.
Anyway, today, 10 days after the interview, I got the following email:
However, if somebody invests their time, gas, and energy into showing up in person for an interview, then that person follows-up with a personal thank you after the interview, the least you could do is sign the rejection email with your own name instead of "HR/Recruitment Team."
Maybe it's better I didn't get the job. I'd hate to show up to work one day and find an email from "HR/Recruitment Team" telling me I've been laid off. I can just see it now:
A week later (this Monday), I got an email from the person in HR I had been talking to. She said that the team had finished the interviews and would be in touch no later than Friday with a decision. I was a little ticked because she sent it to all the candidates, but put our email addresses in the To field instead of using BCC, so everybody was able to see everybody else's email addresses and names. So much for privacy.
Since I had the email addresses of each of the other candidates, I could have done searches and got background information on each of them, then used this information to my advantage in a follow-up email. I didn't (though I wonder if any of the other candidates did). To make matters worse, it was HR that sent the email, and HR should have known better than to disclose the names and email addresses of all the candidates.
Anyway, today, 10 days after the interview, I got the following email:
Is it too much to ask for a personal email signed by a person? There were only four of us (which is information I shouldn't have known). It would have only taken a few minutes to send each of us an email. Even an email that was sent to all of us would've been better than just logging into Taleo and clicking a button to send a form rejection letter to all candidates. Form responses are great when you haven't even gotten a phone call about your application. In fact, I'm glad when I get those, since at least I know they got my application.
Subject: Thank you for your interest in [Name of company I applied to]
Dear Troy Hoffman,
Thank you for submitting your resume tofor consideration.
We are fortunate to have many qualified candidates apply to each of our positions. We have reviewed the qualifications of each candidate and after careful consideration, we have determined that the credentials of other candidates may better fit our needs at this time.
Please accept our best wishes and thank your for your interest in our company.
Sincerely,
The [Name of the parent company] HR/Recruitment Team
-------------------------------
Powered by Taleo
www.taleo.com
However, if somebody invests their time, gas, and energy into showing up in person for an interview, then that person follows-up with a personal thank you after the interview, the least you could do is sign the rejection email with your own name instead of "HR/Recruitment Team."
Maybe it's better I didn't get the job. I'd hate to show up to work one day and find an email from "HR/Recruitment Team" telling me I've been laid off. I can just see it now:
Subject: Thank you for your service at [Company Name]
Dear Troy Hoffman,
As you are aware, many companies have been forced to cut expenses due to the current economic situation. At [company name], we have been fortunate to have avoided workforce reduction.
However, due to a slowdown in sales, we have been faced with the difficult decision of how to reduce expenses. Regrettably, we have been forced to reduce our working staff. This decision was not made lightly and in no way reflects on the performance of those who will no longer be with us.
Since you have received this email, you have been one of those whose position has been eliminated. Please pack up your personal belongings and wait for security to escort you out of the building. Your final paycheck will be mailed to you. Regrettably, there will be no severance package.Please accept our best wishes and thank your for your many years of dedicated service to our company. We sincerely hope you are able to support your family. Security at [Company Name] will, of course, be increased in the months ahead, so please do not visit without an appointment and approval.
Sincerely,
The [Name of the parent company] HR/Recruitment Team
-------------------------------
Powered by Taleo
www.taleo.com
Subscribe to:
Posts (Atom)
Posts
