CSQA Software Certifications CSQA Certified Software Quality Analyst Free Practice Exam Questions (2025 Updated)

Level 1 – Validation

Validation is testing the software in an operational state. While there are several iterations of testing, they do not occur until the latter part of the system development life cycle. Thus, validation does not take advantage of the control theory stating that the control should be placed as close as possible to where the defect occurs. The most common types of validation are unit testing, integration testing, and system testing. Unit testing tests the smallest operating module of a system; integration testing tests the connecting logic between the modules/units; and the system testing validates that the system executes in the organization's operating environment.

Level 2 – Verification

Verification is the static testing of the system in a nonoperational status. It primarily tests the documentation produced by the project team. The documentation includes requirements, design,code, test, and operating documentation. Verification is performed through a variety of processes, including code analyzers, walkthroughs, reviews, and inspections. These verification processes also interact with the project team, end users, and other interested parties. Level 2 also incorporates acceptance testing, in which the end users define the criteria, which the system must meet in order to, be acceptable, and then test against those criteria.

Level 3 -- Defect Management

This level involves naming defects, counting defects, recording defects in a database, analyzing them, and then managing them throughout the entire life cycle of software. There are two types of defects, just as there are two types of quality. One defect is a variance from requirements/specifications, and the second defect is anything that dissatisfies the end user. For example, if the system was to add A plus B to get C, but in fact added A to X that would be a variance from specification defect. If the output was correct, but hard to use from an end user viewpoint, it would be an ease of use defect. Defects are generally only considered to be defects when they are uncovered in a task beyond the task in which the defect occurred. If the individual who makes the defect finds it during the same task, it is generally not considered to be a defect.

Level 4 -- Statistical Process Control

To be effective, statistical process control needs stabilized processes and defect recording. Some statistical process control techniques will be introduced at Level 3, but their use will be confined more to process improvement than for process management. Good statistical process control techniques require the type of measurement data that is only produced at Level 4. The statistical process control techniques will expand on root cause analysis, use sophisticated statistical tools and analysis, and create dashboards to be used in managing processes.

Level 5 - Preventive Management

This level is focused on preventing defects. It uses the lessons learned from the previous four levels of control/test to address the problems before they can become defects. During the previous four levels, the causes of defects are available and some addressed through process improvement. This level accelerates that trend and in addition provides the professional information staff with methods to modify the way work is performed so that the root causes of defects will not be built into software. This involves building risk models, developing defect expectation charts and/or defect profiles, and processes to customize processes so that the do component of processes can build software that is almost defect free.

Total quality management (TQM) is the term used by many to indicate an organization-wide effort of continuous process improvement. The Federal Quality Institute defines TQM as a strategic, integrated management system for achieving customer satisfaction, which involves all managers and employees and uses quantitative methods to continuously improve an organization's processes.

Some additional thoughts on TQM include:

The improved performance is directed toward satisfying such cross-functional goals as quality, cost, schedule, mission, need and suitability.

TQM is a process of controlled change.

Central to the TQM approach is the change in management philosophy regarding the "responsibility for quality." Formerly it rested with a separate group of individuals in a department/directorate/division often designated as quality assurance. Under TQM, the responsibility rests with every employee, beginning with top management. Skill Category2 provides additional insight into the change in management philosophy, new behaviors for management and leadership.

TQM is accomplished using a team organization; both management and the employees are members of "quality teams" (also called process improvement or process action teams), that focus on continuous process improvement. Suggestions to improve the quality of a particular process should come from the employees and the managers who work in the process, as they know it best.

Communication must be encouraged to allow employees and management to work together to reach the mutual goal of continuous process improvement.

Management Tools

These tools are based on logic rather than mathematics, to address idea generation and organization, decision-making and implementation. The examples are brainstorming and affinity diagram.

Statistical Tools

These tools have a mathematical focus, usually related to data collection, organization, or interpretation. They may also be separated into tools used for counting and tools used with measures. The examples are check sheet and histogram.

