Quality Assurance

Q1. From a ______________ viewpoint, a defect is a product requirement that has not been met.

Q2. A procedure is a step-by-step method to ensure that _____________ are met.

Q3. Meeting requirements is ___________ view of quality.

Q4. Customer’s view of quality is referred to as ______________________.

Q5. A ___________ is the requirement that a product or process should fulfill.

Q6. Fit for use means that the product or service meets the customer needs, regardless of the _________ __________.

Q7. The organization policy states that all modules to be tested 100%. However the project team did only 70% testing in each of the modules. This is a type of ___________ quality gap.

Q8. The customer wanted an export and print facility on all screens, however the team provided the same only on some of the screens. This is a type of ______________ quality gap.

Q9. Closing the producer’s gap enables the IT function to provide its customers ____________ in what it can produce.

Q10. Many technical experts believe that _____________ inhibit their creativity.

Q11. It should take not more than 2 days to locate and fix an error in an application. This is a measure of the ________________ attribute of an application

Q12. Password should be more than 6 characters, should have at least one special character and should be changed every 2 months. This is a measure of the ________________ attribute of an application

Q13. The program prepared for a processing VISA card payments should also be useful when preparing an application which processes card payments for MasterCard. This is a measure of the ________________ attribute of an application

Q14. The application should be up 99.9% of the time doing its intended function. This is a measure of the ________________ attribute of an application

Q15. It takes 20 years to change a culture from an emphasis on _______________ to an emphasis on _______________.

Q16. A major premise of a quality management environment is an emphasis on ____________ improvement.

Q17. ROI is achieved by increasing the ____________ and / or the _____________ costs of quality in order to reduce the _______________ cost such that the overall cost of quality is still less than what it would have been without implementing a quality program.

Q18. ___________ should be actively involved in the establishment of their own standards and procedures.

Q19. Six sigma means _______ defects per million opportunities

Q20. _______________ is defining current level of performance.

Q21. Comparing processes within the organization or with an external organization is _______________.

Q22. QC is defined as the processes or methods used to compare product quality to its stated ____________ and applicable ____________.

Q23. ________ is the responsibility of the unit producing the product, while QA is a _________ function.

Q24. It is possible to have QC without QA. T / F

Q25. The Juran trilogy is quality __________, quality ___________ and quality____________.

Q26. TQM is a process of _________ change.

Answers:

1. producer
2. standards
3. producers
4. fit for use
5. standard
6. product requirements
7. producers
8. customer
9. consistency
10. standards
11. maintainability
12. integrity
13. reusability
14. reliability
15. productivity, quality
16. continuous
17. prevention, appraisal, failure
18. workers
19. 3.4
20. baselining
21. benchmarking
22. requirements, standards
23. QC, staff
24. T
25. planning, control, improvement
26. controlled

Also See:

• Other CSQA Questions

====================================================

Date: July 21, 2009

Location: New Delhi

Position: Sr. Process & Quality Analyst

Exp:  3+ years

Candidate must be trained/ certified on Six Sigma & ITIL. Should have exposure on SLA analysis, maintaince & definion.

Responsibilities:

