Software Testing and Quality Control

In disconnected mode, the Mobile Web Client uses a local web server with SWSE (Siebel Web Server Extension) to deliver HTML to the browser. HTML pages are generated locally from templates and data stored on the device, not from a web cache or requiring immediate synchronization.

The Siebel Web Engine processes incoming requests by retrieving appropriate templates, fetching required data from the Siebel database, and constructing HTML pages. Display happens on the client, load balancing is handled by the SWSE/gateway, and browser verification is a separate function.

When a user enters a Siebel application URL, the Web Server first receives the HTTP request. The Web Server recognizes Siebel URLs and passes them to the Siebel Web Engine (SWE), which then retrieves data from the database and constructs the HTML page using appropriate templates. This separation allows the Web Server to handle static content while the SWE processes dynamic Siebel-specific requests.

The Siebel Web Server extends a third-party web server with three key components: SWSE (Siebel Web Server Extension) which acts as the plug-in interface, eapps.cfg which contains application configuration settings, and a Virtual Directory that maps web requests to Siebel resources. SWE (Siebel Web Engine) is a separate component that runs on application servers, not the web server tier. The Name Server is a completely separate service for enterprise connectivity.

The ListBox's SelectedIndexChanged event only fires automatically when the selection changes if AutoPostBack is set to True. When False (the default), the event only fires during the next postback from another control. Option A refers to automatic event wireup which is unrelated to postback timing. Option C has a typo but codebehind compilation issues would prevent all events.

Verification is the process of checking that we are building the system right - that is, ensuring the system is being built correctly according to specifications and requirements. Validation (option A) is checking that we're building the right system - that it meets user needs. Option C describes a specific organizational approach, not the definition. Option D describes validation, not verification.

Static testing techniques involve examining code and documentation without running the software. Walkthroughs, data flow analysis, and inspections are all static testing techniques. Error guessing is a dynamic testing technique where testers guess likely error conditions based on experience - it requires executing the software.

Identifying and resolving faults during the planning phase is highly cost-effective because requirements and design issues can be corrected before code is written. Fixing defects in later stages like design, execution, or exit criteria review requires significantly more time, effort, and resources.

The test plan is primarily derived from the project plan, which contains scope, schedule, resources, and risk information needed for test planning. Business plans focus on financial/projection aspects. Support plans are for maintenance. The project plan provides the foundational information for developing an appropriate test strategy.

A Function/Test Matrix (also called a Traceability Matrix) maps test cases to requirements or functions. In many project management and testing frameworks, this matrix serves as a project status report showing coverage progress. The other options are specific report types, while the matrix is a broader status tracking tool.

Software testing typically accounts for 40-50% of total software development costs according to many industry estimates. This includes test planning, design, execution, and maintenance of test artifacts. Option D '40308' is clearly a data entry or OCR error.

Regression testing is performed specifically to verify that modifications, bug fixes, or updates in one part of the code have not adversely affected existing, unchanged features. It does not focus on testing new changes directly, nor is it restricted to automation or UAT.

The statement 'Component testing does not involve regression testing' is false. Component testing absolutely includes regression testing to ensure that changes or fixes to a component don't introduce new defects. The other statements are generally true: component testing is often done by developers, is also called module/isolation testing, and should have planned completion criteria.

Equivalence partitioning is a black box testing technique that divides input data into valid and invalid classes (partitions). It's appropriate for all testing levels - unit, integration, system, and acceptance testing. It's not restricted to developers, system testing, or white box techniques.

Test prioritization is primarily about making the best use of limited time. By prioritizing, you ensure the most critical tests are executed first, maximizing value within the available time window. It's not necessarily about shortening time, finding more faults inherently, or just being more effective - it's about optimization under constraint.