Presentation Tools

These tools are used during presentations to summarize or graphically illustrate data. These tools may be used in the development of written materials, such as proposals or reports, or to accompany oral presentations. The examples are table and line chart.

The plan will be outlined in four steps. Those four steps are:

-Creating Messages

- Understanding Audiences

-Planning Transfer Methods

- Defining Impacts.

Actual experience with measurement suggests that recurring costs of 2 - 3% of direct project costs are adequate for data collection and analysis and for project tracking and monitoring. This small price buys real help in meeting project goals, and in increasing project control through better budgeting, problem anticipation, risk reduction, and incremental process improvement.

Quality is a multifaceted concept driven by customer requirements. The level of quality can vary significantly from project to project and between organizations. In IT, the attributes of quality are examined in order to understand the components of quality, and as a basis for measuring quality. Some of the commonly accepted quality attributes for an information system are described in the following figure.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 7.38.30 PM.png

The most important step of the acquisition life cycle is contractor selection. This step has the same importance in the acquisition life cycle as the systems design step has in the system development life cycle. It is determined during this step whether or not the purchased application meets the needs of the organization. During the systems design phase, the needs are translatedinto systems design specifications. During selection those needs are translated into contractual requirements.

Selecting the right organization to develop software is critical to successfully outsourcing development. The selection process must find a competent and compatible organization to develop all or part of the software development. What cannot be outsourced is the responsibility for software quality. The following concerns need to be addressed when selecting an outsourced organization.

Assure That Requirements and Contract Criteria are Testable

A common term used for contracting today is performance-based contracting. This means that the performance criteria of the contractor will be defined and once defined, can be monitored and measured.

It is important that all the requirements that will be given to the contractor are testable. That means as much as possible, an objective measurement can be made as to whether or not that requirement or criteria has or has not been met. For example, easy-to-use criteria might specify the type and number of help screens included within the software.

As a general rule, if a requirement or criteria is not testable the contractor has significant discretion on how that requirement or criteria is implemented. It also limits the contractee’s ability to have corrections made without additional cost for a requirement or criteria that does not meet the customer’s need. If it is a testable requirement, it is easy to demonstrate that the contractor has failed to meet the component of the contract.

Assure That the Contractor Has an Adequate Software Development Process

The contractor should provide a certificate indicating what SEI CMMI level they have achieved or equivalent; for example, ISO certified.

Assure That the Contractor Has an Effective Test Process

This responsibility is primarily for contracted developed software. It is important for the quality professional to develop an opinion on the contractor’s ability to deliver software that meets the requirements or criteria in the contract. It can also provide insight on the ability of the contractor to develop software at a reasonable cost. For example, if the test plan indicates that the defect removal efficiency at the requirements phase is 95%, then the quality professional knows that only 5% of the requirement defects will move to the design phase. On the other hand, if the contractor does not begin testing until after the unit is compiled, then there may be extensive rework and potential delays in getting the software on the scheduled date.

Define Acceptance Testing Criteria

The quality professional should not allow COTS or contracted software to be placed into operation without some acceptance testing. If the COTS software is acquired by the Internet orfrom a business college its reliability is questionable, and it may contain viruses. Many organizations do not permit their employees to acquire software from unapproved sources such as the Internet.

The quality professional may or may not be involved in the actual acceptance testing. However, the quality professional must determine that acceptance criteria are developed. It has been demonstrated extensively that the cost of not acceptance testing is normally much greater than the cost of acceptance testing. It only takes a few problems in acquired software to far exceed the cost of acceptance testing.

Incorporating risk management into the software development life cycle includes planning at the following levels:

Long-Term or High-Level

This level includes both long range planning, and optimizing the organization's mix of projects in order to obtain a balance.

Medium-Term or Medium-Level

This level deals with project management strategies, project evaluation, and selection and project portfolio management

Short-Term or Low-Level

This level includes development, integration and testing strategies.

