CSQA Practice Questions

ISO/IEC process-assessment standards (ISO/IEC 15504 and its successor ISO/IEC 33020) state that a capability level n is achieved when:

1. Every process attribute (PA) at level n is rated at least “Largely achieved” (≥ 50 %); and

2. Every PA of all lower capability levels (1…n-1) is rated “Fully achieved” (≥ 85 %).

Thus, the standard does not require all PAs at the target level to be “Fully achieved”; “Largely achieved” is sufficient. Therefore the assertion that a capability level is established only when all PAs are fully achieved is incorrect.

Why the other option is wrong:

• True – Incorrect because it ignores the ISO rule that allows a “Largely achieved” rating for the PAs of the level being claimed; only lower-level PAs must be “Fully achieved.”

1. ISO/IEC 15504-2:2003, Clause 4.5.4 “Determination of process capability level”, pp. 18-19.

2. ISO/IEC 33020:2015, Clause 7.3.2 “Criteria for capability level rating”, p. 16.

3. García, F. et al., “An Overview of ISO/IEC 15504 (SPICE)”, Software Quality Journal, 2004, Section 3.2, DOI: 10.1023/B:SQJO.0000013324.00459.a7.

4. University of Oulu, Course “Software Process Improvement”, Lecture 6, slide 19 (2021).

Quality Function Deployment (QFD) is a structured methodology that uses a series of matrices, starting with the "House of Quality," to translate customer requirements (the "Voice of the Customer") into technical design characteristics. This process continues by cascading these technical characteristics into part characteristics, process plans, and finally, production controls. This systematic and documented linkage at each stage creates an explicit and verifiable trail. This trail allows stakeholders to trace a customer requirement forward to its specific implementation details (forward traceability) and to trace a technical feature or process step backward to the original customer need it was designed to satisfy (backward traceability). Therefore, QFD inherently provides a mechanism for tracing value throughout the development lifecycle.

The alternative option, "False," is incorrect. The fundamental purpose and mechanism of the QFD process are to create and maintain a clear, documented connection between customer-defined value and the technical solutions implemented to deliver that value. To suggest QFD cannot be used for traceability would be to misunderstand its core function.

1. QAI Global Institute, Certified Software Quality Analyst (CSQA) Body of Knowledge, Version 2018.

Section: Skill Category 4: Quality Leadership, Part C: Quality Improvement Processes.

Reference: The CSQA Body of Knowledge describes QFD as a method for "translating customer wants and needs... into engineering characteristics." It emphasizes the use of matrices to "flow down" these requirements through design, parts deployment, process planning, and production. This "flow down" or cascading process is the foundation of traceability, creating a direct link from the initial customer input to the final product characteristic.

2. Cohen, L. (1995). Quality Function Deployment: How to Make QFD Work for You. Addison-Wesley.

Chapter 2: The QFD Process, pp. 25-28.

Reference: This foundational text on QFD explains the "four-phase" approach, where the "hows" from one matrix become the "whats" of the next. This cascading of matrices (Product Planning -> Part Deployment -> Process Planning -> Production Planning) creates a direct, traceable link from the initial customer voice to the shop floor instructions, explicitly enabling both forward and backward traceability.

3. Akao, Y. (Ed.). (1990). Quality Function Deployment: Integrating Customer Requirements into Product Design. Productivity Press.

Chapter 1: The History and Development of Quality Function Deployment, pp. 12-15.

Reference: As one of the originators of QFD, Akao explains that the "quality chart" (a precursor to the House of Quality) and its subsequent deployment tables are designed to ensure that "customer-required quality is deployed into the design quality for each functional component... and then to the quality of each part and process." This documented deployment is the essence of traceability.

The statement is incorrect because it proposes the wrong solution for the stated problem. When a process is operating outside customer specifications due to common causes of variation, it means the process is stable and in statistical control, but its inherent, natural variation is too wide to meet the requirements. This is a problem of process capability. To resolve this, management must make a fundamental change to the process itself—such as implementing new technology, using better materials, or redesigning the workflow—to reduce the inherent (common cause) variation.

Reducing special causes of variation is the correct action when a process is unstable or "out of control." This action brings the process into a stable, predictable state but does not change its inherent capability. Therefore, addressing special causes will not fix a process that is already stable but incapable of meeting specifications due to its common cause variation.

The "True" option is incorrect because it fundamentally misunderstands the principles of Statistical Process Control (SPC). It incorrectly prescribes the remedy for an unstable process (reducing special causes) to a problem of an incapable but stable process (excessive common cause variation).

1. Montgomery, D. C. (2013). Introduction to Statistical Quality Control (7th ed.). John Wiley & Sons.

