CSQA CSQA Certified Software Quality Analyst Questions and Answers

There are four main testing stages in a structured software development process. They are:

Unit Testing

These tests demonstrate that a single program, module, or unit of code function as designed. For example, observing the result when pressing a function key to complete an action. Tested units are ready for testing with other system components such as other software units, hardware, documentation, or users.

Integration Testing

These tests are conducted on tasks that involve more than one application or database, or on related programs, modules, or units of code, to validate that multiple parts of the system interact according to the system design. Each integrated portion of the system is then ready for testing with other parts of the system.

System Testing

These tests simulate operation of the entire system and confirm that it runs correctly. Upon completion, the validated system requirements result in a tested system based on the specification developed or purchased.

User Acceptance Testing

This real-world test is the most important to the business, and it cannot be conducted in isolation. Internal staff, customers, vendor, or other users interact with the system to ensure that it will function as desired regardless of the system requirements. The result is a tested system based on user needs.

If you want to develop a baseline of customer satisfaction, you might ask your customer to rate the following factors using “very satisfied” to “very dissatisfied” as a scale:

Availability– Accessible to the customer, as agreed (e.g., product is available when you need it).

Correctness– Accurate and meets business and operational requirements (e.g., automated information is accurate).

Flexibility– Easy to customize for specific needs (e.g., easy to enhance product with new features).

Usability– Easy to learn, easy to use, and relevant (e.g., the way you interact with components of the product is consistent).

Caring– Demonstrating empathy, courtesy, and commitment (e.g., project team is sensitive to your needs).

A histogram requires some understanding of the data set being measured to consolidate or condense it into a meaningful display. To create a histogram, perform the following steps:

Gather data and organize it from lowest to highest values.

Calculate the range, which is the largest value – smallest value.

Based on the number of observations, determine the number of cells, which is normally between 7 and 13.

Calculate the interval or width of the cells, which is the range divided by number of cells.

Sort the data or observations into their respective cells.

Count the data points of each cell (frequency) to determine the height of the interval, and create a frequency table.

Plot the results.

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 be simple, 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 or services. Fit for use means that the product or service meets the customer’s needs regardless ofthe 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

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.

Management needs to develop quantitative, measurable "standards" for each of these quality criteria for their development projects. For example, management must decide the degree of maintenance effort that is acceptable, the amount of time that it should take for a user to learn how to use the system, etc.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-11 at 2.39.38 PM.png

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.

Develop a matrix of process results and contributors to show which contributors drive which results. The results should come from the process policy. The contributors can be positive or negative, and involve process, product, or resource attributes. Process attributes includecharacteristics such as time, schedule, and completion. Product attributes include characteristics such as size, correctness, reliability, usability, and maintainability. Resource attributes include characteristics such as amount, skill, and attitude. A cause-and-effect diagram is often used to graphically illustrate the relationship between results and contributors.

Assure process results are aligned to business results. Processes should help people accomplish their organization’s mission. Alignment is subjective in many organizations, but the more objective it is, the greater the chance that processes will drive the mission.

Rank the process results and the contributors from a management perspective. This will help workers make tradeoffs and identify where to focus management attention.

Select metrics for both the process results and contributors, and create two tactical process dashboards: one for process results and one for contributors. These dashboards are used to manage the projects and to control and report project status. Normally results are measured subjectively and contributors are measured objectively. For example, for a result of customer satisfaction, contributors might include competent resources, an available process, and a flexible and correct product. Sometimes, as with customer satisfaction, factors that contribute to achieving the result can actually be used to develop the results metric. In other words, first determine what contributes to customer satisfaction or dissatisfaction and then it can be measured.

Identify a problem (effect) with a list of potential causes. This may result from a brainstorming session.

Write the effect at the right side of the paper.

Identify major causes of the problem, which become “big branches”. Six categories of causes are often used: Measurement, Methods, Materials, Machines, People, and Environment, but the categories vary with the effect selected.

Fill in the “small branches” with sub-causes of each major cause until the lowest level sub-cause is identified.

Review the completed cause-and-effect diagram with the work process to verify that these causes (factors) do affect the problem being resolved.