The quality professional should not allow COTS or contracted software to be placed into operation without some acceptance testing. If the COTS software is acquired by the internet or from a business college its reliability is questionable, and it may contain viruses. Many organizations do not permit their employees to acquire software from unapproved sources such as the internet.

The quality professional may or may not be involved in the actual acceptance testing. However, the quality professional must determine that acceptance criteria are developed. It has been demonstrated extensively that the cost of not acceptance testing is normally much greater than the cost of acceptance testing. It only takes a few problems in acquired software to far exceed the cost of acceptance testing.

Acceptance testing of software will be dependant upon the risk associated with the use of that software. As the use and importance diminishes so does the amount of acceptance testing.

Likewise, the greater assurance the quality professional has in the ability of a contractor of software to produce high quality, defect-free software, the fewer acceptance testing that needs to be conducted.

Subjective baseline studies will be the most commonly conducted studies in measuring quality and productivity. Subjective means that judgment is applied in making the measure. We noted in the discussion on objective measures that when the individual involved in recording time has the option of applying judgment, then the measure becomes subjective.

Baselines should be quantitative even if it is a subjective measure, but quantitatively subjective. For example, because quality conformance and nonconformance must be defined by people, we are looking for ways to put this information into a quantifiable format. This does not convey a lot of information, but it is indicative of a problem. However, if we develop a five-point scale for unresponsiveness, and ask your dissatisfied customer to complete that scale, we now have conveyed a lot more information. If our scale rates “1” as very poor service, and “5” as very good service, there is a great deal of difference between a “1” rating and a “3” rating for dissatisfaction.

Examples of products/services that can be measured subjectively for developing a baseline include:

Customer satisfaction

Effectiveness of standards/manuals

Helpfulness of methodologies to solve problems

Areas/activities causing the greatest impediments to quality/productivity

Causes for missed schedules/over-budget conditions

Understandability of training materials

Value of tools

Importance of activities/standards/methods/tools to individual activity

Baselines can be conducted for any one of the following three purposes:

Planning: To determine where detailed investigation/survey should be undertaken.

Internal analysis: To identify problems/areas for quality improvement. Once the problem/area has been identified, then no additional effort need be undertaken to formalize the results.

Benchmarking: Comparison against external organizations.

IT organizations cannot protect the confidentiality, integrity, and availability of information in today’s highly networked systems environment without ensuring that all the people involved in using and managing IT:

Understand their roles and responsibilities related to the organizational mission

Understand the organization’s IT security policy, procedures, and practices

Have at least adequate knowledge of the various management, operational, and technical controls required and available to protect the IT resources for which they are responsible

Fulfill their security responsibilities.

As cited in audit reports, periodicals, and conference presentations, it is generally agreed by the IT security professional community that people are the weakest link in attempts to secure systems and networks.

While there is no one best way to develop a security awareness program, the process that follows is an all-inclusive process of the best security awareness training program. This example includes these three steps:

1. IT management creates a security awareness policy.

2. Develop the strategy that will be used to implement that policy. (Note that this practice focuses on that strategy. Other practices will explain how to implement the steps in that strategy.)

3. Assign the roles for security and awareness to the appropriate individuals.

The IT Quality Plan should include the following:

A reference to the organization's quality policy

An assessment of where the organization currently stands in relation to accomplishing the quality policy

Long-term quality goals - these are discussed below

Short-term quality objectives (i.e., programs) - these are discussed below

The means of implementing the quality objectives

Resources required in order to accomplish the short-term objectives and long term-goals

Baselining is defining the current level of performance. For example, the number of defects currently contained in a thousand lines of code is usually calculated quantitatively and can be used to measure improvement.

Benchmarking involves a comparison of one organization’s, or one part of an organization’s, process for performing a work task to another organization’s process, for the purpose of finding best practices or competitive practices that will help define superior performance of a product, service or support process.

A benchmarking baseline is one determined by another organization. For example, if you wanted to establish a baseline goal for up-time in your computer center, you might want to go to what you believe is a leading organization and use their up-time percentage as your baseline goal.