Section 4.2, "Control Charts and Process Capability": Montgomery distinguishes between a process being in a state of statistical control and its capability to meet specifications. He states, "A process may be in statistical control, yet its natural variability... may be so large that a high percentage of the output fails to conform to specifications. This is a problem of process capability." (Paraphrased from concepts in Chapter 4). He further explains that improving capability requires fundamental changes to the process, which addresses common cause variation.

2. MIT OpenCourseWare. (2004). 16.842 Fundamentals of Systems Engineering, Fall 2004. Massachusetts Institute of Technology.

Lecture 5: Statistics and Quality Control, Slide 16 ("Deming’s Principles"): The lecture notes explain W. Edwards Deming's concepts. It is stated that special causes are "assignable to a specific event or person" and are "correctable locally." In contrast, common causes are "inherent in the system" and require "management action to correct." The question describes a problem inherent in the system (common causes), which requires management action to change the system, not the local correction of special causes.

3. Wheeler, D. J. (2000). Understanding Variation: The Key to Managing Chaos (2nd ed.). SPC Press.

Chapter 2, "The Two Types of Variation": Wheeler explains that confusing common causes and special causes is a critical management error. He states, "Treating common causes as if they were special causes will only make things worse... To reduce common-cause variation, one must make a fundamental change in the system." The question proposes exactly this error: treating a common cause problem as if it could be solved by addressing special causes.

4. Smith, G. T. (2000). Statistical process control for monitoring and improving project quality. Project Management Journal, 31(2), 29-39.

Page 32, "Process Capability": The article clarifies the appropriate actions. "If the process is in control but not capable of meeting the specifications, management must change the process. This may mean a new machine, a new raw material supplier, or retraining the operators. If the process is out of control, the project manager must find the special cause of variation and remove it." This directly refutes the premise of the question. (DOI not available for this older publication, but it is a widely cited peer-reviewed article in the domain).

This statement is a fundamental principle in quality management, innovation, and organizational change. In the context of a Certified Software Quality Analyst (CSQA), identifying a potential improvement, a new test strategy, or a more efficient process is only the first step. The tangible value of such an "idea" is only realized after it has been successfully communicated to, and accepted by, stakeholders (e.g., management, development teams) and is subsequently implemented. An unimplemented idea, no matter how brilliant, does not improve product quality, reduce costs, or increase efficiency; it remains a concept with no practical impact. The CSQA Body of Knowledge (BOK) places significant emphasis on interpersonal and leadership skills specifically to enable analysts to champion their ideas through to implementation.

The option "False" is incorrect because it would imply that an idea possesses significant intrinsic value independent of its application. This contradicts the core purpose of quality assurance and process improvement, which is to effect positive change in processes and outcomes. In any business or engineering context, resources are finite, and the value of an idea is measured by its contribution to organizational goals, which cannot occur without implementation.

1. Official Vendor Documentation (CSQA): QAI Global Institute. (2018). The Guide to the Certified Software Quality Analyst Body of Knowledge (CSQA BOK). Skill Category 4: "Quality Leadership," Sub-skill 4.F, "Facilitate Organizational Change." This section details the analyst's role in not just conceiving but also planning, selling, and implementing changes to processes and standards. The entire skill area is predicated on the principle that ideas must be implemented to provide value.

2. Peer-Reviewed Academic Publication: Rogers, E. M. (2003). Diffusion of Innovations (5th ed.). Free Press. In Chapter 1, Rogers defines an innovation as "an idea, practice, or object that is perceived as new by an individual or other unit of adoption" (p. 12). The entire theory of diffusion is concerned with the process by which an innovation is "communicated through certain channels over time among the members of a social system," leading to adoption and implementation. The value is derived from the adoption, not the mere existence of the idea.

3. University Courseware: von Hippel, E. (2005). Democratizing Innovation. MIT Press. As used in MIT Sloan School of Management course 15.351 Managing the Innovation Process, the book and associated lectures emphasize that innovation is not just invention (the idea) but the entire process through to successful implementation and diffusion. Chapter 1 states, "Innovation is in the end a commercial-outcome-related concept" (p. 4), directly linking an idea's value to its practical implementation and acceptance.

Modern quality-management frameworks (e.g., ISO 9000 family, IEEE Std 730) and the classical teachings of Deming, Juran and Crosby all state that quality improvement cannot be achieved by isolated functions. Sustained quality improvement and the effective operation of a quality-management system require the active cooperation of “people at all levels” and “all relevant functions” in the organization. Hence cooperation is not optional but required to both improve quality and to implement/maintain a quality-management system.

