As testers we typically receive software from a development group at the end of the build cycle and then install this software into a given test system. We then run a set of pre-written test cases that exercise the software in a way that tests the software in a simulated environment. These tests generally take one of 3 forms. 1) We examine manually or programmatically the UI screens that the software produces. 2) We test the objects and methods of those objects in the program by exercising test code that interacts with the product code. 3) We do a "System Test" or black box test that places the product in a simulated user environment and then we do the operations that an end user would and verify the results.

After a defect has been found, it must be reported to development so that it can be fixed. Much has been written about identifying defects and reproducing them--but very little has been done to explain the reporting process and what developers really need. This paper is to provide a guideline for what information should be included in a report and how the information will vary based on the type of bug and the type of function.

Three years ago, the NYSE and SIAC established an initiative to improve the productivity and quality of testing. This paper discusses the key architecture and infrastructure elements of that initiative including: The suite of tools needed to test and control 20 major software systems that are written in many different computer languages, operate on heterogeneous  hardware platforms and operating systems, and are in a constant state of change;
The development, operation, and maintenance of robust, reusable business-oriented Regression Scripts; Key issues and lessons learned.

Data centric products such as language and language-based logic products can pose an overwhelming test problem. Here is an approach to begin defining an omniscient test suite to attack search engine bugs using model-based testing theories in the real world.