Force field analysis is a visual team tool used to determine and understand the forces that drive and restrain a change. Driving forces promote the change from the existing state to the desired goal. Opposing forces prevent or fight the change. Understanding the positive and negative barriers helps teams reach consensus faster. Following are sample processes that could benefit by a force field analysis:

Implementing a quality function

Implementing quality management in IT

Developing education and training programs

Establishing a measurement program/process

Selecting a new technique or tool

Implementing anything new

Establishing meaningful meetings

Empowering the work force

The steps below show how a team uses force field analysis:

1. Establish a desired situation or goal statement.

2. Brainstorm and list all possible driving forces.

3. Brainstorm and list all possible restraining forces.

4. Determine the relative importance of reaching consensus on each force.

5. Draw a force field diagram that consists of two columns, driving forces on one side and restraining forces on the other.

6. Select the most significant forces that need to be acted upon using the nominal group technique to prioritize and reduce the number, if there are too many.

7. Proceed to a plan of action on the forces selected in the previous step

Preventive controls are located throughout the entire IT system. Many of these controls are executed prior to the data entering the computer programs. Following are three of the 8 preventive controls:

Source-data authorization- Once data has been recorded properly, there should be control techniques to ensure that the source data has been authorized. Typically, authorization should be given for source data such as credit terms, prices, discounts, commission rates, overtime hours, and so forth.

Data input -Data input is the process of converting data in non-machine-readable form (such as hard-copy source documents) into a machine-readable form so that the computer can update files with the transactions. Since the data input process is typically a manual operation, control is needed to ensure that the data input has been performed accurately.

Source-data preparation -In many automated systems, conventional source documents are still used and, therefore, no new control problems are presented prior to the conversion of source documents into machine-readable form. Specially designed forms promote the accuracy of the initial recording of the data. A pre-audit of the source documents by knowledgeable personnel to detect misspellings, invalid codes, unreasonable amounts, and other improper data helps to promote the accuracy of input preparation.

The primary concern of the user during acceptance testing is that the deliverables meet the user requirements. The specific concerns during this phase are:

Meets specifications

All of the deliverables provided by the contractor meet the user requirements as specified in the contract.

On time

The delivered products will be in the hands of the user on the date specified on the contract.

Adequate test data

The customer should prepare sufficient test data so that the deliverables can be adequately tested. For application systems, this may be test transactions to verify the processing performed by the application. The acceptance test criteria for training courses and manuals may be review and examination. For example, the contractor may be asked to put on a training class in order to determine the adequacy of the material.

Preparation for operation

Any supporting activities should be completed in time for acceptance testing. This may involve the ordering of forms, making changes to existing operating systems, and other application systems, developing procedures to use the application, etc. The customer should have identified these needs during the feasibility phase, and worked on meeting those requirements while the contractor was preparing the application system.

User training

The users of the application should be trained prior to the acceptance test phase. This training may be provided by the organization itself, or it may be done by the contractor.

When can it begin

Acceptance testing should occur on the date which was specified in the contract.

Conversion to production

The procedures and steps necessary to put the application into production should be tested during the acceptance testing phase. These are normally customer obligations to prepare files, schedule production, etc. These procedures should be tested just as vigorously as the contractor’s application system.

1. Create Consistency of Purpose in the Company

In quality-oriented companies, quality should be the cornerstone of the corporation. All units within the organization should work toward common goals and purposes. Within IT this can be translated to mean that the training department teaches the standards, operations is working for the same goals as systems programming, and systems programming is dedicated to improving application performance. Assuring quality involves:

Innovating new approaches and allocating resources for long-term planning, such as possible new service, new skills required, training and retraining of personnel, satisfaction of the user.

Putting resources into research, education and maintenance.

2. Institute Modern Aids to Training on the Job