Why the other option is wrong:

• False – would contradict the fundamental “engagement of people” principle in ISO 9000 and the cross-functional collaboration requirements found in IEEE 730; without cooperation, quality initiatives consistently fail (as documented in empirical studies and university coursework).

1. ISO 9000:2015, Quality management systems — Fundamentals and vocabulary, Clause 2.3.6 “Engagement of people”, bullet a: “People at all levels … must be involved and cooperate to enhance the organization’s capability to create and deliver value.”

2. ISO 9001:2015, Clause 5.1.1 b & f: Top management shall “promote a customer focus throughout the organization” and “communicate the importance of effective quality management,” both of which presuppose inter-functional cooperation.

3. IEEE Std 730-2014, §5.2 “SQA Activities”: “The SQA Group shall work with project management, development, test, configuration management and other involved groups…” (explicit requirement for cooperation).

4. MIT OpenCourseWare, Course 15.301/15.310 “Managerial Psychology: Leading Organizations,” Lecture on Deming’s 14 points (slide ‘Point 9’): “Break down barriers between departments; people must work as a team.” (https://ocw.mit.edu, Spring 2006 materials).

5. Juran, J.M. & Godfrey, A.B. (1999). Juran’s Quality Handbook, 5th ed., McGraw-Hill, Ch. 3 “Quality Planning Roadmap,” p. 3.12: “Interdepartmental cooperation is essential for successful quality improvement.”

The statement is correct. Quality Assurance (QA) is a proactive management discipline focused on preventing defects by ensuring that the processes and standards used to create a product are appropriate and correctly implemented. Its primary emphasis is on the process itself, with the goal of building quality into the product from the start, rather than inspecting for defects after the fact. This process-centric view is a core management function designed to provide confidence that the final product will meet the required quality standards.

This is a "TRUE OR FALSE" question. The statement "False" would be incorrect because it would mischaracterize the fundamental nature of Quality Assurance. To claim QA is not a management function or not process-focused would be to confuse it with Quality Control (QC). QC is a reactive, product-oriented activity focused on identifying defects in the finished product through testing and inspection. In contrast, QA is a preventative, process-oriented management activity.

1. IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), Version 3.0. (2014). In Chapter 11: Software Quality, the guide distinguishes between quality assurance and other quality activities. It states, "Software quality assurance (SQA) is a set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes." This clearly defines QA as a process-focused set of activities that provide confidence, aligning with the concept of a management function. (See Section 2.1, SQA Activities).

2. ISO 9000:2015, Quality management systems — Fundamentals and vocabulary. The international standard defines Quality Assurance as the "part of quality management focused on providing confidence that quality requirements will be fulfilled." This confidence is achieved through the systematic management and evaluation of processes, confirming its role as a management function with a process emphasis. (See Clause 3.3.6).

3. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill Education. In Chapter 16, "Software Quality Assurance," the text describes SQA as "a management activity that is applied throughout the software process." It further explains that SQA encompasses a set of auditing and reporting functions that assess the effectiveness and completeness of quality control activities, reinforcing its role as a management oversight function focused on the entire process. (See Chapter 16.1, "Elements of Software Quality Assurance").

Within software‐quality and SPI (software-process-improvement) literature, the consensus is that writing or “developing the approach” for a new or revised process is relatively straightforward; the real difficulty is in rolling that process out, gaining acceptance, training staff, and ensuring sustained, organization-wide use. The CSQA Body of Knowledge explicitly notes that institutionalizing (deploying) a process is harder than defining it. Therefore the statement that “the development of the approach … is much harder than the actual deployment” is incorrect.

Why the Opposite (True) Would Be Wrong:

Answering “True” would reverse the well-documented reality. Deployment demands change-management activities (communication, training, mentoring, measurement, management sponsorship, cultural adaptation) that consistently prove more resource-intensive and risk-laden than drafting the process description itself.

1. PeopleCert / QAI. “Certified Software Quality Analyst (CSQA) Common Body of Knowledge,” v2023, Section 3.3.1 “Process Design and Deployment,” para 2, p. 109:

“Developing or documenting a process is usually not difficult; the greater challenge is deploying that process and ensuring that it is used consistently across the organization.”

2. SEI, CMMI® for Development, Version 1.3, CMU/SEI-2010-TR-033, p. 42 (Generic Practices discussion):

“In many organizations defining processes has not been difficult; rather, getting them used effectively is the real challenge.”

3. Paulk, M. “Software Process Improvement: Implementation is the Hardest Part,” IEEE Software, Vol. 11 No. 4, 1994, pp. 61-64. DOI: 10.1109/52.281686.

