Software Testing and Quality Control

The Environment team is responsible for notifying QA when code deployment is complete, typically via email notification. This is the standard communication protocol - QA leads don't send deployment notifications, and personal noon notifications aren't the formal process.

QA must log off during software deployments because their active testing sessions can delay the deployment process (impacting upgrade timelines) and they risk testing outdated code once the deployment completes. Option B captures both critical reasons: time impact and version correctness.

Deciding when to stop testing depends on the specific risks, budget, and quality standards of the system under test. Running all planned tests or fixing all faults is often unrealistic or insufficient, and running out of time is a constraint rather than a logical stopping criterion.

Beta testing is performed by real customers at their own site after alpha testing is complete. This helps identify issues in real-world environments that might not appear in controlled testing conditions. Option A correctly defines beta testing as testing performed by customers at their own site, distinguishing it from alpha testing (at developer's site) and other testing types.

Acceptance testing evaluates whether the system meets business requirements and is ready for deployment. It's conducted from a business perspective rather than a purely technical fault-finding perspective. Option C is correct because acceptance testing focuses on business needs, while option A describes technical testing and option B is too broad.

Re-testing (or confirmation testing) specifically reruns failed test cases to verify that a previously identified defect has been successfully fixed. In contrast, regression testing is performed on unchanged parts of the software to ensure that recent modifications have not introduced unexpected side effects or new bugs.

Testing is fundamentally about finding defects in software, not about proving that it works or is defect-free. Option D correctly states that testing executes software to find defects, which is the standard definition in software engineering. Options A, B, and C are incorrect because they suggest testing proves perfection or functionality, which is impossible to guarantee.

AMRO (Account Management and Reconciliation Operations) database is the repository where BANs (Billing Account Numbers) required for testing are identified and stored based on project criteria. V21 DB and Reference DB serve different purposes in the testing infrastructure.

System Functional Testing begins during the Task phase in test execution, after Entry criteria are met and before Exit criteria evaluation. The Validate phase focuses on validation rather than functional testing execution.

The correct QA testing sequence is System Integration Testing (SIT) → QA → Performance Testing → User Acceptance Testing (UAT) → Operational Readiness. This order ensures systems are integrated before functional QA, performance is validated after functional correctness, and user acceptance precedes operational readiness.

In testing terminology, pests (defects or issues) are prioritized based on both blocked AND failed test cases. Blocked cases indicate testing cannot proceed, while failed cases indicate actual defects. Both metrics together help determine which issues need immediate attention.

Quality Assurance covers both new and existing applications - it's about ensuring quality across all software, not just new developments or just maintenance. QA activities include testing both newly implemented features and verifying existing functionalities continue to work correctly.

Under the ETVX (Entry, Task, Verification, Exit) process model, the actual action of reviewing the Functional Requirements Document (FRD) for completeness and correctness is classified as a Task. Entry criteria define prerequisites, Validation/Verification tests the output quality, and Exit criteria determine completion, making Task the correct phase.

Final Inspection (FI) is performed by the Quality Assurance Group (QAG), which is independent of the project team. This independence ensures objective assessment - it's not done by the project team itself (Within the Project) or entities outside the project (Outside the Project) in general terms.