Training must be totally reconstructed. Statistical methods must be used to learn when training is finished, and when further training would be beneficial. A person once hired and trained and in statistical control of his/her own work, whether it be satisfactory or not, can do no better. Further training cannot help. If their work is not satisfactory, move them to another job, and provide better training there.

3. Drive Out Fear

Most people on a job, and even in management positions, do not understand what the job is, or what is right versus wrong. Moreover, it is not clear to them how to find out. Many of them are afraid to ask questions or to report trouble. The economic loss from fear is appalling. It is necessary, for better quality and productivity, that people feel secure.

Another related aspect of fear is the inability to serve the best interest of the company through necessity to satisfy specified rules, or to satisfy a production quota, or to cut costs by some specified amount.

One common result of fear is seen in inspection. An inspector records incorrectly the result of an inspection for fear of overdrawing the quota of allowable defectives of the work force.

4. Look Carefully at Work Standards

Do they take account of quality, or only numbers? Do they help anyone do a better job? How old are they? Work standards are costing as much loss as poor materials and mistakes. In hundreds of companies any day, people stand around the last hour or two waiting for the whistle to blow. They have completed their quotas for the day. Is this good for the competitive position of any industry? Ask these people. They are unhappy doing nothing, and would rather work.

Consider questions such as:

How big is the risk?

What exactly is being exposed to the risk?

Can this be considered an acceptable risk?

What alternatives are there?

Will alternatives invoke additional risks?

As it is impossible to be completely certain of the impact or likelihood of many events, these events are estimated using a combination of historical data, knowledge of the event, and experience and judgment. Tools such as simulation, decision trees, or calculating a monetary value are used. Risk can be calculated by structured (associated with data) and unstructured (focus on judgment and experience) methods. Regardless of the method used, two elements must always be considered:

The probability of such an event occurring

The resulting impact if the event occurs

The Quality Charter should contain the following:

Scope

The scope should involve activities supporting the implementation of the quality policy, and closing the producer and customer gaps.

Objectives

The objectives clarify the role of the quality function, and normally move through three phases as quality processes mature. Product quality is the initial focus, followed by the definition and improvement of work processes. Finally, objectives are oriented towards optimization. The next section covers the maturation of the quality function.

Responsibilities

Responsibilities assigned to the quality function should be important, meaningful, accomplishable and measurable. They should be defined in sufficient detail so that the accomplishment or non-accomplishment of the tasks can be determined. The quality function is not responsible for product quality, but will have responsibilities supporting quality initiatives. These responsibilities should include maintaining current knowledge of quality principles and practices; identifying companies and sources that can provide best processes and practices; training, coaching, and facilitating; and maintaining and analyzing databases of information that will help identify process and product weaknesses as candidates for improvement. Additional responsibilities may include participating on committees; providing process management expertise; serving as a centralized resource for measurement analysis and reporting; acting as custodian for processes by formatting, editing, publishing, distributing, and controlling access to changes, etc. Auditing for process deployment and compliance may also be a responsibility, although this is more desirable separated from QA.

Authority

The quality function needs the authority to perform its responsibilities. This authority should give the quality staff access to all documentation and data that is necessary to analyze and identify problems. In many organizations the quality function receives data that is not available to line management. For example, from product inspections it may know the type and quantity of defects made by individuals in building products. Since inspections are designed to assist the worker in improving quality, the usefulness may be compromised if the worker believes management will use them negatively in a performance appraisal. On the other hand, the quality staff needs that information to identify defect-prone products and processes.

Ongoing Quality Programs

The charter should specify programs that will be performed regularly by the quality function. These might include building and analyzing defect databases, assisting in the development of work processes; summarizing and analyzing quantitative data; training the IT staff in quality principles, practices, and processes; and assisting in the performance of tasks such as software reviews and inspections. These programs may change over time as the quality program matures. For example, initially the quality function may chair reviews and inspections, but when that function matures, the review and inspection responsibilities go to the developers of the products.

Measure defect rate in defects per thousand function points or defects per thousand lines of code. As processes become better defined, controls become more effective, and as people become more motivated, the defect rate drops significantly.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 3.24.25 PM.png

