CSQA CSQA Certified Software Quality Analyst Question and Answers

A mission statement explains why a company, organization, or activity exists, and what it is designed to accomplish. It clearly and concisely describes the work that is done, providing direction and a sense of purpose. The mission should focus on products and services and be customer-oriented. During implementation, the mission is constrained by the vision and values. Examples of mission statements include:

From Arco Transportation Company Information Services: "The mission of information services is to provide the appropriate computing network, products, and services and support of the strategies, goals, and objectives of the company."

From the Ford Motor Company (listed in their Ford Q-101 Quality Systems Standard, January 1986): “Ford Motor Company is a worldwide leader in automotive and automotive-related products and services as well as in newer industries such as aerospace, communications, and financial services. Our mission is to improve continually our products and services to meet our customers’ needs, allowing us to prosper as a business and to provide a reasonable return for our stockholders, the owners of our business.”

Vision

Leaders provide a vision, which is a clear definition of the result to be achieved. Organizations without a vision flounder. The vision establishes where the organization desires to move from its current state. It gives everyone a direction to work towards. Senior management should establish the vision, ensuring how it contributes to the business is clear. A vision is simple and concise, and it should be understood and supported by all.

Examples of visions include:

From the Quality Assurance Institute: “Our vision is to produce competent and successful quality assurance analysts.”

From the Eastman Kodak Company: "We see ourselves now and in the future as a company with a strong customer franchise, known for reliability, trust, and integrity in all relationships. Our business will be based on technologies that have evolved over our long history, and which will give us unique advantages over our competition. These technologies will span our core businesses, and will also go beyond boundaries we can see today.”

From the Ford Motor Company: "A worldwide leader in automotive and automotive related products and services as well as in newer industries such as aerospace, communications, and financial services."

President Kennedy had a vision of putting a man on the moon before 1970.

QA analysts should have a vision of improving quality, productivity, and customer satisfaction.

The concerns that arise in maintaining a relationship of harmony and good will include:

Contractor obligations met - The contractor should meet their requirements as specified in the contract.

Customer obligations met - The customer should meet their requirements as specified in the contract.

Need met - It is to the benefit of both parties to have the customer satisfied with the application system. Even when the initial deliverables meet the customer’s need, there will be ongoing maintenance required to meet the continually evolving needs of the customer. The methods of doing this should be specified in the contract, and those requirements should form the basis for both parties specifying and delivering new contractual obligations.

Limits on cost increases - The cost specified in the contract should include provisions for ongoing costs. In an inflationary economy, it may be advantageous to have limits placed on cost increases. For example, if service is provided at an hourly rate, the increases in that rate might be specified in the contract.

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.

A practice is a specific implementation of a work process. For example, a practice would be one organization’s process for estimating the amount of resources required for building a system. A Best Practice is one of the most effective practices for performing a specific process. Best Practices are normally identified by benchmarking, or by an independent assessment. Best Practices are also identified through winners of quality competitions such as the Malcolm Baldrige National Quality Award, Deming Prize, etc.

Lack of involvement by management

Management's unwillingness to accept full responsibility for all defects

Failure to determine the cost associated with defects (i.e., poor quality)

Failure to initiate a program to "manage defects"

Lack of emphasis on processes and measurement

Failure to enforce standards

Failure to reward people for following processes

Lack of knowledge about quality

Lack of a quality vocabulary, which makes it difficult to communicate quality problems and objectives

Lack of knowledge of the principles of quality (i.e., what is necessary to make it happen)

No categorization scheme for defects (i.e., naming of defects by type)

No information on the occurrence of defects by type, by frequency, and by location

Unknown defect expectation rates for new products

Defect-prone processes unknown or unidentified

Defect-prone products unknown or unidentified

An economical means for identifying defects unknown

Proven quality solutions are unknown and unused

The QA analyst has three roles in integrating new technology:

Determining the Risks

Each new technology poses new risks. These risks need to be identified and prioritized and, if possible, quantified. Although the QA analyst will probably not perform the actual task, the QA analyst needs to ensure that a risk analysis for the new technology is undertaken and effectively performed.

Assuring that the Controls are Adequate to Reduce the Risk

The QA analyst needs to assess whether the controls proposed for the new technology are adequate to reduce the risk to an acceptable level. This may be done by line management and reviewed by the QA analyst.

Assuring that Existing Processes are Appropriately Modified to Incorporate the Use of the New Technology

Work processes that will utilize new technologies normally need to be modified to incorporate those technologies into the step-by-step work procedures. This may be done by the workers responsible for the work processes, but at least needs to be assessed or reviewed by the QA analyst.

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.

SEI CMM Model:

It is a staging model.

All processes have to be followed in order.

Designed specifically for software organizations.

It has 5 stages:

Initial – Level 1

Repeatable – Level 2

Defined – Level 3

Managed – Level 4

Optimizing – Level 5

ISO 9000:

It is a continuous model.

Processes can be followed independently.

Not specific to software organizations.

The workbench transforms to the input to produce the output. The workbench is comprised of two procedures: Do and Check, which correspond to the Do and Check phases of the PDCA cycle. If the Check procedure determines that the standards for the output product are not met, the process engages in rework until the output products meet the standards, or management makes a decision to release a nonstandard product. People, skills, and tools support the Do and Check procedures. A process is defined by workbench and deliverable definitions. A process is written with the assumption that the process owners and other involved parties possess certain skill and knowledge levels (subject matter expertise).

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-13 at 2.13.25 AM.png