• List of activities performed within each responsibility area
• Definition of any new process required to deliver services to the customer as per business requirement
• Revision of any existing process as per changes in business requirement or for improvement in service performance
• Ensuring all processes are having defined speps to be audited, defined samples to audited and defined frequency at which the audit needs to be conducted. There should be a signoff on these with the process owner
• Ensure that all engineers following the process are trained on audit steps as and when the audits steps are gettign defined or revised
• Ensure all audits are conducted as per schedule
• Ensuring all processes are having defined metrics to measure the performance of the process as per business requirement
• Ensure that the frequency of generation of reports are signed off with the process owners are adhered to
• Ensure all reports are delivered as per the schedule
• Ensure that all process are adhering to document management guidelines and are stored live and updated at all times in the central repository
• Ensure that all audit steps are documented as per document management guidelines and are stored live and updated at all times in the central repository
• Ensure that SOPs for all reports and dashboards are documented as per document management guidelines and are stored live and updated at all times in the central repository
• Analyse and identify Improvement areas to help increase productivity
• Analyse and identify Improvement areas to help reduce average Incident resolution time
• Analyse and help improve Incident ratio and reduce incidents through the definition of Problem Management
• Analyse process performance metrics to identify any areas of improvement and drive improvement together with process owner
• Analyse processes to identy any areas of automation in the process and drive automation initiatives together with process owners
• Participare in internal reviews to discuss metrics on performance of processes, understand process owners pain points, identify areas of improvement and drive improvement together with process owner
• Participare in operations reviews with customer to discuss metrics on performance of processes, understand customer pain points, identify areas of improvement and drive improvement together with process owner
• Keeping track of current and forecasted tasks which needs to be delivered by self and team on daily, weekly, monthly and quarterly basis
• Proper estimation of effort required for all tasks
• Identifing gap in resource strength required and work with reporting manager to find a solution such as resource adddition
• Updation of team skill matrix – Assessment of each team member as per the defined frequency to assess skill gaps for each individual
• Signoff on TNI based on the skill gap scores and coordinate with QM/AQM, TTC for impartation of training
• Track application of skills as well as assessment scores of all team members and mentor them for skill development
• Suggest changes in processes to incorporate best practies in order to improve service performance, reduce cost of deliver and enhance customer satisfaction
• Understanding the processes required to deliver the signed of deliverables for the customer
• Understaning of service management tool to be used to deliver services to the customers
• Understanding of methodology of data collection in order to generate service performance metrics for agreed services and processes
• Alignment of processes to Microland & Business standard processes and signoff with the customer on the same
• Definition of metrics to the shared with the customers and signoff on the same
• Training of all resources on processes signed off with the customers
• Training on usage of service management tool required to deliver services to the customers
• Training of data analysts on methodology required to collate data and publish dashboards signed off with the customers

If your are interested, please mail your resume at o_manishad@microland.com

====================================================

====================================================
Date: July 21, 2009

Location: Gurgaon

Experience: 5 – 10 Years

Desired Candidate Profile: Graduate/MBA with 5-6 years of total exp and 1-2 years of managerial exp/ISO 9000 Lead Assessor, Six Sigma Green / Black Belt in a large BPO setup. Excellent Knowledge of ISO 9000. Knowledge on KAIZEN & Suggestion scheme & process orientation

Job Description Overview:

• Excellent Knowledge of ISO 9000.
• Knowledge on Six Sigma tools & techniques.
• Exposure to Six Sigma, 7 QC Tools, Policy Deployment,Extensive work on Problem Solving tools & techniques. Design training and sensitizing programmes

If you are interested, please mail your resume at anshu@creativeindians.com

Contact Anshu at 011-45088685
====================================================

Sample Subjective question papers:

• CSQA Subjective questions sample paper – 1
• CSQA Subjective questions sample paper – 2
• CSQA Subjective questions sample paper – 3

Skill Category wise Practice questions:

• Quality Principles
• Quality Leadership
• Quality Baselines
• Quality Assurance
• Quality Planning
• Work Processes
• Quality Control Practices
• Metrics and Measurement
• Internal Control and Security
• Outsourcing, COTS and Contracting Quality

Also See:

• QTP, CSTE, ISEB, ISTQB, CSQA Question Papers

Causal Analysis is to find causes that you can treat rather than treating symptoms. It provides the real reason why things happen and allows focused change activity.

A root cause is the basic reason why something happens and can be quite distant from the original effect.

Sources of information for causal analysis: Causal Analysis are triggered through one or more of the following ways:
• Reviews / Testing
• Audits of the quality system/projects
• Management Review Meetings
• Maintaining the quality system and deviations sought
• Customer complaints
• Problems / issues encountered at the project and organizational levels.

The goals of causal analysis are:

- To identify critical problem areas in a systematic way.
- Investigate and determine the root cause(s) of the nonconformance and document the root cause(s)
- Determine a plan to eliminate the root cause(s) of the nonconformance, taking into consideration the magnitude of the problem and the risk involved

1. Identify Crtical problems: The individual or team that encounters the problems shall organize a brainstorming meeting to identify the causes for the problem(s). Participants at the meeting shall include the individual or team that encounters the problem(s), experts in the domain and representatives of the Quality team and the Defect Prevention Analyst of the project. The lists of problem areas are determined, based on their impact on the performance of the team.

2. Identify causes and root causes: During the meeting, the participants define (or redefine if necessary) the problem for a precise understanding. Following this, brainstorming shall identify the possible causes of the problem. The causes of the problem shall also be prioritized and root causes are identified after eliminating others, the root cause of the problem is then documented appropriately.

