CSTE Practice Questions

Quality Assurance (QA) is a comprehensive, process-oriented set of activities designed to prevent defects and ensure that development and maintenance processes are continuously improved. It encompasses the entire software development lifecycle, including defining standards, conducting audits, and establishing procedures. Software testing is a crucial activity within this broader QA framework. Testing is a product-oriented activity, often considered a form of Quality Control (QC), which focuses on finding defects in the software product. Therefore, testing is a subset of the complete QA process, serving to verify that the product meets the quality standards established by the QA framework.

A. This inverts the relationship. QA is the overarching framework that includes testing, not a component within the testing process.

B. These terms are distinct. QA is a proactive, process-focused discipline, while testing is a reactive, product-focused activity for defect detection.

D. This statement is illogical. QA is a continuous process that occurs throughout the lifecycle, not a phase that begins after testing is complete.

1. ISTQB® Certified Tester Foundation Level Syllabus (Version 2018 V3.1.1), Section 1.1.3, "Testing and Quality Assurance (QA)": "While testing and QA are related, they are not the same... Quality assurance is concerned with the proper execution of the entire process... Testing, a quality control (QC) activity, is mainly concerned with the product. Testing is one of the activities that ensures quality." This source explicitly states that testing is an activity within the broader QA context.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). In Chapter 16, "Software Quality Assurance," the authors describe SQA as an "umbrella activity" that is applied throughout the software process. This activity encompasses a multi-tiered testing strategy, clearly positioning testing as a component within the SQA framework (p. 451-452).

3. Sommerville, I. (2016). Software Engineering (10th ed.). In Chapter 24, "Quality Management," Sommerville distinguishes between quality assurance and quality control. He states, "Quality assurance is the definition of processes and standards that should lead to high-quality software... Quality control is the application of these processes to check the product and remove defects before delivery." Testing is presented as the primary quality control activity, thus placing it under the governance of the QA process (p. 718-719).

The test is being performed against a user requirement, focusing on the external behavior and functionality of the application—specifically, whether a field is populated by a dropdown box as specified. This method of testing, which evaluates the system's functionality without any knowledge of its internal code, structure, or implementation, is known as Black-Box Testing. The tester is concerned only with the inputs (selecting the dropdown) and the expected outputs (the field being populated from the list), treating the software as an opaque "black box."

B. Regression Testing: This is incorrect because the scenario does not describe re-testing existing functionality to ensure that recent changes have not introduced new defects.

C. White-Box Testing: This is incorrect because the test is based on user requirements, not on the internal logic, code paths, or structure of the software.

D. Load Testing: This is incorrect because the test is evaluating functional compliance, not the system's performance or behavior under a specific number of concurrent users.

1. Pressman, R. S., & Maxim, B. R. (2015). Software Engineering: A Practitioner's Approach (8th ed.). McGraw-Hill Education. In Chapter 22, Section 22.3.1, "Black-Box Testing," it is stated that this technique "focuses on the functional requirements of the software... Black-box tests are used to demonstrate that software functions are operational."

2. Jorgensen, P. C. (2013). Software Testing: A Craftsman's Approach (4th ed.). CRC Press. Chapter 1, Section 1.2, defines black-box testing as being based on a specification of the system's external behavior. The tester is only concerned with the system's functionality.

3. Koomen, T., & van der Aalst, L. (Eds.). (2006). TMap Next: For result-driven testing. UTN Publishers. In Chapter 6, "Test design: the techniques," black-box testing techniques are described as specification-based, deriving test cases from requirements documents without reference to the internal implementation.

4. IEEE. (1990). IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990). Section 3, Definitions. Black-box testing is defined as: "Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions."

The statement is correct. It articulates a fundamental principle of modern corporate governance and leadership assessment. Evaluating executive performance requires context. The appropriateness, effectiveness, and extent of leadership involvement are not absolute metrics; they are relative to the specific circumstances of the organization. Factors such as company size, industry sector, market position, and organizational complexity directly influence the challenges and expectations placed upon leadership. Therefore, any credible evaluation framework must be tailored to these contextual factors to provide a fair and meaningful assessment.

B. False: This is incorrect because it suggests a universal, one-size-fits-all standard for evaluating leadership, which contradicts established management principles like the Contingency Theory of Leadership.

1. OECD (2023), G20/OECD Principles of Corporate Governance, OECD Publishing, Paris. The principles, particularly in Chapter VI on "The responsibilities of the board," emphasize that the board's oversight and strategic guidance must be appropriate for the business. The commentary notes that the implementation of governance principles should be adapted to a company's size, complexity, and risk profile, which directly supports contextual evaluation of leadership. (See Chapter VI, Introduction, p. 55).

