EMILY L.
EBERLY
Quality Assurance Software Test Engineer
Project Coordinator / Manager
Cincinnati, Ohio 45242
Phone: 513.481.5128
Fax: 513.661.0567 Web Site:
www.TheSoftwareTester.com Email:
EmilyEberly@TheSoftwareTester.com
ENGINEERING WORK BACKGROUND DETAILS:
Great
American Insurance Companies: Cincinnati, Ohio
BUSINESS
ANALYST, 8/04 through 10/04
(Consultant)
I
provided Business Analyst services for a small team to understand and gather
Business and Functional Requirements and develop Use Cases for a proposed
rewrite of an existing legacy mainframe system for one of the Subsidiaries of
Great American Insurance Companies. I analyzed numerous complicated Excel
accounting spreadsheets, batch cycle Focus reports, worked closely with the
client’s employees to understand their current business practices, and helped
the team gain insight on how a single new .NET system could possibly replace a
varied mixture of mainframe systems, manual procedures, and various software
tools.
The
Health Alliance of Cincinnati, Ohio
TESTING
COORDINATOR, 12/03 through 4/04
(Consultant)
The
Health Alliance of Cincinnati, Ohio is currently preparing to implement
Computerized Physician Order Entry (CPOE) at two of their six hospitals, the
University Hospital and The Christ Hospital. By 2006, CPOE will be rolled out
to the other four hospitals: Jewish, Fort Hamilton, St. Luke East, and St. Luke
West. Only about 6% of all hospitals in
the United States are currently up and running on a CPOE system. By 2010, per a
mandated requirement that will vary from state to state, the nation’s hospitals
will have already moved to CPOE, or be in the process of implementing such
practices.
All
six of the Health Alliance hospitals currently use IDX LastWord for their patient care and billing
processes and all
of these LastWord modules work in combination with each other and are
interfaced with other Health Alliance information systems. The IDX LastWord software
resides on a shared HP Himalaya 7400 Series non-stop mainframe; based on Tandem
architecture.
To
enable the CPOE process for The Health Alliance, the vendor has modified two IDX LastWord modules, Order
Communication and Pharmacy In-patient. The code for the
remaining modules has not been modified for CPOE. Custom CPOE tailoring to the
Order Communication and the Pharmacy In-patient modules is being performed on
site by the Health Alliance IS&T Care Management Analysts. Input as to what should be tailored is being
jointly designed by the Care Management Analysts, the CPOE Clinical
Consultants, and Department Representatives, (Physicians, Pharmacists, Nurses,
HUCs, and other LastWord users); all of whom provide input as to what screens,
buttons, commands, pull-down menus (VTs) should be created, modified, enhanced,
etc. for CPOE. In addition to system design, process flows have also been
developed to support the new CPOE future state workflows.
My
responsibilities for The Health Alliance included the following:
Without any CPOE system requirements or project
specifications and with the initial Design still underway throughout the
duration of my contract, I created a Project Scope Map; interviewed numerous
team members to discover who did what, how and when; and created a CPOE Key Testing
Events calendar for 2004 per management requirements (which includes the
following events: System Component Test #1, User Component Test #1, System
Component Test / User Component Test #2 Combo, IT #1, and IT #2). I
successfully passed all computerized CBT training modules in the use of IDX
LastWord. I planned and facilitated a number of large brainstorming and testing
related group meetings; defined numerous software testing concepts to include
Unit Testing, Functionality Testing, Regression Testing, etc.; and created a
Master Test Plan. I planned for and launched a core Testing Methodology (which
included having created a variety of software testing documentation about
functionality and regression testing, working examples, test case templates,
and other “How To” documentation) that the employees can use after my roll-off
from the project to further their methodology and testing development. I
identified Essential CPOE Information Sources and resources within The Health
Alliance; identified which additional test plans need to be written for future
test events; and identified what is needed for accurate CPOE issue tracking
with suggestions for the development of bug database standards. I organized and
set up on the shared directory working files and folders; provided real-time
software testing for certain elements of two finished workgroups (which found
more than a dozen bugs in very short order); and worked very closely with several employees throughout my contract.
In particular, I provided focused attention on two employees (CPOE Clinical
Consultants) in how to “think like a software tester” and how to test their
software - as well as how to identify bugs and report such issues. I also
transferred knowledge and duties (to the best of my ability and as her time
allowed) to the employee assigned the role of Testing Coordinator.
QUALITY
ASSURANCE TEST ENGINEER, 4/03 through 11/03
(Consultant)
SMARTworks is a customer driven e-business and print procurement
firm that hosts an efficient web-based and
customizable solution for the management of a complex array of Standard
Register forms, as well as unique customer specific documents, digital assets
(electronic documents and images), and e-procurement. With a single login website,
SMARTworks provides individual accounts to over 800 blue-chip customers. Upon
signing on, companies can manage all of their custom printing, forms
procurement, and other office supplies purchasing needs in a streamlined and
efficient fashion. SMARTworks provides
a complete digital library of both images and design files to allow for easy
modification of printed materials and electronic documents, including the data
storage space for everything. Organizations both large and small can better
manage their financial print resources by utilizing the wide array of features
and reporting capabilities offered by the system. In addition to companies
being able to design, procure, distribute and manage their own preprinted and
electronically created documents, they can also interface directly with their
print providers – whether it’s an in-house print shop or a 3rd party
commercial printer - by placing their readied orders via the SMARTworks
ordering/requisitioning process.
My duties included the following: working in a small team
environment, designing and writing test grids to track specific items for
regression testing; documenting main functional areas and sub areas of the
software for tester Regression assignments, validating and testing new builds,
assisting in the 400+ customer migration from version 5.0 to version 6.0, and
assisting in the Integration of new 6.0 customers. To the amazement of my QA
peers, I even volunteered and did Telephone Technical Support for a while
during an especially busy time for the Customer Support Team. It was fun and
challenging and I tried to convince the other QA folks to try it, too, but they
just looked at me like I was green and from Mars! This experience, however, was a great way to see the software
from the customer’s eyes, which I felt would only make me a better tester;
besides that, I made some new friends! I also lead special QA projects as
assigned, and interfaced directly with senior executive management to analyze
current work flow patterns and make recommendations for process improvement.
The Rational Unified Process (RUP) and some of the Rational Suite TestStudio
tools are currently in various levels of use, including ClearQuest for bug
database reporting and RequisitePro for document generation and control. Microsoft
Project Central is being used for time reporting and tracking efficiency.
Additional tasks and duties included the inception leadership and management
responsibilities for starting up a Mercury Interactive TestDirector 8.0 and
QuickTest Pro 6.5 Automated Testing project, for which I was on the vendor
selection committee to evaluate and choose the best automated tool for
SMARTworks. Following its purchase, I worked closely with 1 other systems
engineer who got the tools installed onto a unique server, configured, and
integrated with the Rational tools and who also implemented regular backups of
the Mercury server. I single-handedly wrote a project proposal,
multi-phase project plan, and designed
and set up a mini test automation lab on my own with 1 master and 4 slave
machines – each with unique Operating Systems and Browsers. I also arranged a
technical ramp up session with a Mercury trainer who came to our site and made
sure we were installed and set up properly, as well as providing me and 2 others
with compressed and concentrated training in the following Mercury courses
(which are usually taught over a longer period of time): Fundamentals of
QuickTest Pro, Advanced QuickTest Pro, Administering TestDirector, and Using
TestDirector. Prior to the end of my contract, I had worked out the
communication issues between the QuickTest Pro client machine and the
TestDirector machine. I had achieved the ability to control basic script runs
from the TestDirector CPU to be executed on the QuickTest Pro client CPU.
QUALITY
ASSURANCE TEST ENGINEER, 4/01 through 6/01
(Consultant)
Digineer was a Cincinnati, Ohio firm that provided technology
enhanced business and clinical solutions, via custom developed software and Web
sites for the worldwide healthcare industry.
Nelson eHealth Group, (NeHG) is a Princeton, NJ firm that specializes in
transformational digital marketing and selling tools for pharmaceutical
companies. NeHG had partnered with Digineer to develop an innovative line of
targeted Web sites and data gathering/reporting tools to revamp the traditional
relationship between time-starved physicians and pharmaceutical
representatives.
During the length of my contract at
Digineer, I provided a variety of QA services for two NeHG projects: eDetailing
and eStatus. For both of these projects, I worked closely with the project
managers, team leads, graphic designers, and programmers during the early
development stages. In union with the team leads, I wrote many test cases based
upon a predetermined test definition list. I also executed Alpha, Beta, and
Final User Interface, and Functionality test cases against a variety of Browser
and CPU configurations, which incorporated the various versions of Netscape and
Internet explorer. I wrote, regressed, and closed numerous software and Web
site bugs, and attended many QA team meetings.
The eDetailing project consisted
of 2 elements: a brand specific “virtual pharmaceutical rep” Web site for a
drug called, Levaquin and a stand alone Previewer tool, which is a type
of Web site template to be used for creating additional brand Web sites. The Levaquin Web site is available in
either FLASH mode or static HTML mode and replaces the need for an in person
visit by a pharmaceutical drug representative.
In the drug marketing industry, this
process is called “Detailing”, hence the name, “eDetailing”. eDetailing
provides a self-paced, log in educational process at Basic, Intermediate or
Expert levels with relative Professional Credits of 25, 50, and 100 points,
respectively. Upon completion of an eDetail, targeted physicians can earn
professional credits, which they can redeem and distribute for their own use or
donate to charity. Either targeted or untargeted physicians can log in, receive
educational information about the drug, clinical study synopsis data,
prescribing information, drug safety updates, typical patient histories,
physician testimonies, order drug samples and participate in other eDetailing
related activities. The Levaquin Web site can either be accessed
manually or via a CD, which will load the browser automatically and run the
images off itself, versus the server, to make the process as fast as possible.
Targeted users are tracked via a CD serial number and a valid DEA (Drug Enforcement
Agency) number. The Web site is secure and all user access is authenticated by
the unique DEA number assigned to each physician. All user provided data and
statistical usage information regarding the eDetails is collected and stored in
a database.
The eStatus project consisted of
2 elements: a multi brand “eDetail data sorting, tracking, and status reporting
utility” Web site (with a tour that runs in FLASH mode or static HTML) and a
stand-alone client server Admin Tool. Based upon data gathered from the
eDetailing database, eStatus displays various charts, statistics, and calendar
information, which can be emailed, printed, or graphically imported into
another application using the PNG format.
The Admin Tool enables the administrator to set up companies, users,
project types, projects, results, user access privileges, and the association
of users to projects and projects to results.
Y2K
CERTIFICATION AUDIT REVIEWER, 6/99 through 10/99
(Consultant)
I joined the AFG Y2K Project Office as
an Audit Reviewer. This was a very high profile group. I found myself reviewing
the exact same genre of mainframe applications that I had been previously Y2K
testing / certifying for the CIS Department (see below). My knowledge and
expertise in the testing methodologies gave me an advantage from the inside out
in being able to accurately judge how well other teams had performed their Y2K
Testing, Documentation, and Certification duties. To ensure objectivity, I did
not directly review any applications that I had personally certified earlier.
As a member of this small team of audit
reviewers, I was responsible for reviewing Y2K tested / certified applications
that had been submitted to the Y2K Project Office by the various Certification
Test Teams for Audit and final Y2K Certification. I carefully reviewed all
aspects of an application's Y2K tested history. This included analyzing its
date specific test plan for completeness and accuracy, all supporting
documentation to offer "proof" that the app was Y2K compliant, lists
of any date related bugs that were found during testing with their resolutions,
its compatibility with other interactive applications (as applicable).
Where Certification issues were
discovered, I worked carefully with the test team to resolve them. In every
case, close interaction with the application test team's leader was
necessary. Typical areas needing help
were test plan writing and documentation. Often, major reorganizing and
indexing of the documented test materials - including culling superfluous
documentation was necessary. Sometimes
even the re-testing of key software components had to be done. No application was determined to be Y2K
compliant until all aspects of its date processing modules were properly tested
and Certified by the test team, reviewed by an audit reviewer, inspected by an
official auditor, and then readied for placement into long-term storage. The
whole point of having an audit review was to ensure that due diligence had been
performed and that the application's Y2K test team had built defensive
documentation, should litigation ever ensue within the next seven years.
Great American Insurance Companies: Cincinnati, Ohio
Y2K
CERTIFICATION PROJECT COORDINATOR / TEAM LEADER, 7/98 through 5/99
(Consultant)
I joined the Corporate Division’s CIS
(Corporate Information Services) department as a multi-purpose individual,
where more than 100 applications were destined to be Y2K Certified by at least
25 test teams throughout the second half of 1998 and most of 1999. My primary
mission was to create a Y2K Certification testing methodology for the group,
focusing on a Test Plan template that could be used by all up-coming
certification teams for all of the Corporate business applications undergoing
the rigors of Y2K Certification. I designed and implemented a Test Plan
template, a Y2K Quality Gate system of sign-off forms and tracking documents,
as well as a set of Test Plan Questionnaires. The Test Plan Questionnaires were
designed as data capturing tools and targeted for key resources, such as the
Business Owners and knowledgeable Users, Technical Experts, and Subject Matter
Experts and System Analysts. I wrote a series of “How To” documents, which
explain in a logical flow such things as, how to go about setting up for Y2K
testing, and how to get started on generating a custom test plan for an
application. I also provided a step-by-step list of team leader duties that
must be considered when launching a new Y2K Certification test team and
beginning a new test project, listing specific tasks that the team leader must
do. To organize the teams, I created a Y2K directory on our group’s shared
server and set up sub-directories for each application. Inside each application’s
directory, I organized folders to contain the standard files and documents
required for certification. To track problems and resolutions, I designed and
implemented a “bug” database from the ground up, using Lotus Notes.
I was also assigned the responsibility
of leading the Y2K Certification efforts for the Premium Entry application,
which was the first application in CIS to begin its Y2K Certification process.
Premium Entry is an application of major importance to the company, which
processes all insurance policy related transactions. Premium Entry is the vehicle that logs
all Premium business to the Company’s books. It is written primarily in COBOL
with some EasyTrieve PLUS and SyncSort. The various tools related to its
running are: JCL, CA-7, CA-11, Repository, and Panvalet. Technically speaking,
it is a data capturing system. Its sole purpose is to book Premium data for
policies. It is a conduit that directs the data flow downstream to Management
Reporting, Bureau Reporting, Earnings, Accounting systems, Statuary Filings,
etc., and other Great American applications. Premium Entry is interrelated with
all other CIS systems and produces a wide variety of reports, such as errors to
be corrected, accounting reports, tax and surcharge reports, etc.
If Premium Entry were to fail sometime in the new century for any reason, the
company’s ability to process new business would be stopped in its tracks until
the problem could be resolved.
My team tested with full volume
Production data, using a Baseline from August ‘98 month-end. Test Cycle 1 aged
all input files by 1 year (included processing Expiration Date into Year 2000), and upon re-running, created the
Test Cycle 1 test output reports. Test Cycle 2 aged all input files by 2 years
(included processing Effective Date
into Year 2000), and upon re-running, created the Test Cycle 2 test output
reports. For each aging cycle, prior to generating the test output for the User
Verification Team, the programmers ran file compares for key files. A TIS (Test
Instruction Sheet) contained the expected results for each series of jobs that
were tested. All unusual or unexpected observations that were discovered during
the testing and verification stages were recorded into the CIS Y2K Issues
Database and the Premium Entry TISs.
Y2K
CERTIFICATION PROJECT COORDINATOR, 12/97 through 6/98
(Consultant)
As a Project
Coordinator for the Marine Y2K Team, I was one of 130 people (consultants and
regular employees) who were brought together for the Y2K project, and who were
spread out over 12 unique groups (each with their own Project Coordinator),
where the company was attempting to test more than 90 different insurance
applications for Y2K Compliance; in as short a period of time as 6 months.
My Marine Y2K
Team consisted of two separate tracks called, Marine Track #1 and Marine Track
#2. All members of my team were mainframe savvy programmers, who used such
tools as JCL, COBOL, CICS, Xchange, File-aid, Data Ager, Xpeditor, and
Microfocus COBOL. The testers, in particular had received special training in
QA Hiperstation & QA Director.
The activities
of both tracks were managed by me and consisted of the following personnel:
· 2 Testers, who
ran all the test cycles.
They executed automated online testing scripts for the on line
applications and ran Batch programs using
JCL and COBOL as needed, for the Baseline, Aged, February 29th
(Leap Year), and Year 2000 testing.
· 2 Technical
Administrators, who supported the testing regions and verified that all the
pieces were there.
They assisted the testers ensuring that all required files were
present and that Security Privileges were properly set in place.
· 2 Technical
Coordinators, who had the business knowledge.
They were knowledgeable in the Marine applications and Batch
processes, which were being executed.
They provided an in-depth understanding of the company’s business
rules, in order to achieve correct
Results.
· 2 Test Planners,
who wrote the test plans, per a standardized Test Plan Template.
They were specialists in the applications being tested, and worked
closely with the developers and users to create valid test cases.
· 21 Business
Coordinators, who were the expert users.
They were utilized as information resources and as on-line test
case entry specialists (whose keystrokes were captured by QA Hiperstation and
re-run many times during on-line testing). All of them were remotely located in
Seattle, WA; Princeton, NJ; and New York, NY and represented the User Community
at large for each respective application being tested.
These tracks,
though separate, were in effect, two collaborative parts of a whole and I
managed them as such, due to the team-oriented nature of our Y2K testing
efforts. The team members on each track were primarily responsible for their
own track’s list of software applications, as detailed below. However, both
tracks were expected to support each other in times of need and when available
time permitted. At first, both tracks met together as one group (daily) at the
beginning of the project, for informational and progress Team Huddles. As the
project evolved and the team learned the routine and processes, the Team
Huddles went to an “as needed basis”. Additionally, each Wednesday was “Statistics
Day”, where my testers and technical coordinators were especially helpful in
providing timely and accurate information in contribution to my PC Weekly
Statistics Reports.
The success of my team depended entirely
upon my ability to effectively manage a diverse array of personalities, skill
sets, experience levels, aptitudes, and a very tight testing schedule. I was
held completely responsible for the success of my team and I took this
obligation very seriously. Had we failed to meet our goals, significant
attention and investigation as to why they weren’t met would have resulted.
Needless to say, although we never missed a deadline (working a few nights and
weekends as necessary), the stress factor was very high as well as the
potential for team mates to buckle under the pressure, but we remained as cool
as could be expected. In fact, all of the members of my team were exceptional
people, both in talent and in their ability to get along with each other and
perform well under any conditions.
My
responsibilities included building a cohesive and team-spirited group, managing
all aspects of the 2 testing teams of 9 direct reports (4 contractors & 5 employees) and 21 off-site employees,
interviewing & hiring a key replacement contractor for IDMS and ADSO skills,
conducting contractor performance reviews as needed, holding daily team
huddles, interfacing with the mainframe Security people regarding access
privileges for my team’s testing regions (emulating 25% capacity of the normal production environment), conducting
application Kickoff meetings using video and telephone conference tools for
off-site employees, attending Y2K planning sessions and skills training
sessions, attending twice a week PC Support Group meetings and weekly
Leadership Support Group meetings, interfacing with the Quick Response Team to
fix non-Y2K Production bugs, attending weekly Change Control meetings (as
needed when my team produced Y2K Code Changes to be merged into Production),
working closely with the Information Systems people in coordinating Production
Implementation, ensuring that both of my teams provided prompt Acceptance
Testing to verify proper Implementation into the Production environment,
providing weekly statistical progress reports for each application under way,
processing contractor time cards, producing statistical time utilization
reports, processing all Y2K deliverable documentation and official sign-offs
and creating an archive folder for each application (in preparation for the GRE
Y2K Auditors), posting weekly numbers charts, and hosting monthly team member
and guest of honor lunches.
Although
it sounds like it would have been “Mission Impossible”, all of my team’s Y2K
responsibilities were completed 3 weeks ahead of schedule and overall, the
entire company’s Y2K efforts were completed with results delivered on time for
the July 1, ‘98 deadline. A Herculean effort, indeed; and it is this fast-paced
environment in which I participated.
The
Marine Team’s Y2K testing work consisted of the following GRE Insurance Group
software applications:
Track #1
Marine Assured
Inquiry, Marine Manual Stat, Marine Cash Collection, Marine, Premium Inquiry,
Marine Yacht System, Marine Yacht Pol, Marine Broker Inquiry, Marine Broker
Database, and Marine Reinsurance Update.
Track #2
Marine CMF &
EASEL, Marine Loss Trans, Marine Loss History, Marine Reporting, and Marine
Miscellaneous Focus Onlines.
QA
SOFTWARE TEST ENGINEER, 11/96 through 12/97
(Consultant)
I came onboard to join the Personal
Lines Division team of Quality Assurance testers and business analysts for the
Y2K project called, IMACS. The Microfocus COBOL and C++ source code of this new
enhanced GUI insurance policy system was being modified and customized in-house.
An aggressive Make schedule provided a multitude of new Builds to test and kept
the testing team busy changing environments to the next available CICS test
region and updating their local IMACS databases. IMACS was undergoing a
“Rollout” plan of adding live state programs in a phased approach, with Ohio
being the compare base. Eventually, IMACS will replace the original 3270 Legacy
system (for client and policy entry) called, PRO. Both are concurrently in use
to enter either “live” or “test” Client Households and HomeOwner and Automobile
policies. I contributed to the IMACS project by writing test plans, endorsement
test grids, testing new Builds of the software, and reporting bugs, which in
the Personal Lines division are called System Inquiries, or SIs.
I also designed and implemented two
special testing projects outside of IMACS (3270 Summary Screens and 3270/GUI
DocumentDirect), worked directly with those programmers, wrote and illustrated
(MITNOR Graphics) all of the user documentation for both of them, and conducted
several user training sessions.
My favorite project, though, was ATF
Automated Scripting, which grew to occupy 100% of my time. Towards the end of
June ‘97, I came onto the ATF project in its infancy and pulled it out of total
disarray. There was no one on site who knew anything about automated testing.
ATF had been set aside for several months and the original people who had been
introduced to the product had either moved on or forgotten what they learned in
the initial vendor-provided training. Based on my previous experience at Apple
Computer with an automation product called, “Virtual User”, I organized the
structure of the ATF software, properly installed it on various machines and
configured it as needed, including modification of the Config.sys files on each
CPU to accommodate particular ATF modes of operation. For a while, I was the
sole person on the project, so I was able to design and implement an automation
strategy from the ground up. Later, I was joined by several others to form an
ATF Team, for whom I offered layout suggestions, scripting insights, and savvy
user tips. I was able to provide the team with an organized and flowing system,
containing numerous executable scripts that automatically entered Clients into
the IMACS database and generated sequential Home Policies via a Master
Controller Script. I continued to refine these scripts, resolved certain
networking problems, and debugged other issues that arose, due to multiple
people working on a complex relational system.
SOFTWARE
AND HARDWARE TEST ENGINEER, 3/94 through 7/95
(Consultant)
Within 2 months, I quickly became fluent in the precise and
unusual area of the Medical Imaging industry. I came to be known as the “expert
tester” of a highly secret Ultrasound Machine, called the QV200, which was
capable of Generating, Storing, and Retrieving Animated Digital Clips of such
fantastic things as the Doppler Effects of blood moving in two different directions
from a prolapsed mitral valve, a 10 week old fetus rubbing its forehead, and
blood moving through a clogged section of the carotid arteries in the neck. In
my 3rd month, I was sent to Ann Arbor, Michigan to the company’s Engineering
Headquarters to work one-on-one with the programmers and other key personnel
who were designing and developing this fascinating technology. It was there
that I participated in the testing of one of 6 single units, each consisting of
the following networked machines: Ultrasound Imager (about the size of a hot
dog stand) housed in a wheeled chassis, Database computer used to direct where
the stored images would be placed and recalled, Review Station for accessing
the images for review, Print Server for printing the images to specialized
medical printers (almost the same size as the Ultrasound machine) and last but
not least, a Sun file server on which the images and exams actually resided. We
dealt with such perplexing issues as UNIX File Servers, Database Management,
Image Playback Times, Storage and Retrieval Times and various other features
and requirements in demand by the ever growing medical industry. I also wrote
Test Plans and Instructional Documents related to the use and proper set up of
this very sensitive and complicated equipment, where just one seemingly
insignificant step omitted in the installation procedure, or something
installed out of order, could wreck complete havoc on the system and bring the
entire network to a grinding halt.
SOFTWARE
TEST ENGINEER, 5/92 through 3/94
(Consultant
initially, and Employee later)
I began testing for Global Village as a
contractor in May of 1992, becoming a regular employee in August, 1992. During
my employment, I served the company in two distinct categories: as a Quality
Assurance Test Engineer for the Engineering Department and as the Customer
Service Testing Engineer for the Customer Satisfaction Department; each
position approximately one year in duration.
CUSTOMER
SATISFACTION TEST ENGINEER, 5/93 - 3/94
The type of testing done for the
Customer Satisfaction Department was different from that of QA in the sense
that I was working in a post-market environment with a very heavy emphasis in
Resolving Customer Problems and Debugging Hardware Failures of returned modems
encountered in the field of real world usage. I set up a basic testing lab and
ran it on my own. The primary source of test issues was the technical support
staff itself. I also dealt 1-on-1 with selected customers providing Problem
Debugging and Modem Installation Services, as needed. I performed many tasks
for this department, including developing the RMA (Return Merchandise
Authorization) Hardware Symptom List, extremely detailed RMA Trend and Pattern
Reporting, in addition to doing Technical Writing and Teaching, as needed.
QUALITY
ASSURANCE TEST ENGINEER, 5/92 - 5/93
The emphasis in QA was to Test
Pre-released Products, both software and hardware. Working in a team
environment, I helped to guarantee the quality of the Fax Center DA, the
GlobalFax driver, and the INIT Cdevs called TelePort Serial, PowerPort, and
TelePort ADB, respectively. I tested all aspects of the software functionality.
Additionally, I tested all Global Village hardware products ranging from the
original v.32/Dongle internal modem to the TelePort Gold. Other testing aspects
included checking 3rd party applications, modems, and fax machines for
Compatibility with Global Village’s own products. Doing this required teamwork,
the ability to follow test plans, if available, and serious independent
examination of various features of the software, including but not limited to:
Option and Command Key Faxing, Fax Enveloping, Scheduling Faxes, the
Registration Process, the Installer Process, etc. I was also the Lead Tester
for the OCR (Optical Character Recognition) product.
MCSQ
(Macintosh CPU Software Quality) Division
SOFTWARE
QA COMPATIBILITY TESTER ON NEW CPUs, 12/91 - 5/92
(Consultant)
I provided Compatibility Testing for Beta version, pre-released
CPUs. Upon finding a bug of any type - cosmetic, or crashing, etc., I attempted
to duplicate it under various operating conditions: (Virtual Memory On or Off,
24-bit or 32-bit Addressing, System 7.0.1 or 6.X, Single/Multi Finder; also
noting such things as the ROM and CPU versions, On-board RAM, and whether or
not the machine was running System 7 Tune Up), and then checked to see if the
bug was reproducible on released CPUs, such as the IIci and the LC. If it was a
crashing bug, a MacsBug Log of the crash was generated and then the Complete
Regression Path was followed by entering the bug's information into Apple's
Anomaly Database called, Radar. I also did Virtual User Scripting. Virtual User
is an Automated Testing environment that runs inside an MPW shell. Apple is
currently using VU Scripts to run Quick Looks and Medium-Depth Scripts for
Compatibility Testing of Third Party software products on prototype CPUs. VU
can run with either Single or Multiple Targets, and within or across Target
network zones.
SOFTWARE QA
APPS. TESTER FOR THE WRITING CENTER, READER RABBIT, OUTNUMBERED!, 7/91 - 12/91
(Consultant)
I tested the features of a new Word Processor for Children, in
both stand-alone and networked versions. I also provided additional QA testing
for TLC on two other product types: Children's Reading and Mathematics Games. A
typical day was spent User Testing the software, where in a team environment, I
assisted in Compatibility Testing, Functional Testing, the finding and writing
up of new anomalies, the Regression Testing of previously found bugs, and
"Ad Hoc" Testing, while waiting for fixed versions of the software to
come in from the programmers. Also, we would go offsite to Apple Computer's
CIAC Third Party Testing Lab, to concentrate on Compatibility Testing with
hardware not available at TLC.
Space Systems/Loral: Palo Alto,
California
TECHNICAL
PUBLICATIONS EDITOR and GRAPHIC ILLUSTRATOR, 5/91 - 7/91
(Consultant)
I worked with a team on a huge government proposal document (many
1,000s of pages long) and my primary focus was twofold: First, I imported
straight text created by the Technical Writers into a common platform,
modifying it as necessary to meet the standardized format, edited handwritten
redlines from the Technical Editors and type set from scratch Scientific
Tables, Mathematical Formulas, and Multiple Columns, all done in Microsoft Word
4.0. Secondly, I created new and edited existing Schematic Drawings that were
to be inserted into the proposal, using Adobe Illustrator. A unique feature of
this job was that the editing work would come to me in either Macintosh HFS
format or IBM DOS, and in any software package between the two. This necessitated
that my Mac was "Bi-lingual"; having DOS Mounter installed in the
system folder and Mac Link Plus in the Utilities folder.
SOFTWARE
QA COMPATIBILITY TESTER FOR PRINTER DRIVERS, 4/91 - 5/91
(Consultant)
I provided software testing in a Macintosh laboratory environment
in which my primary focus was to Test more than 50 different Mac software
packages against 8 Epson Printer Drivers (6 Dot-Matrix and 2 Laser), using
various Macintosh hardware/memory/system configurations, including Kanji, and
comparing the quality (and color when appropriate) of the outputs to those
generated by the Apple Image Writer LQ and Apple Laser Writer II. My methods of
testing included running a series of Mixed Attribute Tests on each driver, as
well as conducting separate tests using the Portrait and Landscape printing
modes in varying degrees of print enlargement or reduction. Bug reporting, bug
verification and system error duplications were all based upon Apple standards.