Taught a 40-hour Mercury Interactive TestSuite Quick Start Class in my spare time. Students had previously completed a two-week intensive technical training class. The purpose of my class was to provide hands-on, shoulder to shoulder guidance and training in the student’s own testing environment. I spent a few hours explaining the automation process along with code examples. The students completed and demonstrated actual scripts that have been used in their regression and Y2K testing cycle. I am provided feedback and worked with students to enhance the scripts. The WinRunner 2000 TE add-in is being used to communicate with Case Maker DRSE on Tandem Workstations.

Analyzed and discussed completeness and accuracy of SAP Y2K System Level QA Documentation for a 20 hour project.

Team member involved in completing an automation test harness to test the Access 2000 NYMEX Trading Application. The approach was to describe the workflow and test data in Excel Spread sheets. Perl was then used to automatically generate WinRunner TSL code. The generated code called a library of functions that I maintained. I wrote stabilization routine utilizing WinRunner physical properties to always insure that the automation testing begins from a known application state. I documetned errors and enhancements in the spreadsheet to WinRunner TSL generation System.

Utilized the new data based driven feature of WinRunner /Power Builder 5.01 to automate the data entry process. The OMSPRINT Application, which was under test, was being used to determine the structure of magazine layouts for different demographic groups in different regions of the world. Data was being provided in Microsoft Excel and SQL tables. Cleaned up code so that it closely matches screen entry requirements. Developed TSL scripts that use spreadsheet data to fill in Windows. In addition to being able to rapidly and accurately validate and enter data into the application, automation had directly lead to locating user interface bugs. Wrote WinRunner 5.01 TSL script which is currently used to Sanity Check all modules which are built by the Development Team. Wrote TSL scripts to test transaction functionality.

Corporate Division

Returned to client to work with an enhanced version of the Test Harness, which is described below. Designed and built Test Lab consisting of 24 PCs clustered into groups of 4 using Belkin switch boxes. Wrote lab set-up procedures. Re-wrote automated procedure in WinRunner Test Scripting Language (TSL), which learns the objects on, more than 1200 SAP transaction screens. Designed, wrote, and maintaining TSL code which recognizes different types of pop-up SAP dialog boxes. The program recognizes objects on the dialog boxes utilizing real-time recognition of physical properties. This avoids having to learn thousands of possible permutations of dialog windows. The workflow for closing the dialog boxes can be read from instruction flat files created in advance by SAP specialists. The dialog boxes can also be handled in a generic way using a system, which I developed and coded. Automated Location Code SAP Transactions utilizing WinRunner and our Harness. Documented many TSL code enhancements to the harness as well as explaining several high level design strategies to our team. While working on the automation process of SAP, I have also gained valuable insight on many SAP modules such as Material Master, Sales and Distribution, and Human Resources.

Business Communications Division

Reviewed and suggested improvements to a group of related functions, which we called the Test Harness. The functions included automatic detection of the success of an action. For example if a function were used to start a transaction, the function would determine if the correct transaction window were displayed after the application stabilizes. On a failure, the Test Harness would send a message to the log and move on to another script. I also wrote several functions that were reviewed and added to later versions of the Harness. Wrote WinRunner scripts using the Test Harness to test SAP security of each transaction to be implemented in our first release of SAP. A SAP security specialist wrote a script for each transaction including data to be entered as well as functional verification points. Each script was reviewed to determine if it was a candidate for automation. I coded 130 of the scripts, which were run on a semi-monthly basis to verify that each transaction could traverse, edit, view and delete proper data on the screens. The Harness Functions made the code much simpler to code as well as to read and document. When scripts failed, I checked whether it was due to a change in SAP configuration, data requirement, SAP security failure, or if a change was needed to my TSL code. Before leaving the project, I taught a full time employee how to maintain and write new scripts. In addition to automated testing, I also wrote two manual test scripts regarding changes to SAP order entry and Cost Centers. I gathered the information by interviewing SAP analysts and other members of the SAP testing team. Writing the scripts required an understanding of UNIX, Windows NT,SAP, Access and FTP. I presented the test scripts at Walkthrough Meetings consisting of business analysts, SAP ABAP programmers, and execution testers. I participated with the testing team to maintain tracking tools such as Lotus Notes Trouble Tracking System and the Price Waterhouse Toolkit which was used to document the SAP implementation. I worked with a BASIS consultant for several weeks to assist in tracking SAP Transports. In several instances, test scenarios required transmitting hundreds of similar transactions with different data to the SAP servers. For these scenarios, I worked with LoadRunner consultants to design LoadRunner Virtual Users. The volume and stress testing was monitored and controlled through the LoadRunner Test Controller.

Tested Citibanking Foreign Check Clearing System. The Application which was written in Visual BASIC 4.0, allows the user to fill fields on the screen that previously appeared on paper based checks. Each country requiring the product had similar but different rules for producing a check. The countries I was responsible for testing were Hong Kong, Australia, and Thailand. Since the testing process was very linear, I chose to base my testing on a checklist containing different variations of input data. Used Lotus Notes to track errors as well as for communicating with the development team, other testers and business analysts