2. Fiedler, F. E. (1964). A Contingency Model of Leadership Effectiveness. In L. Berkowitz (Ed.), Advances in experimental social psychology (Vol. 1, pp. 149–190). Academic Press. This foundational academic work establishes that leadership effectiveness is contingent upon situational factors. It argues there is no single best style of leadership, and effectiveness depends on the context, which includes the nature of the organization (e.g., size and type of business). This directly supports the premise of the question. DOI: https://doi.org/10.1016/S0065-2601(08)60051-9

3. Donaldson, L. (2001). The Contingency Theory of Organizations. Sage Publications. This book provides a comprehensive overview of contingency theory, stating that organizational structures and, by extension, leadership approaches must align with contextual factors like size, technology, and environment to be effective. The evaluation of that effectiveness must therefore also be context-dependent. (See Chapter 2: "Size and Structure").

The statement provided in the question is an accurate definition of Quality Control (QC), not Quality Assurance (QA). Quality Assurance is a proactive, process-oriented set of activities focused on establishing and maintaining a framework of standards and procedures to prevent defects from occurring. In contrast, Quality Control is a reactive, product-oriented activity that involves inspecting, testing, and measuring a product to verify that it meets the specified quality standards and requirements. The process of "comparing product quality with applicable standards" and taking "action when nonconformance is detected" is the core function of Quality Control.

A. True: This is incorrect because the statement misattributes the definition of Quality Control to Quality Assurance. These are distinct, though related, disciplines within the overall quality management framework.

1. ISO 9000:2015, Quality management systems — Fundamentals and vocabulary.

Section 3.3.7 (Quality assurance) defines QA as the "part of quality management focused on providing confidence that quality requirements will be fulfilled." This emphasizes the proactive, confidence-building nature of QA.

Section 3.3.6 (Quality control) defines QC as the "part of quality management focused on fulfilling quality requirements." This aligns directly with the question's description of comparing a product to standards and acting on nonconformance.

2. Sommerville, I. (2016). Software Engineering (10th ed.). Pearson.

In Chapter 24, "Quality Management," Sommerville distinguishes the two: "Quality assurance is the establishment of a framework of organizational procedures and standards that lead to high-quality software... Quality control is concerned with defining the quality checks on the software and ensuring they are implemented by the software development team." (p. 710). This source clearly separates the process-oriented nature of QA from the product-checking function of QC.

3. IEEE Std 730-2014, IEEE Standard for Software Quality Assurance Processes.

The standard's abstract and introduction describe SQA as a "planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements." The focus is on the systematic processes that provide confidence, not the direct act of product comparison and defect detection itself.

The statement accurately defines a primary objective of risk analysis within the broader context of risk management. The core purpose is to provide management with the necessary data to make informed, cost-effective decisions about security. It involves identifying potential threats and vulnerabilities, assessing their potential impact (e.g., financial loss, reputational damage), and estimating their likelihood. This analysis enables a cost-benefit comparison between the expense of implementing a security control (protective measure) and the value of the risk reduction it provides. The goal is not to eliminate all risks, which is often impossible or financially impractical, but to reduce them to an acceptable level in an economically sensible manner.

B. False: This is incorrect. The principle of balancing the cost of controls against the impact of risks is a fundamental tenet of information security and IT risk management. Proceeding without this economic consideration would lead to inefficient allocation of resources, either by overspending on minor risks or under-protecting critical assets.

---

1. National Institute of Standards and Technology (NIST). (2012). Special Publication (SP) 800-30 Revision 1, Guide for Conducting Risk Assessments.

Section 2.1, Page 5: "The risk assessment is one of the foundational activities of a risk management process... Risk assessments are used to identify, estimate, and prioritize risk to organizational operations... This information is used to inform decision makers and support risk responses by providing a basis for making sound, risk-based decisions..." This directly supports the idea that analysis provides the basis for decisions, which in a business context are inherently economic.

Section 2.3.3, Page 14: Discusses risk response, stating that organizations can "implement risk-reducing controls or countermeasures." The selection of these controls is based on the analysis of their effectiveness and cost, which is the essence of striking an economic balance.

2. Peltier, T. R. (2010). Information Security Risk Analysis (3rd ed.). Auerbach Publications.

Chapter 1, Section: "What Is Risk Analysis?", Page 3: "The main objective of an information resources risk analysis is to help management make a proper and logical decision on the selection of safeguards to protect the assets of the organization... The process should help management strike an economic balance between the impact of a risk and the cost of the protective measure." This text, a standard academic and professional reference in the field, uses nearly identical wording to the question.

