Software Engineering Glossary
QA Terms
Press the "Letter" button to view the glossary contents for that specific letter.
Other topics within the glossary: 
| Acceptance Criteria | Acceptance criteria are predetermined expectations of the operation of the application system. These criteria are established during requirements definition. The user(s) responsible for the application system should define the criteria that will make the system acceptable. For example, the application system might be designed to provide a mean response time of three seconds. The system is then evaluated to determine whether the three-second-response time has been achieved. |
| Acceptance Test | An Acceptance Test is a script or set of scripts to test the criteria established during requirements definition. |
| Alpha Version | An Alpha Version is the first version of the software with code and content complete. No new code is added except in order to fix bugs. This version can be distributed internally to QC/Testers and Customer Acceptance Testers. |
| API | An Application Program Interface is a set of standard function calls, “hooks” and protocols that a program uses to communicate with the outside world, and usually is provided by the operating system, e.g., Win32 for Windows NT. Typical functions include sending e-mail, de-allocating memory, accessing a network, and reading keyboard input. APIs can range from simple (and easier to validate), such as saving a data file, to complex, such as provision of queues or stacks for interrupts and checking of buffer overflows. |
| Archive | The retention of records, artifacts, and memorabilia considered having long-term value to the business or institution. |
| Baseline Test | A test that that provides a benchmark against which other test results can be measured after programming changes have been made. |
| Benchmarks | Timed measures of various actions within a product. They consist of establishing a timed baseline and comparing the duration of these same actions after a set of features is code complete. |
| Beta Release | Stabilization phase release of the product intended for beta testing with no known active severity 1 or 2 bugs. QC/Testing and Customer Acceptance Testing have been completed before Beta Release. Special final release tests, like those performed on “Golden Master” disks, should be conducted on a Beta release before sending to Beta sites. |
| Black box testing | Testing which examines only the inputs and outputs of a process, without respect to the internal workings of the process. Theoretically it is possible to get correct results even though internal values of a process may be incorrect. |
| Build | At various times during product development, the code is compiled into a build. Builds may happen several times a day or there may be several days between builds. |
| Build Verification Test (BVT) | Quick, automated test run by Development on every build. The purpose of this script is to catch major breaks in the product executable. |
| Code Bug (Defect) | A code bug is any bug that required a rebuild of the code in order to fix it. See Severity section of the Test Plan for rating guidelines. |
| Code Complete | Exit criteria for the last testable unit in the Development Phase of each milestone. For the final milestone, all features and sub-features have been coded. No known coding should remain. Code additions or changes that occur after this point are only to fix bugs. Code complete also signifies that the product is visually frozen. |
| Communications Test | Testing to ensure that data proceeds from the source through any required modems, etc., and arrives correctly at its intended destination. |
| Content Bug (Defect) | A content bug is any bug that requires a rebuild of the content (text, graphics and audio) in order to fix it. See Severity for rating guidelines. |
| Content Complete | All content of the product has been added. Content includes all text, graphics and audio. Content changes that occur after this point are only to fix bugs. |
| Customer Acceptance Testing | Testing the complete functionality of a software system from the users’ point of view. Usually performed after the QA/QC Testing. Tests the users’ ability to interface with the system and to see that it meets their defined criteria. |
| Disk Building | The process by which the entire set of files created for a project is copied to sets of disks. There are a variety of quality assurance checks that must be addressed in this process. Often this process is automated. This currently applies to DATAlynx development. |
| Documentation Test | The review of accuracy and readability of the user manuals, including tutorials and on-line help text, and of the technical documentation for a system. |
| End-to-End Test | A test that allows a complete business scenario to be evaluated. |
| Entrance criteria | Conditions that must be met before a procedure or task can take place. |
| Exit criteria | Conditions that must be met for a procedure or task to be regarded as successful. |
| Final Version | The version released for production. |
| Golden Masters | The final sets of disks that are sent to Product Release Services for manufacturing. |
| Golden Release | Testing performs the following tests on the Golden Master disks before it is released to manufacturing (RTM): Check for missing files, Check for extra files, Proper date stamps, Binary comparison to source files, Setup, Basic functionality check. |
| Integration Test | An incremental series of tests of combinations or sub-assemblies of selected components in an overall system. Integration testing is incremental in that successively larger and more complex combinations of components are tested in sequence, proceeding from the unit level to eventually the full system test. The term integration test can also be used in a different way, to describe large-scale systems interface or interoperability testing. |
| Load Test | See: Stress Test. |
| Master Project Schedule | The big picture schedule that includes major milestones and review points of a project from start to finish. This schedule must be reconciled with activities across each functional group. |
| Milestone | A specific, measurable event that sharply defines a development stage reached by the product. The milestone definition must include specific identification of what the milestone is and acceptance criteria to determine if the milestone has been met. |
| Milestone Certification | During this stage, Testing runs all cases against the testable units delivered in the milestone. At the same time. Development continues to fix bugs to reach the goal of zero active bugs. Certification of the milestone depends on a final build that includes all bug fixes and no reactivated bugs. |
| Performance Testing | The purpose of performance testing is to measure performance under load. Performance is a weighted mix of throughput, response time and availability. The scope of performance testing may include volume testing and stress testing. |
| Quality Assurance | Assessment of a process or product according to established standards. Also, the group that develops, improves, and modifies Quality Assurance policies, processes and procedures with regard to test plans, test environments, test cases, defect tracking, change control, version control, requirements traceability, Customer Acceptance Testing support, sign-off, archiving, and acceptance criteria. |
| Quality Control/Testing | The group responsible for ensuring the following: written client/user requirements are clearly and completely defined; written design includes all the requirements; coded software includes all the user/client required functionality; application processing complies with the organization’s policies and procedures; secondary client/user needs have been included (security officer, database administrator, internal auditors, records retention, comptroller); system processes accounting information in accordance with generally accepted accounting procedures; application systems process information in accordance with governmental regulations. |
| Regression Test | Comprehensive re-tests of an entire system or of a major subsystem after a modification has been made. According to a study by Watts Humphrey, anywhere from 20% to 50% of systems changes introduce new defects, hence the need for regression testing. Uses pre-existing data to verify that pre-existing code is still functioning properly after changes or revisions have been made. This kind of testing is very important because changes often cause unintended results in other parts of the system. |
| Release Candidate (RCx) | A build release to Testing with no known showstopper bugs. After under going normal acceptance process, there must be no active Severity 1, 2, or 3 bugs. There must be no active Priority 1, 2, or 3 bugs. All files to be shipped (including readme.txt) are included in the release. No Severity 1 bugs are discovered within an additional time period (e.g., 6 - 8 hours) |
| Release Date | The date on which the completed set of product disks is released. All disk QA work is complete and functional group leads sign off on a product release document. |
| Simulated Work Environment | A “day in the life” of a typical user utilizing production files. A working model of a system. Used to refine requirements and designs and to perform early usability testing. |
| Stress Test | A stress test deliberately stresses a system by pushing it to and beyond its specified limits. The intent is to see whether the system can recover as specified. |
| System Test | Highest level of application functionality testing all aspects of a completely integrated system and its subsystems under all feasible conditions. It is the testing of all affected programs to ensure that they run correctly, that they relate to each other properly, and that the operating procedures and controls are adequate. Developers, operations personnel and project team members, perform it. |
| System Acceptance Test | See: System Test |
| Test Case | Defines a scenario/situation to be tested, the supporting environment (data, test tools, hardware, software, networks), and expected results. One or more test cases will exist per Test Script. |
| Test Plan (Specification) | A detailed accumulation by the tester of all the available information on a particular area of functionality. It includes the testing approach used to test each component and comments on any know limitations of the testing methods. The test plan defines testing objectives, criteria for successful completion of testing, test environment, overview of test cases, priority and sequence of test cases, test execution procedures, documentation requirements, and follow-through procedures. |
| Test Script | A test script is a family of test cases that are identical except for variations of the input data values. If using with an automated test tool, a test script is the actual recorded piece of functionality. |
| Test Release Document (TRD) | A document that accompanies the Testing Release and describes the functionality of the release. It also includes testing notes for all areas indicating the status of each component (test, don’t test, known unresolved bugs, etc.). |
| Test Release Procedures | Process by which Testing takes a build from Development and the requirements or checks that need to be done before a build is accepted. |
| Test Specification Document | The Test Specification Document is a detailed accumulation by the tester of all the available information on a particular area of functionality. It includes the testing approach used to test each component and comments on any known limitations of the testing methods. |
| Testable Unit | Comprised of one or more “Work Items” and refers to any piece of the software package that is testable. |
| Unit Test | The testing of each functional module of an integrated application performed by the programmer/developer. It ensures that the functional module works according to the requirements, design, and acceptance criteria. |
| Unit Test Script | A test script written by the programmer in preparation for unit testing or recording an automated test script. |
| Vision Statement | A vision document defines the broad scope and goals for the product. It may include analysis of market and competition: target audience; external product positioning; internal product vision and design goals for domestic and international versions; analysis of users, activities, and prioritization of activities; timing and version requirements. The vision should be obtained from Product Management. By having a vision statement synopsis in the test plan you ensure that all testers are aware of the project objectives. |
| Volume Test | A test of application functionality that utilizes a sizeable volume of transactions that has deliberately not been pre-selected nor filtered. |
| White box testing | Testing which examines both the inputs and outputs of a process, and the internal workings of the process itself. This is done by examining values Theoretically it is possible to get correct results even though internal values of a process may be incorrect |
| Wish List | There are two types of wish lists. One is obtained from the Help Desk, highlights features that are requested by users for inclusion in a new release of the product. The other is obtained from Program Management and Marketing during product design. This list generally includes desirable but lower priority features. If there is room in the development schedule, wish listed items could be added to the official development feature list. |
| Work Item | A scheduled task representing the lowest level granularity of work by development. |
| Zero Bug Release (ZBR) | A product build where there are no active bugs in the list older than (e.g., 36) hours and no blocking bugs in the list less than (e.g., 36) hours old. |