Industry accepted definitions of quality are “conformance to requirements” (from Philip Crosby) and “fit for use” (from Dr. Joseph Juran and Dr. W. Edwards Deming). These two definitions are not inconsistent.

Meeting requirements is a producer’s view of quality. This is the view of the organization responsible for the project and processes, and the products and services acquired, developed, and maintained by those processes. Meeting requirements means that the person building the product does so in accordance with the requirements. Requirements can be very complete or they can besimple, but they must be defined in a measurable format, so it can be determined whether they have been met. The producer’s view of quality has these four characteristics:

Doing the right thing

Doing it the right way

Doing it right the first time

Doing it on time without exceeding cost

Being fit for use is the customer’s definition. The customer is the end user of the products o rservices. Fit for use means that the product or service meets the customer’s needs regardless of the product requirements. Of the two definitions of quality, fit for use, is the more important. The customer’s view of quality has these characteristics:

Receiving the right product for their use

Being satisfied that their needs have been met

Meeting their expectations

Being treated with integrity, courtesy and respect

In addition to the producer and customer views of quality, the organizational infrastructure also includes a provider and a supplier view. These views are as follows:

Provider view– This is the perspective of the organization that delivers the products and services to the customer.

Supplier view– This is the perspective of the organization (that may be external to the producer’s company, such as an independent vendor) that provides either the producer and/or the provider with products and services needed to meet the requirements of the customer.

Automated Enforcementis normally viewed as the most fair of all methods of enforcement. It isnormally performed by a computer. The rules are included in the computer system, and whenthose rules are violated, enforcement is automatic.

Automated enforcement is a predetermined enforcement decision. The computer merely executes the action. For example, if you need a password to enter into a system and you do not enter a correct password, access is denied. If you are charging items on your credit card and you have exceeded your credit limit, the computer action is to disallow the purchase.

Several procedures are necessary to maintain control over program changes.

The nature of the proposed change should be explained in writing, and formally approved by a responsible individual. Major changes should be approved by the systems-planning steering committee, commonly called the CCB or Configuration Control Board, in the same manner as for new systems. Minor changes may only require the joint approval of the IT manager and senior personnel in the user department. Documenting the proposed change clears up any initial misunderstandings that may arise when only verbal requests are made. In addition, written proposals provide a history of changes in a particular system.

Developers should make the program changes, not the operations group. Any change should be supported by adequate systems documentation. If the operators were authorized to make minor changes, it would greatly increase the difficulty of controlling versions and of maintaining up-to-date documentation.

Someone independent of the person who designed and made the change should be responsible for testing the final revised program. The results should be recorded on program change registers and sent to the IT manager for approval. Operations should accept only properly approved changes.

Finally, the documentation system should be updated with all change sheets or change registers and printouts.

Objective measurement uses hard data that can be obtained by counting, stacking, weighing, timing, etc. Examples include number of defects, hours worked, or completed deliverables. An objective measurement should result in identical values for a given measure, when measured by two or more qualified observers.

Subjective data is normally observed or perceived. It is a person's perception of a product or activity, and includes personal attitudes, feelings and opinions, such as how easy a system is to use, or the skill level needed to execute the system. With subjective measurement, even qualified observers may determine different values for a given measure, since their subjective judgment is involved in arriving at the measured value. The reliability of subjective measurement can be improved through the use of guidelines, which define the characteristics that make the measurement result one value or another.

Following are a few other examples of objective and subjective measures:

The size of a software program measured in LOC is an objective product measure. Any informed person, working from the same definition of LOC, should obtain the same measure value for a given program.

The classification of software as user-friendly is a subjective product measure. For a scale of 1-5, customers of the software would likely rate the product differently. The reliability of the measure could be improved by providing customers with a guideline that describes how having or not having a particular attribute affects the scale.

Development time is an objective process measure.

Level of programmer experience is a subjective process measure.