“…drafting new processes is relatively easy; institutionalizing them throughout the enterprise is what proves difficult.”

4. MIT OpenCourseWare, Course 16.882 “System Processes & Process Improvement,” Lecture 5 slides, slide 13:

“Defining a process can be done by a small core team; deployment requires organizational change and is considerably harder.”

These authoritative sources directly contradict the claim in the question, making the correct choice False.

The statement is true by the very definition of Commercial Off-the-Shelf (COTS) software. COTS products are developed by a vendor for a general market, not for a specific client. They are pre-packaged, commercially available solutions that an organization can buy or license. Therefore, the development of the software product is completed and the product is made available on the open market prior to any individual organization making the decision to select and acquire it for their use. This is the fundamental distinction between acquiring COTS software and commissioning custom-developed software, where development begins only after an organization has defined its requirements and contracted a developer.

The "False" option is incorrect because it would contradict the core concept of "off-the-shelf." If the software were developed after or concurrently with an organization's selection, it would be classified as custom or bespoke software, not COTS.

1. QAI Global Institute. (2018). Certified Software Quality Analyst (CSQA) Body of Knowledge. Category 6: Define, Build, Implement, and Improve Work Processes. The CBOK describes software acquisition processes, distinguishing between custom development and the procurement of pre-existing packages (COTS). It implicitly supports that COTS products are developed for a mass market and exist before a specific customer's acquisition process begins.

2. Carney, D., & Oberndorf, P. (2000). A Framework for COTS-Based Systems (CMU/SEI-99-TR-021). Software Engineering Institute, Carnegie Mellon University. In the introduction, the report defines COTS products as those "sold, leased, or licensed to the general public...offered by a vendor in the commercial marketplace," which necessitates their existence prior to selection by a specific program or organization. (p. 1).

3. MIT OpenCourseWare. (2015). 16.842 Fundamentals of Systems Engineering, Lecture 20: Acquisition. The course materials distinguish between developmental items (custom-built) and non-developmental items (NDI), which include COTS. The lecture notes clarify that COTS are existing commercial products selected to fulfill requirements, confirming that their development precedes the selection and acquisition phase by the using organization.

The statement is false. A fundamental and non-negotiable principle of auditing is independence. An audit is defined as an independent examination of a process, product, or system. For an audit to be credible and its findings to be considered objective, the auditor(s) must be organizationally independent and impartial from the individuals or teams whose work is being audited. This separation prevents conflicts of interest and ensures an unbiased assessment against established standards and procedures. While individuals can perform self-reviews or inspections of their own work, these activities are not classified as formal audits due to the inherent lack of independence.

The "True" option is incorrect because it violates the core tenet of auditor independence. If individuals involved in conducting the work were allowed to perform the audit, it would be a self-review, not an audit. This would compromise the integrity, objectivity, and reliability of the findings, rendering the entire process ineffective as a formal assurance activity.

1. Quality Assurance Institute (QAI). (2014). CSQA Certified Software Quality Analyst Body of Knowledge (4th ed.).

Reference: Domain 1: Quality Principles and Concepts, Skill Category F: Quality Audits, Section 2, "Types of Audits."

Content: The CBOK explicitly defines an audit as an "independent review" and emphasizes that auditors must be independent of the work being audited to ensure objectivity. It distinguishes between first-party (internal), second-party (supplier), and third-party (external) audits, all of which presuppose a level of independence from the direct performers of the work. For internal audits, the auditors must be from outside the specific project or department being audited.

2. Bourque, P., & Fairley, R. E. (Eds.). (2014). Guide to the Software Engineering Body of Knowledge (SWEBOK) (Version 3.0). IEEE Computer Society.

Reference: Chapter 10: Software Quality, Section 2.3.2, "Audits."

Content: The SWEBOK defines an audit as "an independent examination of a software product or process to assess compliance with specifications, standards, contractual agreements, or other criteria." The key term "independent" is central to the definition, distinguishing it from other review types. This IEEE standard, which informs the CSQA certification, reinforces that the auditing entity must be separate from the development or operational entity. (DOI: https://doi.org/10.1109/978-0-7695-5166-1)

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

Reference: Chapter 17: Software Quality Assurance, Section 17.3, "SQA Tasks, Goals, and Metrics."

Content: This foundational academic textbook, widely used in university software engineering curricula, describes formal technical reviews and audits as key SQA activities. It states that for an audit to be effective, it must be conducted by an independent party, such as the SQA group, to provide management with an objective assessment of compliance. The text explicitly contrasts this with less formal reviews that might be conducted by peers within a team.