3. Carnegie Mellon University, Software Engineering Institute. (2003). OCTAVE®-S Implementation Guide, v1.0. CMU/SEI-2003-HDB-003.

Section 1.2, Page 3: The OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) method, a widely respected risk assessment framework, emphasizes that the process helps an organization "make decisions about the best way to manage its risks." The entire process is designed to prioritize resources and focus protection strategies where they are most needed and provide the most value, which is an application of the economic balance principle.

The statement is correct. The Function Point Analysis (FPA) methodology, as defined by the International Function Point Users Group (IFPUG), is a structured process involving distinct steps. The final function point count is derived from three primary components that are determined individually:

1. Unadjusted Function Point (UFP) Count: Calculated by identifying, classifying, and weighting five function types (data and transactional).

2. Value Adjustment Factor (VAF): Derived from assessing the degree of influence of 14 General System Characteristics (GSCs).

3. Adjusted Function Point (AFP) Count: The final calculation where the UFP is multiplied by the VAF.

Each of these components requires a separate and independent evaluation before the final result can be computed.

B. False: This is incorrect. The FPA process explicitly separates the counting of functional components (to get the UFP) from the assessment of system characteristics (to get the VAF). These are not determined concurrently or as a single composite value.

1. International Function Point Users Group (IFPUG). (2010). Function Point Counting Practices Manual (CPM), Release 4.3.1. In Part 2: "The Counting Process," the manual outlines the distinct steps for determining the Unadjusted Function Point count (Sections 2.3.3, 2.3.4, 2.3.5) and the Value Adjustment Factor (Section 2.3.6) before calculating the final Adjusted Function Point count (Section 2.3.7). This structure confirms the individual determination of each part.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. Chapter 26, "Estimation for Software Projects," describes the process of function point analysis. It details the computation of the unadjusted function point count based on information domain values and then separately explains the calculation of the value adjustment factor based on responses to 14 questions about general system characteristics (pp. 570-573).

3. Albrecht, A. J. (1979). "Measuring Application Development Productivity." Proceedings of the Joint SHARE/GUIDE/IBM Application Development Symposium, Monterey, California, October 14-17, 1979, pp. 83-92. The original paper introducing function points establishes this multi-part process. It first describes the method for counting and weighting the five function types and then introduces a separate step to adjust this count based on "processing complexity characteristics." This foundational document establishes the principle of individual determination.

Configuration Management (CM) is a formal engineering discipline that provides a structured process for establishing and maintaining the consistency of a product's attributes throughout its entire lifecycle. This scope is not limited to test artifacts. It encompasses all components, known as Configuration Items (CIs), including source code, design documents, requirements specifications, and hardware. Applying CM to non-test changes, such as a modification in the source code or an update to a requirement, is fundamental to ensuring traceability, controlling the evolution of the system, and maintaining the integrity of the final product.

B. False: This is incorrect. Limiting configuration management solely to test-related changes would defeat its core purpose. CM is essential for managing the entire system's baseline, including all development and documentation artifacts, to ensure a controlled and auditable product lifecycle.

1. IEEE Std 828-2012, "IEEE Standard for Configuration Management in Systems and Software Engineering."

Section 3.1.4, Configuration Item (CI): Defines a CI as an "aggregation of hardware, software, or both, that is designated for configuration management..." This definition is broad and not restricted to testware.

Annex A, SCM Plan Information: Provides examples of CIs which include "Software requirements specification," "Software design description," and "Source code," all of which are non-test items.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill.

Chapter 8, "Software Configuration Management": This chapter explicitly states that SCM is a set of activities designed to manage change throughout the software process. It identifies baselines that include not just test-related items but also specifications, design documents, and source code.

3. MIT OpenCourseWare, "6.170 Software Studio, Lecture 4: Configuration Management."

The course materials describe Configuration Management (using tools like Git) as a practice for managing the evolution of a software system's source code and related documents. The primary focus is on managing the codebase, which is a "non-test" artifact.

The statement provides an accurate definition of Mean Time Between Failures (MTBF). MTBF is a fundamental measure of reliability for repairable systems, representing the average elapsed time from the occurrence of one failure to the next. It is calculated by dividing the total operational time of the system by the number of failures observed during that period. This metric is crucial in software and systems engineering for predicting reliability and planning maintenance activities. The definition given in the question is the standard and widely accepted one in the field.

B. False: This option is incorrect. The provided statement is the standard, textbook definition of Mean Time Between Failles (MTBF) as established in reliability engineering principles and documented in official standards.

