Software Testing and QA Fundamentals

Once an FRD (Functional Requirements Document) is baselined, it becomes a controlled document. Any modifications require a formal change control process to maintain traceability and ensure all stakeholders review and approve changes. Project Change Request is the standard mechanism for this.

Project criticality is classified into levels: Low, Medium, and High. The question asks what it's determined by, and all three are valid classifications of criticality. Different projects can have different criticality levels based on their impact, risk, and importance to the organization.

Project deliverables must pass multiple quality gates: Internal Quality Assurance (IQA within the project team), External Quality Assurance (EQA by independent QA), and Final Inspection (FI for final sign-off). This multi-layer approach ensures thorough quality control before delivery.

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.

The Test Plan is created by the QA Prime, who is the lead QA professional responsible for the project's testing strategy. The QA Manager oversees multiple projects, while QA Analysts and Testers execute the plans created by the QA Prime.

QA deliverables typically include test strategy, test plans, and test summary reports. Project closure documents and induction manuals can also be part of QA deliverables in some organizations as they document the testing outcomes and help transition knowledge. Therefore, all the options listed are valid QA deliverables.

Field testing is performed by users at their own client locations, allowing testing in real-world environments where the software will actually be used.

System testing must investigate both functional requirements (what the system does) and non-functional requirements (how the system performs, like speed, usability, security).

Non-functional testing tests system attributes like performance, speed, scalability, usability, and security rather than specific functional behaviors.

The Scribe is the designated person responsible for documenting all issues, problems, and open points identified during a review meeting, ensuring accurate record-keeping.

Informal reviews provide an inexpensive way to get some benefit from peer review without formal processes, allowing teams to quickly share knowledge and catch obvious issues.

Test design techniques serve two purposes: identifying test conditions (situations to test) and identifying specific test cases (concrete tests with inputs and expected outputs).

Equivalence partitioning divides input data into groups (partitions) that are expected to be processed similarly, allowing you to achieve coverage by testing one value from each partition.

Use cases describe how users interact with a system to achieve goals, making them ideal for testing business scenarios and end-to-end workflows.

Alpha testing is conducted at the developer's site by internal teams before release to external users. Beta testing, by contrast, happens at the customer's site. Unit and integration testing are development activities, not defined by location.

Exit criteria define when testing should stop, mark the end of a test level, and indicate that a set of tests has met predefined conditions. All three statements are true, so the 'All of the above' option correctly captures the purpose.

HP Quality Center 9.2 includes Requirements, Test Plan, Test Lab, and Defects modules as core functionality, plus Dashboard/Analysis module. The exact count varies by documentation, but 5 modules is the commonly accepted answer for this version.

In the Test Lab module, parameter values can be viewed both at the test case design level and at the test instance execution level. These two views show different aspects - design-time default parameters versus run-time actual parameter values used during execution.

Requirement Flow is not part of the Requirement module; the module includes trees, grids, and detailed views but does not model execution flow. The other options are genuine components of the module, so they are incorrect choices.

The Graph Wizard is not universally available across all Quality Center modules. It's primarily accessible in the Dashboard module and certain views within other modules, but not throughout every module. The Test Lab and Requirements modules have limited or no graph wizard access compared to Dashboard.