Work on the most important causes first. Teams may opt to use the nominal group technique or Pareto analysis to reach consensus.

Verify the root causes by collecting appropriate data (sampling) to validate a relationship to the problem.

Continue this process to identify all validated causes, and, ultimately the root cause.

Define the Scope of the Process

Use the Process Inventory, Process Maps, and existing standards and procedures to clarify the scope of the process. This involves developing a high-level process flow (major workbenches and interfaces with other processes), major inputs and outputs (deliverables), and major customers and their requirements.

Develop the Workflow

Brainstorm the tasks and deliverables in the process and then group the tasks. Select the current best practices, adding missing tasks or deliverables and correcting flaws in the workflow. Define the workbenches internal to the process, their sequence, and major interim deliverables. Typically processes contain 3-5 workbenches, with each workbench containing 3-7 process steps or task procedures.

Develop Policies

A policy states why the workbench or deliverable exists, and indicates desired results (desirable attributes of process performance or desirable product quality characteristics). Policies should link to the organization’s strategic goals, and support customer needs or requirements. A policy should be realistic, stating a desire that the organization is currently capable of accomplishing.

Develop Standards

A standard states what must happen to meet the intent of the policy. Standards are more specific than policies in that they convert intentions into specific rules. Workbench standards deal withperformance issues related to time frames, prerequisites, or sequencing of tasks while deliverable standards typically specify content.

Develop Procedures

Procedures describe how work is done, and indicate the "best current way" to meet standards. Ideally, if the procedures are followed, the standards will automatically be followed and the intent of the policy will be met.

A task is a single step in a procedure. Procedures may have many tasks. Task procedures should refer to people, accessible tools, known techniques or methods, and templates for deliverables. If appropriate, tasks can also refer to more detailed work instructions, such as training or user’s manuals.

The objective of this phase is to create an environment in which the use of quantitative data is an accepted component of the management process. The four steps for accomplishing this are:

Define the objectives for the measurement program- how it is to be used. Consider how to implement the four uses of measurement, given the maturity level of the organization. The use of measurement should be tied to the organization’s mission, goals and objectives.

Create an environment receptive to measurement.Begin with the prerequisites listed earlier in this section. Establish service level agreements between IT and the users to define quality and productivity that must be defined before they can be measured. People involved with the measurement should help develop the measure. Establish a quality management environment and ensure the work processes being used have been implemented.

Define the measurement hierarchy, which has three levels of quantitative data: measures, metrics, and a strategic results dashboard (also called key indicators). This measurement hierarchy maps to a three-level IT organizational tier: staff, line management and senior management. IT staff collects basic measures, such as product size, cycle time, or defect count. IT line management uses fundamental metrics, such as variance between actual and budgeted cost, user satisfaction or defect rates per LOC to manage a project or part of the IT function. Senior management uses a strategic results dashboard, where the metrics represent the quantitative data needed to manage the IT function and track to the mission, vision, or goals. For example, a mission with a customer focus should have a customer satisfaction metric. A metric of the number of projects completed on time gives insight into the function's ability to meet short and long-term business goals.

Define the standard units of measurement.

There are three COQ categories:

Prevention - Money required preventing errors and to do the job right the first time is considered prevention cost. This category includes money spent on establishing methods and procedures, training workers and planning for quality. Prevention money is all spent before the product is actually built.

Appraisal – Appraisal costs cover money spent to review completed products against requirements. Appraisal includes the cost of inspections, testing and reviews. This money is spent after the product or subcomponents are built but before it is shipped to the user.

Failure – Failure costs are all costs associated with defective products. Some failure costs involve repairing products to make them meet requirements. Others are costs generated by failures, such as the cost of operating faulty products, damage incurred by using them and the costs incurred because the product is not available. The user or customer of the organization may also experience failure costs.

Environmental controls are the means by which management uses to manage the organization. They include such things as organizational policies, the organizational structure in place to perform work, the method of hiring, training, supervising and evaluating personnel, and the processes provided personnel to perform their day-to-day work activities, such as a system development methodology for building software systems.

