set-3

Answer: 4. All of the above

Explanation:

• White box testing techniques include statement coverage (testing every statement), decision coverage (testing every decision point), and data flow testing (testing the flow of data through the program). All these techniques focus on the internal structure of the code.

Answer: 2. Developer’s end

Explanation:

• Alpha testing is performed at the developer’s end in a controlled environment before the software is released to external users. It is an early stage of testing to identify major issues.

Answer: 3. Incident reports

Explanation:

• Incident reports are not part of the test plan. The test plan includes the schedule, risk occurrence, and entry/exit criteria, which define the scope and approach of testing.

Answer: 2. Interface Errors

Explanation:

• The key objective of integration testing is to identify interface errors between different modules or components of the system. It ensures that the integrated components work together as expected.

Answer: 1. Experience-based Test Design Technique

Explanation:

• Exploratory testing is an experience-based testing technique where testers explore the application without predefined test cases. It relies on the tester’s knowledge, intuition, and creativity to identify defects.

Answer: 2. Structural testing

Explanation:

• White box testing techniques are also known as structural testing because they focus on the internal structure of the code, such as control flow, data flow, and logic.

Answer: 4. All of the mentioned

Explanation:

• White box testing techniques include basis path testing (testing all possible paths), decision tree testing (testing decision points), and condition coverage (testing all conditions). All these techniques focus on the internal logic of the code.

Answer: 3. Unit testing

Explanation:

• Unit testing is performed by developers to test individual components or units of code. It ensures that each unit functions correctly in isolation before integration with other components.

Answer: 4. The risk are resolved

Explanation:

• Testing is typically stopped when the risks associated with the software have been resolved, and the software meets the required quality standards. Fixing faults and running all tests are part of the process, but the ultimate goal is risk mitigation.

Answer: 3. ISO

Explanation:

• ISO (International Organization for Standardization) is a globally recognized standard for various industries, including software testing. ISO standards ensure quality and consistency in testing processes.

Answer: 4. Static testing

Explanation:

• Static testing is performed first, as it involves reviewing documents, code, and designs without executing the software. It helps identify defects early in the development process.

Answer: 2. White box testing

Explanation:

• White box testing involves checking the internal code of the program. It focuses on the structure, logic, and flow of the code to ensure it functions as intended.

Answer: 3. Adhoc testing

Explanation:

• Adhoc testing is performed without formal planning or documentation. It is an informal testing approach where testers explore the application to find defects based on their intuition and experience.

Answer: 4. Beta testing

Explanation:

• Acceptance testing is also known as beta testing when it is performed by end-users in a real-world environment. It ensures that the software meets the user’s requirements and is ready for deployment.

Answer: 2. Performance testing

Explanation:

• Performance testing is a type of non-functional testing that evaluates how the system performs under various conditions, such as load, stress, and scalability. It focuses on system behavior rather than functionality.

Answer: 2. Boundary value analysis, Equivalence partitioning

Explanation:

• Boundary value analysis and equivalence partitioning are black box testing techniques. They focus on input values and their impact on the system’s behavior without considering the internal code structure.

Answer: 4. Both option A & C

Explanation:

• Regression testing should be performed after the software has been modified or when the environment has been modified. This ensures that the changes have not introduced new defects or broken existing functionality.

Answer: 3. The testing team is not good

Explanation:

• It is nearly impossible to deliver a 100% bug-free product due to the complexity of software systems. However, a good testing team can significantly reduce the number of defects and improve software quality.

Answer: 4. Test Plan

Explanation:

• The Test Plan document defines the exit criteria for testing, which specify the conditions that must be met for testing to be considered complete. It outlines the scope, approach, and objectives of testing.

Answer: 1. Big bang approach

Explanation:

• The big bang approach is not an incremental testing approach. Incremental testing involves testing components in small increments, such as top-down, bottom-up, or functional incrementation.

Answer: 2. It is based on the nature of the project

Explanation:

• The order of test levels (unit, integration, system, acceptance) can vary based on the nature of the project. The specific sequence depends on the project’s requirements and development approach.

Answer: 1. White-box testing

Explanation:

• Component testing, also known as unit testing, is a type of white-box testing where individual components or units of code are tested in isolation. It focuses on the internal structure and logic of the code.

Answer: 4. 3.4 million per million lines of code.

Explanation:

• Six Sigma aims for a defect rate of 3.4 defects per million opportunities. This is a measure of process quality and indicates a high level of consistency and reliability.

Answer: 3. Both A and B

Explanation:

• Defect Removal Efficiency (DRE) is calculated based on the number of errors found before software delivery (E) and defects found after delivery to the user (D). It measures the effectiveness of the testing process in identifying and removing defects.

Answer: 4. All of the above

Explanation:

• Quality, complexity, and reliability are indirect measures of a product. They are not directly measurable but are inferred from other metrics and observations.

Answer: 1. Efficiency