1. IEEE Computer Society. (1990). IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. New York, NY: Institute of Electrical and Electronics Engineers.

Reference: In the definitions section, MTBF is defined as "The expected or observed time between consecutive failures of a system." This directly validates the statement in the question.

2. Lyu, M. R. (Ed.). (1996). Handbook of Software Reliability Engineering. IEEE Computer Society Press & McGraw-Hill.

Reference: Chapter 2, "Basic Reliability Concepts," Section 2.2.1, "Time-Dependent Reliability Models," explains that for a repairable system, the time between failures is a random variable, and its expected value is the MTBF. This confirms the concept of it being an "average time."

3. Shooman, M. L. (2002). Reliability of Computer Systems and Networks: Fault Tolerance, Analysis, and Design. John Wiley & Sons.

Reference: Chapter 2, "Reliability and Availability Definitions," Section 2.2, defines MTBF for repairable systems as the average time between failures, calculated as the sum of Mean Time To Failure (MTTF) and Mean Time To Repair (MTTR). The question's phrasing, "time between consecutive failures," correctly encapsulates this entire cycle.

The process described is the definition of risk management, specifically the initial phases of risk identification and risk analysis. Risk management is a systematic discipline for identifying, analyzing, quantifying, and mitigating risks before they become problems. Identifying potential software failures is risk identification, while quantifying their likelihood of occurrence is a core component of risk analysis. These activities are fundamental to proactively managing potential negative outcomes in a software project.

A. Configuration Management: This process focuses on controlling and managing changes to software artifacts, such as code and documentation, not on identifying potential failures.

B. Contingency Planning: This is a component of risk management that deals with creating a plan for what to do after a risk materializes, not the initial identification and quantification.

D. Process Improvement: This involves analyzing and enhancing the software development lifecycle processes themselves, rather than identifying and managing specific product or project risks.

1. Bourque, P., & Fairley, R. E. (Eds.). (2014). Guide to the Software Engineering Body of Knowledge (SWEBOK), Version 3.0. IEEE Computer Society. ISO/IEC TR 19759:2015.

Reference: In Chapter 8, "Software Engineering Management," Section 4.2, "Risk Management Process," states that the process begins with "risk identification" (identifying potential risks) and "risk analysis" (evaluating the likelihood and impact of risks). The question directly describes these two activities.

2. Boehm, B. W. (1991). Software Risk Management: Principles and Practices. IEEE Software, 8(1), 32–41.

Reference: On page 34, Figure 1 outlines the major steps in software risk management. The first step, "Risk Assessment," is broken down into "Risk identification," "Risk analysis," and "Risk prioritization," which perfectly aligns with the activities described in the question. (DOI: https://doi.org/10.1109/52.62930)

3. Massachusetts Institute of Technology (MIT) OpenCourseWare. (2005). 16.355J Software Engineering Concepts, Fall 2005.

Reference: In the lecture notes for "Lecture 5: Risk Management," the process is defined as including "Risk Identification - What can go wrong?" and "Risk Analysis - What is the likelihood and impact of each risk?" This directly supports that the question is describing risk management.

An inspection is a formal, static evaluation technique used in software engineering to find defects. The core of this process involves a team of peers meticulously examining a work product, such as a requirements document, design specification, or source code. This examination is primarily a visual and cognitive activity where participants read and analyze the material, often against a set of standards and checklists, to identify errors, omissions, and deviations. Since the work product is not executed, the technique fundamentally relies on this visual scrutiny to achieve its objective of early defect detection.

B. False: This is incorrect. The primary mechanism of an inspection is the visual and analytical examination of a static work product by human reviewers.

1. IEEE Std 1028-2008, "IEEE Standard for Software Reviews and Audits." Section 5, "Inspection," describes the process as a formal evaluation technique involving detailed examination of a work product by a group of peers. The activities of "Preparation" (5.4.3) and "Examination" (5.4.4) explicitly detail the individual and group-based visual review of the material to find anomalies.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. Chapter 20, "Software Quality Assurance," describes inspections as a formal technical review. The text states, "The intent [of an inspection] is to identify errors in content or logic... The review itself is a stylized meeting in which a reviewer 'walks through' the work product." This walkthrough is a form of guided visual examination.

3. Sommerville, I. (2016). Software Engineering (10th ed.). Pearson. Chapter 8, "Software Testing," section 8.1.2, "Inspections and testing," defines inspections as a static verification process involving "people examining the source representation with the aim of discovering anomalies and defects." This examination is a visual and analytical process.