Auditors state that without strong environmental controls the transaction processing controls may not be effective. For example, if passwords needed to access computer systems are not adequately protected the password system will not work. Individuals will either protect or not protect their password based on environmental controls such as the attention management pays to password protection, the monitoring of the use of passwords that exist, and management’s actions regarding individual workers failure to protect passwords.

Environmental controls are the means by which management uses to manage the organization.

Examples of environmental controls are the review and approval of a new system, limiting access to computer resources and transaction processing controls.

Review and Approval of a New System

This control should be exercised to ensure management properly reviews and approves new IT systems and conversion plans. This review team examines requests for action, arrives at decisions, resolves conflicts, and monitors the development and implementation of system projects. It also oversees user performance to determine whether objectives and benefits agreed to at the beginning of a system development project are realized.

The team should establish guidelines for developing and implementing system projects and define appropriate documentation for management summaries. They should review procedures at important decision points in the development and implementation process.

Limiting Access to Computer Resources

Management controls involve limiting access to computer resources. It is necessary to segregate the functions of systems analysts, programmers, and computer operators. Systems analysts and programmers should not have physical access to the operating programs, and the computer files. Use of production files should be restricted to computer operating personnel. Such a restriction safeguards assets by making the manipulation of files and programs difficult. For example, assume a bank’s programmer has programmed the demand deposit application for the bank. With his knowledge of the program, access to the files in the computer room on which information about the demand depositors is contained may allow him to manipulate the account balances of the bank’s depositors (including his own balance if he is a depositor).

Transaction Processing Controls

The object of a system of internal control in a business application is to minimize business risks. Risks are the probability that some unfavorable event may occur during processing. Controls are the totality of means used to minimize those business risks.

There are two systems in every business application. The first is the system that processes business transactions, and the second is the system that controls the processing of business transactions. From the perspective of the system designer, these two are designed and implemented as one system. For example, edits that determine the validity of input are included in the part of the system in which transactions are entered. However those edits are part of the system that controls the processing of business transactions.

Because these two systems are designed as a single system, most software quality analysts do not conceptualize the two systems. Adding to the difficulty is that the system documentation is not divided into the system that processes transactions and the system that controls the processing of transactions.

Experience has shown that over 50% of the software developed by offshore organizations fails to meet the expectations of the contractor. Since many of the decisions to have software developed offshore are economic decisions, the differences associated with having the software developed offshore negate the economic advantages in many cases. These offshore differences are:

Cultural differences

There may be a significant difference in the culture and values between the contractor and the offshore organization.

Communication barriers

The language of the offshore organization may be different or difficult to comprehend which causes difficulty in communicating the needs and desires of the contractor.

Loss of employee morale and support

Employees who would like to have developed the software may resent the software being developed offshore and thus make it difficult for the offshore developed software to be successful.

Root cause of the contractor IT organization not addressed

Frequently, offshoring is chosen because there are problems in the contractor organization that executives do not want to address. For example, the problems might include a lack of training for the employees in the contractor organization or other perhaps better options for software development were not explored

While the software may be developed by an outside organization, the responsibility for quality of that software cannot be contracted. The contractor is still responsible for the quality of the organization. There must be a process to monitor the development and validate the correct functioning of the software when it is developed by an outside organization.

The quality professional is the individual who should accept the quality responsibility for software developed by an outside organization. This may mean that the quality professional needs to visit periodically or during the entire developmental period of the software to ensure the quality. Many of the same practices used to assure quality of in-house developed software are applicable to software developed by outside organizations. For example, conducting reviews at specific checkpoints should occur on contracted software. Acceptance testing should be conducted on all software regardless of how developed.

The quality professional’s specific responsibility for software developed by outside organizations is to assure that the process for selecting COTS software and contracting with an outside organization for software are adequate.

One of the major responsibilities of the quality assurance activity is to oversee the development and deployment of work processes, and then to assure that those work processes are continuously improved.

Without a process for selecting COTS software and a process for contracting for software those processes would be subject to great variability. One contract may work well, one acquisition of COTS software may work well, while other acquisitions may result in a failure.