I returned for my second rotation on August 30, 1999.  During this rotation, I was assigned to work under Joe Cappezuto in the Integration and Test team.  The main task for me to accomplish was testing the most recent product builds of Code Composer Studio and reporting any problems or inconsistencies in behavior, as well as any suggestions for improvements, to the product manager of that specific product release.  After a brief but thorough introduction to the methodologies and applications used in testing, I began testing the latest builds of the TMS320C54x Code Composer Studio product (as mentioned previously, a large software application that enables code to be developed, built, and run on a DSP through either a simulator or emulation technology that connects the DSP to a host PC via one of its ports and a cable (known as a JTAG)).  By the time I had joined this product group, the release date was only a few weeks away, and thus testing needed to be done quickly and efficiently.  Everyone on the product team, led by Tim Pasko, worked many hours to ensure the stability of the product.  With such a sizeable combined effort, the team was able to release the product even earlier than anticipated.
                Without any delay, I moved to my next task, working under Matt Bost on the TMS470 Code Composer Studio release.  Although the release date of the product was two months after the end of my work rotation, all of the team still worked hard to make the product as solid as possible.  To adequately test both of these products, a suitable level of knowledge about the DSP or microprocessor for which the product was being made was necessary.  Otherwise, errors would not be properly understood, and one would not have a deep enough comprehension to even know if the error was valid or not.  Thus, I learned a good amount about both of these product lines through my testing work, as the testing done was much more in depth than in any previous experiences.
                 The other main task I performed during this work rotation was using several automation tools to determine which was the easiest to use and which best fit the Integration and Test team needs.  Automation tools enable testing to be performed on a product without a user sitting at a computer and working step-by-step through a given test.   An individual can start a test with the click of a button, walk away from the computer, and return minutes or hours later, viewing a detailed report of any failures which occurred in the product.  The main tool which was evaluated was Rational Robot, which TI eventually chose to use for its testing automation.  I used Rational Robot extensively to record, write, and perform tests, through which I was able to understand in detail the workings of the tool, and therefore help in determining the usefulness of the tool to the testing team.
                 I enjoyed working on the Integration and Test team.  It was a very educational experience, as I was able to directly apply knowledge and coding experience learned in the classroom when working with Rational Robot, which uses a variant of Visual Basic for writing tests.  Though I had never worked with Visual Basic before, I learned the basics of the language and applied my general coding knowledge through this work.  I was also able to learn even more about the work environment and structure of the company through working closely with people on specific product teams.