The defect prevention group analyzing the problem shall use a combination of one or more of the following to identify the critical problem, possible causes and root causes:

Pareto analysis to seek out the vital few causes / characteristics known to contribute to the problem(s). Pareto Analysis is used to prioritize and attack the various causes that contribute to the problem so that the effect of the action taken would result in substantial improvement. Pareto Analysis is extensively used where quantitative data is available.

Cause-and-Effect Diagram or “Fishbone” diagram to visualize, clarify, link, identify and classify possible causes of a problem. Using Cause and Effect Diagram, a root cause analysis (WHY-WHY analysis) is done which helps in taking appropriate corrective action, to prevent the recurrence of the root cause, in future. The Cause and Effect Analysis is a qualitative technique and requires the involvement of team members since brainstorming will be used in conjunction with this tool.

3. Identify Corrective action: The participants of the meeting propose and discuss possible mitigation methods or strategies to correct the problem as well as to prevent the problem from occurring in future.The participants shall also decide on responsibilities assigned for acting on the action items identified, along with any risk perceived and target date for closure. The action items are tracked to closure and follow-up takes place during subsequent meetings.

Performing Causal analysis and preventive actions across the Organization: Causal analysis and appropriate preventive actions are performed at the following levels across the organization:
• Project / Work Group
• Organization

Project Level: The scope of a causal analysis at a project level is to identify critical problem areas with respect to Defects and Issues.

The project team members meet periodically to track the performance of the defects and issues along with the inputs given by the team members.

Based on the discussion, the team identifies, suitable intervals on a planned, as well as an event driven basis to perform causal analysis and determine suitable corrective actions and follow it up to closure. Causal analysis is performed at the end of a phase or once in a month, whichever is earlier. In cases where Phases overlap, Causal analysis for the current phase will be done before the start of the succeeding phase.

The team shall also track the effectiveness of such corrective actions periodically.
In order to support and prevent problems, the team shall initiate discussions and identify a suitable plan along with appropriate methods to prevent problems, as needed. The team shall also periodically, review the performance of such activities and identify suitable corrective actions.

Significant points resulting from these meetings shall be recorded and the minutes of meeting are circulated to all members of the project team. The Project Manager assigns responsibilities for any action items that arise and tracks the action items to closure. During project team meetings the entire project team shares their experiences with a view to identifying causes of problems that have occurred and to prevent known problems from recurring. Project Managers also use weekly project status reports to escalate problems to the department head.

The Project Managers shall also meet with the practice head / Delivery Head regularly. Project teams will also meet regularly at a periodicity defined in the project plan. These meetings discuss:

• Project progress
• Achievements of the project thus far
• Forthcoming project activities
• Distribution of responsibilities for forthcoming tasks

Workgroup Level: The heads of various workgroups shall schedule departmental meetings in order to

• Share information about departmental activities
• Share important and non-confidential news about happenings in the organization
• Address problems/Issues faced by the department as a whole.
• Identify and discuss relevant root causes
• Identify and follow-up appropriate corrective actions assigned

Departmental meetings shall serve as a forum for members of a department to share experiences and to discuss problems with a view to finding solutions and to prevent problems from recurring by discussions and causal analysis. One of the team members shall record significant points thrown-up during such meetings. The workgroup head shall assign responsibility for these action items and track the action items to closure.

Organizational Level: The heads of the various workgroups in the organization along-with the President, shall meet at regular intervals during SIR’s to discuss departmental issues and activities. These meetings will be held at least at monthly intervals and as required more frequently. During such meetings, the participants

• Discuss common issues and problems facing the work group.
• Share key information regarding work group activities.
• Attempt to resolve any pending inter-departmental interface problems.
• Discuss customer complaints of a critical nature affecting the entire organization.
• Share information regarding problems and preventive actions.

Minutes of the meetings shall be recorded and circulated to all participants. The workgroup head assigns responsibility for action items that are identified. The department heads, in turn, convey this information to the employees in the department during departmental meetings.

Formal quality assurance principles / fundamentals are based on a number of precepts that are not a good fit for the realities of software development today. Below are six precepts among the most prevalent-and erroneous-in the field today:

Assumption 1: Quality Requirements Dictate the Schedule

Fact For most software systems, market forces and competition dictate the schedule.

Traditional development model cannot keep up with the demand for consumer software products or the rapidly changing technology that supports them. Today’s rich development environment and ready consumer market has sparked the imagination of an enormous number of entrepreneurs. Consequently, this market is incredibly competitive and volatile. Product delivery schedules are often based on a first-to-market strategy. This strategy is well expressed in this 1997 quote from Roger Sherman, director of testing at Microsoft Corporation:

Schedule is often thought to be the enemy of quality, but at Microsoft it is considered to be part of the quality of the product.

Assumption 2: Quality = Reliability

This equation is interpreted as “zero defects is a requirement for a high-quality product.”

Fact: Reliability is only one component of the quality of a product.

The commercial software market is not willing to pay for a zero defect product or a 100% reliable product.

Users don’t care about faults that don’t ever become bugs, and users will forgive most bugs if they can work around them, especially if the features are great and if the price is right. For example, in many business network environments in 1994 and 1995, users religiously saved their work before trying to print it. The reason: About one in four print jobs submitted to a certain type of printer using a particular software printer driver would lock up the user’s workstation and result in the loss of any unsaved work. Even though many thousands of users were affected, the bug was tolerated for many months because the effects could be limited to simply rebooting the user’s workstation occasionally.

Safety critical and mission-critical applications are the notable exceptions to this fact. Consumers are willing to pay for reliability when the consequences of a failure are potentially lethal. However, the makers of these critical software systems are faced with the same market pressures from competition and constantly changing technology as the consumer software makers.

Assumption 3: Users Know What They Want

Fact: User expectations are vague and general, not detailed and feature-specific. This situation is especially true for business software products. This phenomenon has led to something that we call feature bloat

For example, if you asked several banking customers if they would like to be able to pay their bills online, many would say yes. But that response does not help the designer determine what type of bills customers will want to pay or how much they will use any particular type of payment feature. Consequently, in a well-funded development project, it is common to see every conceivable feature being implemented.

Assumption 4: The Requirements Will Be Correct

This fallacy assumes that designers can produce what the users want the first time, without actually building product or going through trial-and-error cycles.

Fact: Designers are commonly asked to design products using technology that is brand new and poorly understood. They are routinely asked to guess how the users will use the product, and they design the logic flow and interface based on those guesses.

Designers are people, and people evolve good designs through trial-and-error experimentation. Good requirements also evolve during development through trial-and-error experimentation. They are not written whole at the outset. A development process that does not allow sufficient time for design, test, and fix cycles will fail to produce the right product.

Assumption 5: Users Will Accept a Boring Product if the Features and Reliability Are Good.

Fact: To make an excellent product, we must consistently meet or exceed user expectations. For example, text-based Web browsers in cell phones have failed to captivate the consumer, even though they provide fast and efficient use of the slow data transmission rates inherent in the current cellular networks.

Software must be innovative in order to compete. The software leads the users to new accomplishments. Some examples of competitive innovations in the home consumer market include digital video editing, 3D animation, imaging, and video conferencing.

As corollaries of the preceding facts, the software must provide a competitive advantage to the business user and it must educate users.

Assumption 6: Product Maturity Is Required

Fact: Product maturity has little to do with the consumer’s buying decision. Price and availability are far more important considerations in most business scenarios.

The very mature premier high-end digital video creation software system has been supplanted by two new software editing systems that provide about 10 percent of the features it does, at 10 percent of the price. In addition, the new systems can be purchased and downloaded over the Internet, whereas the premier system cannot. We are also seeing this trend in large system software. The typical scenario involves dropping a massive, entrenched, expensive client/server system and replacing it with a lightweight, Web-based, database-driven application.

When analysis is performed on the current system, a frequent discovery is that the customers are paying for lots of features they are not using. Once the correct feature set has been determined, it can often be implemented quickly in a new Web-based application-where it can run very inexpensively.

Feature maturity is a far more important consideration than product maturity. As I have already pointed out, most consumers have realized that the latest release of software is not necessarily more reliable than the previous release. So product maturity is most often a myth. A mature product or system is typically overburdened by feature bloat.

For most software development organizations, ensuring quality means dealing with defects. Three generic ways to deal with defects include:

1) Defect Prevention
2) Defect Detection and removal
3) Defect Containment.

Defect prevention through error blocking or error source removal: These QA activities prevent certain types of faults from being injected into the software. Since errors are the missing or incorrect human actions that lead to the injection of faults into software systems, we can directly correct or block these actions, or remove the underlying causes for them. Therefore, defect prevention can be done in two generic ways:

- Eliminating certain error sources, such as eliminating ambiguities or correcting human misconceptions, which are the root causes for the errors.

- Faultprevention or blocking by directly correcting or blocking these missing or incorrect human actions. This group of techniques breaks the causal relation between error sources and faults through the use of certain tools and technologies, enforcement of certain process and product standards, etc.

Defect reduction through fault detection and removal: These QA alternatives detect and remove certain faults once they have been injected into the software systems. In fact, most traditional QA activities fall into this category. For example,

- Inspection directly detects and removes faults from the software code, design,
- Testing removes faults based on related failure observations during program execution etc.

Various other means, based on either static analyses or observations of dynamic executions, can be applied to reduce the number of faults in a software system.

We use defect detection and removal for the overall concept and activities related to what many people commonly call “debugging”.

When specific activities related to “debugging” are involved, we point the specifics out using more precisely defined terms, including,

- Specific activities related to defect discovery, including testing, inspection, etc.
- Specific follow-up activities after defect discovery, including defect diagnosis, analysis, fixing, and re-verification.

Defect containment through failure prevention and containment: These containment measures focus on the failures by either containing them to local areas so that there are no global failures observable to users, or limiting the damage caused by software system failures. Therefore, defect containment can be done in two generic ways:

- Some QA alternatives, such as the use of fault-tolerance techniques, break the causal relation between faults and failures so that local faults will not cause global failures, thus “tolerating” these local faults.

- A related extension to fault-tolerance is containment measures to avoid catastrophic consequences, such as death, personal injury, and severe property or environmental damages, in case of failures. For example, failure containment for real-time control software used in nuclear reactors may include concrete walls to encircle and contain radioactive material in case of reactor melt-down due to software failures, in order to prevent damage to environment and people’s health.

Various QA alternatives and related techniques can be used in a concerted effort to effectively and efficiently deal with defects and assure software quality. In the process of dealing with defects, various direct defect measurements and other indirect quality measurements (used as quality indicators) might be taken, often forming a multi-dimensional measurement space referred to as quality profile. These measurement results need to be analyzed using various models to provide quality assessment and feedback to the overall software development process.

By extension, quality engineering can also be viewed as defect management. In addition to the execution of the planned QA activities, quality engineering also includes:

- quality planning before specific QA activities are carried out,
- measurement, analysis, and feedback to monitor and control the QA activities

In this respect, much of quality planning can be viewed as estimation and planning for anticipated defects. Much of the feedback is provided in terms of various defect related quality assessments and predictions.

ISO-9126 offers a comprehensive framework to describe many attributes and properties we associate with quality. There is a strict hierarchy, where no sub-characteristics are shared among quality characteristics. However, certain product properties are linked to multiple quality characteristics or sub-characteristics. For example, various forms of redundancy affect both efficiency and maintainability.

Consequently, various alternative quality frameworks have been proposed to allow for more flexible relations among the different quality attributes or factors, and to facilitate a smooth transition from specific quality concerns to specific product properties and metrics.

ISO-9126 (ISO, 2001) provides a hierarchical framework for quality definition, organized into quality characteristics and sub-characteristics. There are six top-level quality characteristics, with each associated with its own exclusive (non-overlapping) sub-characteristics, as summarized below:

Functionality: A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. The sub-characteristics include:

- Suitability
- Accuracy
- Interoperability
- Security

Reliability: A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. The sub-characteristics include:

- Maturity
- Fault tolerance
- Recoverability

Usability: A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. The sub characteristics include:

- Understandability
- Learnability
- Operability

Efficiency: A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. The sub-characteristics include:

- Time behavior
- Resource behavior

Maintainability: A set of attributes that bear on the effort needed to make specified modifications. The sub-characteristics include:

- Analyzability
- Changeability
- Stability
- Testability

Portability: A set of attributes that bear on the ability of software to be transferred from one environment to another. The sub-characteristics include:

- Adaptability
- Installability
- Conformance
- Replaceability