Software Testing Fundamentals

A driver is a test harness or program that calls the function under test and passes it test data. Conversely, a stub is a dummy implementation called by the function under test to simulate missing dependencies.

Testing should ideally start during the requirement gathering phase through test planning activities. Early testing involvement helps identify testable requirements and prevents defects from being designed into the system.

Among these options, Sahi is not developed by TCS. SCEGEN, Testify, and Masketeer are TCS-developed testing tools. Sahi is an open-source automation tool originally developed by Sahi Labs.

Verification is the process of evaluating work products to ensure that the software is being built correctly according to specifications ('building the system right'). Validation ensures we built the correct system ('building the right system').

Regression testing is performed to ensure that changes or bug fixes have not introduced new defects in unchanged areas of the software. It does not have to be automated, and it is not restricted to user acceptance testing.

A failure is a departure from specified behavior - the system doesn't behave as documented in requirements. This is distinct from an error (human mistake) or defect (code issue).

Philip Crosby defined quality as 'conformance to requirements'. While 'zero defects' is a related goal, 'conformance to requirements' is the most widely accepted formal definition of quality in software engineering and project management.

Software testing provides confidence to stakeholders that the software meets requirements and is suitable for use. It cannot guarantee zero defects or complete bug-freeness, but it reduces risk and builds trust.

Functional system testing tests the end-to-end functionality of the system as a whole, verifying that the complete system works correctly for user scenarios. It's not about integration (component interaction) or interoperability (system-to-system).

UAT stands for User Acceptance Testing, which is the phase of software development where actual users test the software to ensure it can handle real-world tasks. The other options are incorrect variations of the acronym.

Without a specified expected result, it's difficult to determine if a test passed or failed. The test outcome is judged against expectations, so missing expected results makes the test inconclusive.

Software testing typically accounts for 40-50% of software development costs according to industry studies. This reflects the significant effort required for quality assurance activities throughout the development lifecycle.

Testing is considered a failure when a program does not work correctly because its primary purpose is to verify that software functions as intended. When tests reveal defects or incorrect behavior, the testing process has identified a failure in the software development process.

Alpha testing is performed by internal staff before public release, while Beta testing involves external end-users who test the software in real-world conditions. Both methods allow actual users to evaluate the software before final deployment, making Alpha and Beta testing the correct answer.

A driver is a test harness or program that calls the function under test and passes it test data. Conversely, a stub is a dummy implementation called by the function under test to simulate missing dependencies.

Testing should begin as early as the requirement gathering phase to identify issues before they become expensive to fix. Early testing allows for validation of requirements and design decisions, reducing the cost of changes compared to discovering defects in later stages like development or integration.

Verification is the process of evaluating work products to ensure that the software is being built correctly according to specifications ('building the system right'). Validation ensures we built the correct system ('building the right system').

Regression testing verifies that recent changes have not adversely affected existing functionality. It focuses on ensuring that unchanged areas of the software continue to work correctly after modifications, helping prevent the introduction of new defects while fixing existing ones.

An expected result defines what should happen during a test, providing a baseline to determine success or failure. Without specifying expected results, it becomes impossible to evaluate whether the actual outcome matches the intended behavior, making pass/fail determination difficult or impossible.