| September 2006 |
| By Michael DeSantis |
Imagine that you’re the first end user to get a new piece of software. A product manager in New York City wrote the requirements for it; a software architect in Herndon, VA designed it; a group of developers in Austin, TX contributed half of the GUI; another group in San Francisco, CA wrote the back end to the database; and a contractor in India did the rest of the coding and builds.
What are the chances that everything in this application will work correctly the first time you try using it?
If you said, "Slim to none," then you have some insight into my life as a Senior QA Engineer at a large ASP. I often say that QA is where the rubber meets the road, because the QA tester is often the first person to try and install and use the application. In the scenario I described at the start of this essay, which in my experience is common, the development team is scattered across time zones and continents. As a QA engineer, you are often the first person to look at the application who has more than a simple idea of the product side and technical side of the equation.
In this job, I have to be a jack of all trades, with skills in all of the following areas:
1. SYSTEM ARCHITECT: I have to understand the big
picture of the application I’m testing. What is it for? Who is going to use it? How? I also have to understand the detailed requirements: what are all the parts and what do they do? What are all the valid inputs and outputs of the system? What should happen in the case of an error?
2. SYSTEM ADMINISTRATOR: I may have to build my own
test environment, including ordering new hardware, installing it in the lab, installing any required OS (Redhat Linux, Solaris, or a flavor of Windows Server), and installing any required supporting applications. During testing, I have to know enough about the underlying OS to monitor connections to other systems (such as database connections) and memory and disk usage.
3. NETWORK ADMINISTRATOR: In the course of building
the environment, I will at least have to get my server on some sort of network. I may also have to build a special network to test with: do I need a T1? A firewall? A NAT? An MPLS link?
4. TECHNICAL WRITER: At the start of the process, I
have to write a test plan and test cases that describe what I’m going to test and how I plan on testing it.
Even though I write the test plan, I’m not always the person who executes it, so the test cases had better be clear enough for someone else to use them. When I find problems, I have to write a description of it that is clear and complete enough for anyone else on the project to understand without further explanation from me.
5. POLITICIAN: When you find a bug in an application,
you’re critiquing someone else’s hard work. It’s natural for anyone to react negatively to criticism.
At some point, though, you’re going to have to ask that same person for help in understanding the system, which you need to get your job done. Sound tricky?
What’s worked for me is to demonstrate my competence in other areas (see numbers 1, 2, and 3 of this list), and communicate clearly but without judgment.
6. TESTER: As a tester, I have two main
responsibilities. The first is functionality testing, and that means making sure the product does everything it is supposed to do, in all the ways it can be done.
The second is performance testing, which means ensuing that the product will perform adequately when people use it.
7. PROCESS SPECIALIST: QA is more than testing;
ultimately, it’s about making sure that your company follows quality practices for developing software. Defining a “quality practice” is far beyond the scope of this essay, but you should take a look at Software Testing, by Ron Patton, or Testing Computer Software, by Kaner, Falk, and Nguyen, if you are interested.
The two most satisfying parts of my job are 1.) when a complex system that I have installed and tested begins to work well and 2.) when I’m finished and my company delivers a product that is the best we can make, in terms of functionality and reliability.
If you would like to submit an article providing an insider’s view of your tech or engineering job, please send your article to us at ITtrenches@dice.com.
Comments on this article? Share your feedback on our discussion forum, Dice Discussions.
*Please note, you must be a registered job seeker in order to submit your question to Dice Discussions.
|
|
|