Preventive Control

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

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. The input documents, where possible, should have evidence of authorization and should be reviewed by the internal control group in data processing. To the extent practical, the computer should be utilized as much as possible to authorize input. This may be done through programmed controls.

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 thetransactions. Since the data input process is typically a manual operation, control is needed to ensure that the data input has been performed accurately.

Detective Controls

Detective controls alert individuals involved in a process so that they are aware of a problem. Detective controls should bring potential problems to the attention of individuals so that action can be taken. One example of a detective control is a listing of all paychecks for individuals who worked over 80 hours in a week. Such a transaction may be correct, or it may be a systems error, or even fraud.

Data Transmission

Once the source data has been prepared, properly authorized, and converted to machine-processable form, the data usually is transmitted from the source department to the data processing center. Data transmission can be made by conventional means (such as messenger and mail) or by data transmission devices which allow data transmission from remote locations on a much timelier basis.

Control Register

Another technique to ensure the transmission of data is the recording of control totals in a log so that the input processing control group can reconcile the input controls with any control totals generated in subsequent computer processing.

Corrective Controls

The following two corrective controls will be discussed in this chapter: error detection and resubmission, and audit trails.

Error Detection and Resubmission

Until now we have talked about data control techniques designed to screen the incoming data in order to reject any transactions that do not appear valid, reasonable, complete, etc. Once these errors have been detected, we need to establish specific control techniques to ensure that all corrections are made to the transactions in error and that these corrected transactions are reentered into the system.

Audit Trails

Another important aspect of the processing cycle is the audit trail. The audit trail consists of documents, journals, ledgers, and worksheets that enable an interested party (e.g., the auditor) to trail an original transaction forward to a summarized total or from a summarized total backward to the original transaction. Only in this way can they determine whether the summary accurately reflects the business’s transactions.

An evaluator can use the six steps below to assess the climate of a specific organization, group, committee, task force, etc.

1. Look at the organization (group, committee, task force, etc.)

Assess the mission and goals of the organization, what it is supposed to produce, and the overriding principles by which it operates.

2. Examine the jobs

Examine each job in the organization. Ask whether the job is necessary, whether it makes full use of the employee’s capabilities, and whether it is important in accomplishing the mission and goals of the organization.

3. Assess employees’ performance

Evaluate each employee’s performance in relation to the organization’s mission and goals. For each job being performed, ask if the employee is doing what should be done, is using his or her skills effectively, likes his or her job, and has enthusiasm and interest in performing the job.

4. Evaluate how employees feel about their manager or leader

Good organizational climate requires good leadership. Determine whether each employee within the group likes his or her manager, whether they follow or ignore the requests of their manager, and whether they attempt to protect their manager (i.e., make their manager look good).

5. Create a dialog with the members of the group

Interact with each employee asking a series of hypothetical questions to identify the employee's true feelings toward the organization. Questions such as, “do you feel the organization supports your suggestions”, can help draw out the true feelings of each employee.

Vision:

It states what the organization intends to achieve.

Senior Management (CIO)

“To become Global Top 10”

Value:

It states how to run the business.

Senior Management

“Will satisfy customer needs”

Goal:

It states how the vision will be achieved.

Senior Management

“Establish a customer vision group”

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.

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.

1. Develop a charter.

Determine the responsibilities and activities of the quality function.

2. Identify the quality manager.

Select a quality "fanatic" to head the quality function.

3. Locate organizationally the IT quality function.

Determine to whom the quality leader reports.

4. Build support for quality.

Initiate programs that will encourage both management and staff to support quality processes.

5. Staff and train the quality function.

Determine what is needed to make quality happen, identify and select the people to do it, and provide them with the training they need.

6. Build and deploy the quality toolbox.

Select effective quality tools and implement them throughout the organization.

7. Drive the implementation of the quality management environment.

The quality manager will need to spend a significant amount of time maturing the quality management environment.

Level 1 -- Product Focus

In this process category, management's focus is on products. The product focus emphasizes management by objective; specifically meeting schedules, managing people and jobs, and using test and control to determine whether those objectives have been met. At this level, status reports, budgets, checkpoints, and meetings are an important component of how management executes their management function.

Level 2 -- Process Focus

Management's emphasis is to bring discipline to their organization through definition and compliance to processes. The processes are usually an accumulation of the best practices currently in use within the information activity. Management creates an environment for discipline by establishing a quality infrastructure, usually a quality council or committee with several lower-level committees such as a standards or process management committee. At this level, management begins quality planning, conducts end user surveys, encourages employees to make suggestions and recommendations for improvement, and changes the methods by which projects are managed to a more scientific method using process management tools with emphasis on managing the process.

Level 3 -- End User Focus

At this level, management is truly able to focus on the end user. This level is achieved by building a competency-based organization. Management has focused the resources of the organization to meeting its mission/objectives. The practices common at this phase are process management practices based on competency, quality incentives based on competency, and end user feedback systems that impact the establishment of competencies. This level formalizes the use of statistical tools in evaluating processes, and formalizes staff’s process improvement teams.

Level 4 -- Team Focus

The emphasis at this level is moving from committees directed and controlled by management to teams empowered to take action on their own. Turning over the day-to-day operation of the team is possible because the quantitative data initiated at Level 4 enables management to manage byfact as opposed to managing people and jobs. The management practices common at this level include team building, team rewards, cross-functional teams, employee surveys, and the widespread use of management tools by the teams.

Level 5 – World-Class Focus

The teams become truly self-directed and motivated through sharing in the gains made by the organization. Management practices now include benchmarking and advanced statistical tools such as quality function deployment.