Software Testing Fundamentals

A tester's primary responsibility is to identify defects in the software. While testers may do some coding for test automation, that's not their core role. 'Checking whether software works correctly' is part of testing but is less precise than 'identify defects' which captures both finding and documenting issues.

Test status should be updated daily to maintain visibility into testing progress and enable timely decision-making. Weekly or longer intervals would cause significant delays in defect tracking and project reporting. Daily updates are standard practice in agile methodologies.

Finding a defect is only the first step; a tester must ensure it gets documented, reported, and tracked to resolution. Leaving defects without follow-through undermines the entire testing process. The QA lifecycle requires closure - identified issues must be communicated and verified as fixed.

A tester must actively follow up on reported defects - checking status, retesting after fixes, and verifying closure. Sitting idle contradicts the tester's accountability for quality. 'Chasing' ensures defects don't fall through the cracks and development teams address them.

Testing should be structured and based on predefined test cases to ensure coverage, repeatability, and traceability. Adhoc testing is unreliable and doesn't provide documented evidence. Even when using experience, you should follow documented test steps to maintain process discipline.

Linking a failed test case to its associated defect creates essential traceability - you need to know which test failed for which defect. This connection is crucial for retesting (verifying the fix) and for impact analysis. Without this link, you can't verify that the defect resolution actually addresses the test failure.

UAT stands for User Acceptance Testing, the final testing phase where actual users validate software against business requirements before production release. Option A incorrectly says 'Acceptable' instead of 'Acceptance'. Options C and D are made-up terms. UAT confirms the software meets user needs and is ready for deployment.

Customers typically only see Acceptance Testing, which validates the product against their requirements before acceptance. Unit, re‑testing, and systems testing occur earlier in the development cycle and are not presented to the customer as a final deliverable.

User Acceptance Testing (UAT) is conducted in an environment that mirrors the customer's actual production setup, using realistic data and configuration. This validates that the software works correctly in the customer's specific context. Regression (A) checks for unintended side effects after changes. Unit testing (C) tests individual code components. Re-testing (D) verifies specific bug fixes.

Beta testing is conducted at customer sites by actual end-users in real-world environments, making it the testing type commonly performed at the customer's location. Alpha testing (B) happens at the developer's site by internal teams. Re-testing (C) is targeted verification of bug fixes. Acceptance testing (D) is formal validation but often done in controlled environments, not necessarily at customer sites.

Beta testing is performed by actual customers or end-users in their production environments to validate software meets real-world needs before general release. Managers (B) typically oversee testing but don't conduct it. Salesmen (C) demonstrate but don't test. Support technicians (D) may assist but aren't primary beta testers.

Top-down, Sandwich, and Bottom-up are all recognized integration testing strategies. 'Big-banger' is not a valid testing approach; the correct term is 'Big Bang' integration testing, where all components are integrated simultaneously. The typo in option D makes it the incorrect option.

Error Guessing is an informal test design technique where testers use their experience to guess where defects might exist. It supplements formal testing methods (like equivalence partitioning or boundary value analysis) by providing additional test ideas based on intuition and past defect patterns. It is not limited to any specific testing level or phase.

A failure is the deviation of the component or system from its expected delivery, service, or result. It occurs when a defect (fault) executes during runtime and causes the actual behavior to differ from the specified/expected behavior visible to end users. Error is a human mistake, defect is the manifestation in code, failure is the observable incorrect behavior.

Testing stops based on risk criteria and completion criteria, not arbitrary constraints like time or executing all planned tests. The decision depends on the acceptable level of residual risk for the system under test. Even after planned tests complete, you may continue testing if residual risk is unacceptable, or stop early if risk is sufficiently mitigated.

Exhaustive testing (testing all possible input combinations and preconditions) is impractical because the number of possible test cases is infinite or astronomically large. With even simple inputs, the combinatorial explosion makes it impossible to test everything within reasonable timeframes. This is why we use risk-based testing, sampling, and test design techniques.