Explanation:

• Efficiency is not a direct measure of the software engineering process. It is a derived metric that depends on other factors like time, cost, and effort. Direct measures include applied effort, investment, and benefits.

Answer: 2. FP = count total * [0.65 + 0.01 * sum(Fi)]

Explanation:

• The Function Point (FP) computation formula is given by:
  $FP = \text{count total} \times [0.65 + 0.01 \times \sum(Fi)]$
  where ( Fi ) represents the complexity adjustment factors.

Answer: 3. Software Maturity Index

Explanation:

• SMI stands for Software Maturity Index, which is a metric used to measure the stability and maturity of a software product over time.

Answer: 4. Minimization of development schedule and assessing project quality on ongoing basis

Explanation:

• Project metrics are used to minimize the development schedule and assess project quality on an ongoing basis. They provide insights into the progress and health of the project.

Answer: 4. All of the Mentioned

Explanation:

• Quality, complexity, and reliability are indirect measures of a product. They are inferred from other metrics and observations rather than being directly measurable.

Answer: 3. Number of lines of code

Explanation:

• Size-oriented metrics are based on the number of lines of code (LOC). This metric is used to estimate the size and complexity of the software.

Answer: 4. Number of errors

Explanation:

• The number of errors is not part of the information domain required for determining function points in Function Point Analysis (FPA). The information domain includes user requirements, user involvement, and external interfaces.

Answer: 1. Product Metrics

Explanation:

• Size and complexity are part of product metrics, which focus on the characteristics of the software product itself, such as its size, complexity, and quality.

Answer: 3. Metric

Explanation:

• The number of errors found per person-hours expended is an example of a metric. It quantifies the efficiency of the testing process in terms of defect detection.

Answer: 4. All of the mentioned

Explanation:

• Software delivery delays can occur due to changing customer requirements, technical difficulties, and unforeseen human challenges. All these factors can impact the project timeline.

Answer: 2. Software Project scheduling

Explanation:

• Software Project scheduling involves distributing the estimated effort across the project duration and allocating it to specific tasks. It ensures that the project is completed on time and within budget.

Answer: 3. Defined responsibilities

Explanation:

• Assigning every scheduled task to a specific team member is termed as defined responsibilities. It ensures accountability and clarity in task ownership.

Answer: 1. 40-20-40

Explanation:

• The recommended distribution of effort for a project is 40% for analysis and design, 20% for coding, and 40% for testing and maintenance. This ensures a balanced approach to software development.

Answer: 3. Estimation by analogy

Explanation:

• Estimation by analogy is a technique used when other projects in the same application domain have been completed. It involves comparing the current project with similar past projects to estimate effort, cost, and duration.

Answer: 1. True

Explanation:

• The COCOMO (Constructive Cost Model) takes into account different approaches to software development, including reuse, complexity, and team experience. It is a widely used model for estimating software development effort.

Answer: 1. Algorithmic cost modelling

Explanation:

• Algorithmic cost modeling uses historical cost information and software metrics (e.g., lines of code, function points) to estimate project costs. It provides a quantitative approach to cost estimation.

Answer: 4. Both FP-Based Estimation and COCOMO

Explanation:

• Both FP-Based Estimation (Function Point Analysis) and COCOMO (Constructive Cost Model) use empirically derived formulas to predict effort as a function of LOC (Lines of Code) or FP (Function Points).

Answer: 1. Constructive cost model

Explanation:

• COCOMO stands for Constructive Cost Model. It is a widely used model for estimating the cost, effort, and schedule of software development projects.

Answer: 1. Early design stage model

Explanation:

• The Early Design Stage Model of COCOMO is used when the requirements have been stabilized, and the basic software architecture has been established. It provides initial estimates for effort and cost.

Answer: 3. Application composition model

Explanation:

• The Application Composition Model was used during the early stages of software engineering when prototyping user interfaces, assessing performance, and evaluating technology maturity were critical. It focuses on rapid application development.

Answer: 4. Cyclomatic Complexity

Explanation:

• Cyclomatic Complexity is a measure of the complexity of the control flow in a program, not a size measure. Size measures include LOC (Lines of Code), Halstead’s program length, and Function Count.

Answer: 3. B.W.Bohein

Explanation:

• COCOMO (Constructive Cost Model) was initially developed by Barry W. Boehm. It is a widely used model for estimating software development effort and cost.

Answer: 4. None of the mentioned

Explanation:

• Failure costs include rework, repair, and failure mode analysis. These are costs incurred due to defects or failures in the software.

Answer: 2. Software

Explanation:

• Software requirements are the foundation from which quality is measured. They define what the software should do and how it should perform, serving as the basis for quality assurance.

Answer: 2. Amount of technical work

Explanation:

• The amount of technical work is not part of the Software Quality Assurance (SQA) plan. The SQA plan includes evaluations, audits, reviews, and documentation to ensure quality.