Tested the D2000-3 Foreign Exchange Network, which was composed of a hierarchy of VAX/Alpha servers, local servers, and PCs running Windows NT. Tests consisted of entering thousands of variations of BIDs, OFFERs, ASKs and BUYs into several PCs in a lab which simulated users at multiple sites. Testing required setting up several PC that would be considered to be at a local site as well as users at foreign sites. The transactions at the multiple sites would all be executed. Verification of results at each workstation had to be closely examined. Some tests required data simulators to provide a constant flow of market data to work against. Many tests required a power down or artificial breakdown of hardware components to test for local and network data disaster recovery. Output logs of the individual workstations as well as the servers were highly scrutinized for transaction accuracy. Documented, communicated, and regression tested errors to the C++ development team.

Accepted short term project utilizing WinRunner to gain hands on experience with an Automated testing tool. The testing department was using Winrunner to test a new version of the Nasdaq Workstation II Product. The product was written in Open Interface. At the time, WinRunner could not recognize most attributes of Open Interface objects. 90% percent of the code was written using analog functions rather than context sensitive, which was a great challenge for coding the scripts as well as determining accuracy of validation points. After each recompile of the Nasdaq application, I would run the automated tests required to ensure functionality and object existence (windows, fields, buttons) of specific modules. If a script failed during a run or if there was an error in the logs, I could often determine the reason for the failure. After explaining the reason for the failure, I was often given the opportunity to fix the Test Script Language (TSL) WinRunner Code. During my last two weeks of the project I wrote my own code based on manual test scripts to test fractional ticker prices.

AIG provided our entire team with training on the existing legacy system. We were then presented with the new Visual BASIC modules that were to replace the old interface. The goal was to consolidate the multiple legacy systems into one working environment that would be easier to understand, be more user-friendly and present data more logically. Some of the new systems gathered and scattered data directly from the mainframe database. Other information was sent between the legacy system and the new system by copying and pasting data to the mainframe screens. We wrote unit, field, and module and string tests. We performed these as well. The tests were repeated using variations of logon privileges. Modules I was involved with were Claims Re-engineering, Auto Residual, Claims Litigation and Claims Representative Calendar. The Visual BASIC developers used a combination of PVCS and WinRunner , and Visual BASIC to archive and perform new builds of the application. The archive structure in the PVCS changed during the development cycle. The originator of the Clipper code was no longer on the project, so I wrote a patch to allow the development team to continue producing new code.

Re-wrote existing Clipper 5.2 program that parsed a weekly feed from a mainframe, updated internal related database files and provided flat files to editors of several Standard & Poor's magazine publications. The data contained information on international Insurance Company's ability to Pay Claims. Most of the original code was for producing the pull down menu and other interface tasks but it was not properly functioning as required by the publishing departments. I spent two months re-writing the code in Clipper. After submitting the improved Clipper program, the publishing editors provided me with a new enhanced set of requirements. The users wanted a Windows front-end interface, which Clipper could not provide. I decided on using Foxpro for Windows 2.6B. Since both platforms are xBASE, about half of the code was re-usable. Created and maintained documentation for the FoxPro version of the application. Taught Editors how to use the new application.

December 93 - December 94 (Kwasha Lipton, Fort Lee, NJ)

Reference: Waquar Qureshi 732 393 0533

Updated and created more than 45 different 401(k) fund distribution systems for external corporations. The system my partner and I inherited contained about 75 thousand lines of code, which is used for switching participant’s retirement funds. I worked closely with the business partners and accountants to find a way to meet the clients documented requirements. I analyzed existing Clipper code in the Distribution and Allocation System (DAS). I Changed existing code, parameters, include statements and client specific functions to closely match the agreed upon rules. Worked with Quality Assurance group to verify that output flat files were extremely accurate.

Reference: Dean Wellington201944 9004

Ten month project as a Clipper Programmer responsible for standardizing Trouble Problem Reports (TPRs) for the Air Force Satellite Control Network Library. TPRs were being saved as dBASE III and Clipper databases in several classified locations. The project required me to store similar information from several sources as one large database file that would be updated on a monthly basis. Each data provider used different backup applications such as PKZIP, DOS backup, and Fastback requiring me to first extract data. Wrote and documented a user-friendly menu driven program which moved data records from individual databases into the library database. Each record was compared to existing data records. In case of data duplication, the user was given an opportunity to determine the more accurate record. The user was also prompted to enter missing required data. Wrote validity logic to scan each entry for improbable data and automatically correct record when possible with an entry made to an output log. Discussed progress of my code and the condition of the Library Database to the Air Force each month. Trained employees on usage of my library management software. Provided Metric Results based on library data in report format to management on an as needed basis.