Section 2.2
My Job

Upon arriving on my first day I was taken to get a badge, I met some of the people I'd be working with (QA has around 25 employees, I couldn't meet them all), and then escorted to my cubicle. Although I didn't technically have a title I would be considered a "Tool Developer" and "Tester."

My task, as presented to me by Lead Engineer, Anteneh Shiferaw, was to create various Perl scripts that would be able to monitor system metrics pertaining to the Voice Over IP (VOIP) system. It seems they were having some issues in the field and needed to figure out how and why they were occurring.

Since I didn't know Perl to begin with but had a good programming background here at JMU, I sat down with Programming Perl and began writing small scripts to acquaint myself. After a weeks worth of that I went to the test boxes (that mimic what's out in the real world) and began scripting.

While working on the scripts I had to be sure to not mess with anything on the machines that may alter performance. To learn more about what exactly I was working with and what parts of the system were being used I went over many documents pertaining to the whole project. Since the documents were available for everyone in QA and at any one time someone may be wanting to edit it, Road Runner used Microsoft's VSS, a version control system. The tool is pretty simple to use but requires a good amount of configuration by the administrator to get running properly.

After my scripts were completed I was introduced to a former JMU student who had created a software tool that was able to emulate a great number of cable modems doing certain things that were known to be causing a stress on the system. After learning about his system I put it to use in conjuntion with my metrics tools. By doing so I was able to not only locate problems in his software, but also the hardware/firmware which was being written out-of-house by Cisco Systems (also in Herndon). Although I didn't get to finish all the testing that I would have liked to, I was sure to comment my code and provide a document on how to use my tools together, my tools will be used and likely built upon in my absence. In my code I was also sure to include contact information in case someone had a question, this may prove to be very important. It should be carefully noted that all the steps I took to ensure someone can modify my work are important. If I hadn't included such things, much like trying to do a puzzle blindfolded, another programmer would likely be able to fumble his way through given enough time, but it would be infinitely easier for me to add a few lines here and there explaining what I was thinking.

During downtime (all internships have them) I aided other interns with their tasks - mainly setting up servers, routers, etc in the Engineering/Test Lab. By doing this I was able to learn a good amount of information on networking and the many types of hardware that are out there.

<2.1 My Employer | Home | 3.0 From the Job>