|
|
||
|
|
||
|
About myself - professionallyIntroductionHi. I'm a computer professional who specializes in white-box software testing, system software design and integration, and Quality Assurance (QA) for Unix and Linux-based computer systems. I have over 10 years of experience with a variety of different Unix platforms. Prior to that, I designed and sustained computer peripheral hardware and embedded systems. Below is a chronological summary of my professional work history. A resume with the essentials is located here.Digital Hardware DesignerMy first job was as an electronics engineer designing interface boards using Fast® TTL logic components. Although I found that work interesting and challenging, I did not enjoy the tedium of making changes in my designs, especially after their implentation in wire-wrap or printed circuit boards. I also found that I preferred looking at the hardware design from the real-time system level, and did not enjoy the minutia of tracing single-bit circuit paths through pages and pages of schematic diagrams. In those days, the hardware solutions I designed were necessary because the microprocessors of that era were not fast enough to provide real-time solutions.The technology of digital hardware was changing fast, and PAL (Programmable Logic Array) technology quickly became a design staple in the field. Printed circuit board designs in those days usually included several PAL chips and adept designers made sure that most changes could be programmed into the PALs instead of using wires and solder. PALs made way for FPGAs and larger programmable VLSI designs until the complexity made it necessary that all new digital hardware designs were programmed using specialized languages such as VHDL, and simulated using tools such as those from Synopsys. Digital Hardware Sustaining support/System-level testBy that time, I was happily doing hardware sustaining support and low-level system testing for new products. I was not learning how to use the new hardware design tools. It did not escape my attention that, as the effect of Moore's Law became more apparent, computer hardware design was becoming a matter of integrating off-the-shelf components and designing software to instruct a microprocessor to perform tasks previously done by discrete hardware logic designs. There were two career paths available for someone with my experience: design the off-the-shelf components and chips, or design the software that integrates those components. Since I already knew I preferred looking at digital hardware from a system level, and did not enjoy the tedium of hardware design, I chose to follow a career path into software.By that time, I was in awe of the flexibility and power of the design underlying the Unix operating system and wanted to continue working in that environment. Even the simplest Unix implentations had dozens of powerful tools for manipulating text-based data, and it was already apparent that Unix could be adapted to run on any microprocessor-based computer. I was a relative late-comer to the Unix world. My first real experience was with a Tahoe running BSD 4.3, and later, AT&T System V, Revision 4 (SVR4) - a creation of the Unix International consortium (now defunct) in the early 1990's to try and add BSD-specific features to AT&T versions of Unix. I bought my first PC - an Intel 486/33 PC - when I learned I could install Linux (version 0.99pl4) at home. For a while, I looked for Unix system administration jobs because I wanted to preach the "gospel" of Unix to the "uninitiated heathens" ignorant of its power and flexibility. Fortunately for me, my next job was as a system test and QA lead and not as a Unix administrator. My religious attitude toward Unix would have certainly been too heavy-handed, and I gradually learned that most computer users preferred using a point-and-click interface. They also preferred that text processing be performed for them transparently, and not as a result of an arcane typed-in command. I am still a Unix nut, but over the years, I have become very familiar with many of the limitations of Unix implementations. I primarily run Red Hat Linux at home, even though I prefer the more BSD-like Slackware Linux. With Red Hat, I am still fascinated with the design compromises they made in the interest of ease of use for the folks not so familiar with Unix. (Yes, I know. Linux isn't Unix, and Linux is really "GNU/Linux". Email to me arguing these points will be ignored.) System software test and integrationFor the next six years, I was the principal tester for a large Sun-based software project that interfaced with high-speed Xerox printer hardware. My system-level perspective and my focus on Unix scripting languages made me an invaluable member of the software development team. I wrote scripts for automated testing and debugging. As a software test / QA / integrator:
Software development & sustainingHowever after six years of testing the same product, I had become very bored and wanted to try developing new features myself. Since my managers thought I was too valuable to the product I had tested for so long, my only choices were to leave the company or transfer from testing to the product development team. I chose the latter mostly because I liked my fellow development engineers and wanted to continue working with them. As a software developer, I:
As my former development team members moved on to other roles (voluntarily & involuntarily), I became increasingly aware of the limitations being placed on my ability to move on to other roles at Xerox. As a result, I started searching for new opportunities and landed a position as a senior software system test engineer at DIRECTV. Software System TestingAt DIRECTV, software engineering has two branches: one is the software on the servers in the broadcast center and the other is the software that goes into set-top boxes. The server software in the broadcast center is well documented and testing it involves the writing of formal test plans based on the specifications and interface documents. For set-top box testing, testing has involved creation and use of "bitstreams" to exercise the set-top box by simulating small portions of the broadcast stream. It also involves an ad-hoc approach by exercising various features via the user interface. We're still working on ideas for automating the set-top box testing process. This is made more difficult due to the lack of test automation tools compatible with the set-top box UI's environment.
Currently, I'm pretty happy with my position at DIRECTV; however, if you think you have a position that
fits my experience, then
Click here to see my resume.
|
||
|
|
||