Showing posts with label QUALITY TESTING. Show all posts

Software Quality Factors

In defining the scope of testing, the risk factors become the basis or objective of testing. The objectives for many tests are associated with testing software quality factors. The software quality factors are attributes of the software that, if they are wanted and not present, pose a risk to the success of the software, and thus constitute a business risk.

For example, if the software is not easy to use, the resulting processing may be incorrect. The definition of the software quality factors and determining their priority enables the test process to be logically constructed.

When software quality factors are considered in the development of the test strategy, results from testing successfully meet your objectives.

The primary purpose of applying software quality factors in a software development program is to improve the quality of the software product. Rather than simply measuring, the concepts are based on achieving a positive influence on the product, to improve its development.

Identify Important Software Quality Factors

The following Figure illustrates the Diagram of Software Quality Factors .

The basic tool used to identify the important software quality factors is the Software Quality
Factor Survey form . The formal definitions of each of the eleven software quality factors are provided on that form.

QUALITY ASSURENCE AND CONTROL

Quality Assurance is a planned and systematic set of activities necessary to provide adequate confidence that products and services will conform to specified requirements and meet user needs. Quality assurance is a staff function, responsible for implementing the quality policy defined through the development and continuous improvement of software development processes.

It is an activity that establishes and evaluates the processes that produce products. If there is no need for process, there is no role for quality assurance. For example,quality assurance activities in an IT environment would determine the need for, acquire, or help install:

System development methodologies

Estimation processes

System maintenance processes

Requirements definition processes

Testing processes and standards

Once installed, quality assurance would measure these processes to identify weaknesses, and then correct those weaknesses to continually improve the process.

Quality Control

Quality control activities focus on identifying defects in the actual products produced. These activities begin at the start of the software development process with reviews of requirements, and continue until all application testing is complete.

It is possible to have quality control without quality assurance. For example, a test team may be in place to conduct system testing at the end of development, regardless of whether that system is produced using a software development methodology.

Both quality assurance and quality control are separate and distinct from the internal audit function. Internal Auditing is an independent appraisal activity within an organization for the review of operations, and is a service to management. It is a managerial control that by measuring and evaluating the effectiveness of other controls.

The following statements help differentiate quality control from quality assurance:

Quality control relates to a specific product or service.

Quality control verifies whether specific attribute(s) are in, or are not in, a specific product or service.

Quality control identifies defects for the primary purpose of correcting defects.

Quality control is the responsibility of the team/worker.

Quality control is concerned with a specific product.

65.3

RELATED POST

TESTING PROCESS PART THREE

WHAT TEST PLAN SHALL HAVE ?

SOFTWARE RELIABILITY

TEST DESIGN

DEFECT CLASSIFICATION

DEFECT TRACKING

TEST METRICS

TEST REPORTS

CHANGE REQUEST MANAGEMENT

UNIT TEST SPECIFICATIONS

UNIT TEST SPECIFICATIONS PART TWO

FUNCTIONAL FLOW MATRIX PART ONE

FUNCTIONAL FLOW MATRIX PART TWO

PROGRAM INSPECTION AND REVIEWS

CODE INSPECTION IN SOFTWARE TESTING

Software Quality Assurence Plan

The SQA Plan provides a road map for instituting software Quality. Developed by the SQA group, the plan serves as a template for SQA activities that are instituted for each software project.

A standard for SQA plans has been recommended by the IEEE. Initial sections describe the purpose and scope of the document and indicate those software process activities that are covered by quality. All documents noted in the SQA Plan are listed and all applicable standards are noted. The management section of the plan describes SQA's place in the organizational structure, SQA tasks and activities and their placement throughout the software process, and the organizational roles and responsibilities relative to product quality.

The documentation section describes (by reference) each of the work products produced as part of the software process. These include

• project documents (e.g., project plan)

• models (e.g., ERDs, class hierarchies)

• technical documents (e.g., specifications, test plans)

• user documents (e.g., help files)

In addition, this section defines the minimum set of work products that are acceptable to achieve high quality.

The standards, practices, and conventions section lists all applicable standards and practices that are applied during the software process (e.g., document standards coding standards, and review guidelines). In addition, all project, process, and (in some instances) product metrics that are to be collected as part of software engineering work are listed.

The reviews and audits section of the plan identifies the reviews and audits to be conducted by the software engineering team, the SQA group, and the customer. It provides an overview of the approach for each review and audit.

The test section references the Software test and Procedure. It also defines test record-keeping requirements. Problem reporting and corrective action defines procedures for reporting, tracking, and resolving errors and defects, and identifies the organizational responsibilities for these activities.

The remainder of the SQA Plan identifies the tools and methods that support SQA activities and tasks; references software configuration management procedures for controlling change; defines a contract management approach; establishes methods for assembling, safeguarding, and maintaining all records; identifies training required to meet the needs and defines methods for identifying, assessing, monitoring, and controlling risk.

Software is an umbrella activity that is applied at each step in the software process. SQA encompasses procedures for the effective application of methods and tools, formal technical reviews, testing strategies and techniques, poka-yoke devices, procedures for change control, procedures for assuring compliance to standards, and measurement and reporting mechanisms.

SQA is complicated by the complex nature of software quality—an attribute of computer programs that is defined as "conformance to explicitly and implicitly specified requirements." But when considered more generally, software quality encompasses many different product and process factors and related metrics.

Software reviews are one of the most important SQA activities. Reviews serve as filters throughout all software engineering activities, removing errors while they are relatively inexpensive to find and correct. The formal technical review is a stylized meeting that has been shown to be extremely effective in uncovering errors.

To properly conduct software quality assurance, data about the software engineering process should be collected, evaluated, and disseminated. Statistical SQA helps to improve the quality of the product and the software process itself. Software reliability models extend measurements, enabling collected defect data to be extrapolated into projected failure rates and reliability predictions.

RELATED POST

ERROR CHECK LIST FOR INSPECTIONS

WALK THROUGHS IN TESTING

TESTING FOR SPECIALIZED ENVIRONMENTS PART ONE

TESTING FOR SPECIALIZED ENVIRONMENTS PART TWO

VALIDATION TESTING

SYSTEM TESTING

DEBUGGING AND TESTING

DEFECT AMPLIFICATION AND REMOVAL

ITERATIVE SPIRAL MODEL

STANDARD WATER MODEL

CONFIGURATION MANAGEMENT

CONTROLLED TESTING ENVIRONMENT

RISK ANALYSIS PART ONE

RISK ANALYSIS PART TWO

BACK GROUND ISSUES

SOFTWARE REVIEWS PART ONE

SOFTWARE REVIEWS PART TWO

SOFTWARE RELIABILITY

SAFETY ASPECTS

MISTAKE PROOFING

SCRIPT ENVIRONMENT

V MODEL IN TESTING

SOFTWARE SAFETY

Before software was used in sarety critical systems, they were often controlled by conventional (nonprogrammable) mechanical and electronic devices. System safety techniques are designed to cope with random failures in these (nonprogrammable] systems. Human design errors are not considered since it is assumed that all faults caused by human errors can be avoided completely or removed prior to delivery and operation.

When software is used as part of the control, complexity can increase by an order of magnitude or more. Subtle design faults induced by human error—something that can be uncovered and eliminated in hardware-based conventional control—become much more difficult to uncover when software is used.

Software safety is a software quality activity that focuses on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If hazards can be identified early in the software engineering process, design features can be specified that will either eliminate or control potential hazards.

A modeling and analysis process is conducted as part of software safety. Initially, hazards are identified and categorized by risk. For example, some of the hazards associated with a computer-based cruise control for an automobile might be

• causes uncontrolled acceleration that cannot be stopped

• does not respond to depression of brake pedal (by turning off)

• does not engage when switch is activated

• slowly loses or gains speed

Once these system-level hazards are identified, analysis techniques are used to assign severity and probability of occurrence. To be effective, software must be analyzed in the context of the entire system.

For example, a subtle user input error (people are system components) may be magnified by a software fault to produce control data that improperly positions a mechanical device. If a set of external environmental conditions are met (and only if they are met), the improper position of the mechanical device will cause a disastrous failure.

Anylysis techniques such as fault tree analyse , real-time logic , or petri net models can be used to predict the chain of events that can cause hazards and the probability that each of the events will occur to create the chain.

Once hazards are identified and analyzed, safety-related requirements can be specified for the software. That is, the specification can contain a list of undesirable events and the desired system responses to these events. The role of software in managing undesirable events is then indicated.

Although software reliability and software safety are closely related to one another it is important to understand the subtle difference between them. However, the occurrence of a failure does not necessarily result in a hazard or mishap. Software safety examines the ways in which failures result in conditions that can lead to a mishap. That is, failures are not considered in a vacuum, but are evaluated in the context of an entire computer-based system.

VALIDATION TESTING

SYSTEM TESTING

DEBUGGING AND TESTING

DEFECT AMPLIFICATION AND REMOVAL

ITERATIVE SPIRAL MODEL

STANDARD WATER MODEL

CONFIGURATION MANAGEMENT

CONTROLLED TESTING ENVIRONMENT

RISK ANALYSIS PART ONE

RISK ANALYSIS PART TWO

BACK GROUND ISSUES

SOFTWARE REVIEWS PART ONE

SOFTWARE REVIEWS PART TWO

SOFTWARE RELIABILITY

SAFETY ASPECTS

MISTAKE PROOFING

SCRIPT ENVIRONMENT

V MODEL IN TESTING

STATISTICAL QUALITY ASSURANCE

Software quality can be achieved through competent analysis, design, coding, and testing, as well as through the application of formal technical reviews, a testing strategy, better control of software work products and the changes made to them, and the application of accepted software engineering standards. In addition, quality can be defined in terms of a broad array of quality factors and measured (indirectly) using a variety of indices and metrics.

A syntax and semantics can be defined for every programming language, and work is underway to develop a similarly rigorous approach to the specification of software requirements. If the requirements model (specification) and the programming language can be represented in a rigorous manner, it should be possible to apply mathematic proof of correctness to demonstrate that a program conforms exactly to its specifications.

Steps required to perform statistical SQA :

1. Information about software defects is collected and categorized.

2. An attempt is made to trace each defect to its underlying cause (e.g., non-conformance to specifications, design error, violation of standards, poor communication with the customer).

3. Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible causes), isolate the 20 percent (the "vital few").

4. Once the vital few causes have been identified, move to correct the problems that have caused the defects.

This relatively simple concept represents an important step towards the creation o: an adaptive software engineering process in which changes are made to improve those elements of the process that introduce error.

Statistical quality assurance techniques for software have been shown to provide substantial quality improvement . In some cases, software organizations have achieved a 50 percent reduction per year in defects after applying these techniques

Quality movement-software-testing

The first step of Quality movement is to develop a process (in this case, the software process) that is visible, repeatable, and measurable.

The second step examines intangibles that affect the process and works to optimize their impact on the process. For example, the software process may be affected by high staff turnover, which itself is caused by constant reorganization within a company. Maybe a stable organizational structure could do much to improve the quality of software. .

While the first two steps focus on the process, the next step, concentrates on the user of the product (in this case, software). In essence, by examining the way the user applies the product kansei leads to improvement in the product itself and, potentially, to the process that created it.

Final step broadens management concern beyond the immediate product. This is a business-oriented step that looks for opportunity in related areas identified by observing the use of the product in the marketplace.

SOFTWARE qualify testing

Even the most jaded software developers will agree that high quality software is an important goal. But how do we define quality? A wag once said, "Every program does something right, it just may not be the thing that we want it to do."

How do we define software quality?

Many definitions of software quality have been proposed in the literature. For our purposes, software quality is defined as

Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

There is little question that this definition could be modified or extended. In fact, a definitive definition of software quality could be debated endlessly.

1. Software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality.

2. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result.

3. A set of implicit requirements often goes unmentioned (e.g., the desire for ease of use and good

maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect.

Quality Assurance and cost

Quality assurance consists of the auditing and reporting functions of management. The goal of quality assurance is to provide management with the data necessary to be informed about product quality, thereby gaining insight and confidence that product quality is meeting its goals. Of course, if the data provided through quality assurance identify problems, it is management's responsibility to address the problems and apply the necessary resources to resolve quality issues.

Cost of Quality

The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities. Cost of quality studies are conducted to provide a baseline for the current cost of quality, identify opportunities for reducing the cost of quality, and provide a normalized basis of comparison. The basis of normalization is almost always dollars. Once we have normalized quality costs on a dollar basis, we have the necessary data to evaluate where the opportunities lie to improve our processes. Furthermore, we can evaluate the effect of changes in dollar-based terms.

What are the components of the cost of quality?

Quality costs may be divided into costs associated with prevention, appraisal, and failure. Prevention costs include

• quality planning

• formal technical reviews

• test equipment

• training

Appraisal costs include activities to gain insight into product condition the "first time through" each process. Examples of appraisal costs include

• in-process and interprocess inspection

• equipment calibration and maintenance

• testing

Failure costs are those that would disappear if no defects appeared before shipping a product to customers. Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs are incurred when we detect a defect in our product prior to shipment. Internal failure costs include

• rework

• repair

• failure mode analysis

External failure costs are associated with defects found after the product has been shipped to the customer. Examples of external failure costs are

• complaint resolution

• product return and replacement

• help line support

• warranty work

As expected, the relative costs to find and repair a defect increase dramatically as we go from prevention to detection to internal failure to external failure costs.

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique
Here i am adding the further topics list on software testing subject and the topics may be scattered and you can find under different groups.

MAJOR SYSTEM FAILURES IN THE HISTORY

WHAT IS A SOFTWARE BUG ?

ROLE OF A TESTER

SOFTWARE TESTING INTRODUCTION PART ONE

TESTING INTRODUCTION PART TWO

TESTING INTRODUCTION PART THREE

TESTING INTRODUCTIONS PART FOUR

SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

QUALITY CONTROL AND ASSURENCE

Quality is defined as "a characteristic or attribute of something." As an attribute of an item, quality refers to measurable characteristics— things we are able to compare to known standards such as length, color, electrical properties, and malleability. However, software, largely an intellectual entity, is more challenging to characterize than physical objects.

Quality of design refers to the characteristics that designers specify for an item.

The grade of materials, tolerances, and performance specifications all contribute to the quality of design. As higher-grade materials are used, tighter tolerances and greater levels of performance are specified, the design quality of a product increases, if the product is manufactured according to specifications.

Quality of conformance is the degree to which the design specifications are followed during manufacturing.

Again, the greater the degree of conformance, the higher is the level of quality of conformance.

“In software development, quality of design encompasses requirements, specifications, and the design of the system. Quality of conformance is an issue focused primarily on implementation. If the implementation follows the design and the resulting system meets its requirements and performance goals, conformance quality is high.”

User satisfaction = compliant product + good quality + delivery within budget and schedule

What is software quality control?

Variation control may be equated to quality control. But how do we achieve quality control? Quality control involves the series of inspections, reviews, and tests used throughout the software process to ensure each work product meets the requirements placed upon it. Quality control includes a feedback loop to the process that created the work product. The combination of measurement and feedback allows us to tune the process when the work products created fail to meet their specifications. This approach views quality control as part of the manufacturing process.

Quality control activities may be fully automated, entirely manual, or a combination of automated tools and human interaction. A key concept of quality control that all work products have defined, measurable specifications to which we may compare the output of each process. The feedback loop is essential to minimize defects produced.

3.1

Quality Assurance

Software quality is something you begin to worry about after code has been generated. Nothing could be further from the truth! Software quality assurance (SQA) is an umbrella activity that is applied throughout the software process.

1) explicitly define what is meant when you say “software quality,

(2) create a set of activities that will help ensure that every software engineering work product exhibits high quality,

(3) perform quality assurance activities on every software project,

(4) use metrics to develop strategies for improving your software process and, as a consequence, the quality of the end product.

Who does it?

Everyone involved in the software engineering process is responsible for quality.

Why is it important?

You can do it right, or you can do it over again. If a software team stresses quality in all software engineering activities, it reduces the amount of rework that it must do. That results in lower costs, and more importantly, improved time-to-market.

What are the steps?

Before software quality assurance activities can be initiated, it is important to define ‘software quality’ at a number of different levels of abstraction. Once you understand what quality is, a software team must identify a set of SQA activities that will filter errors out of work products before they are passed on.

What is the work product?

A software Quality Assurance Plan is created to define a software team’s SQA strategy. During analysis, design, and code generation, the primary SQA work product is the formal technical review summary report. During core produced. Other work prod-improvement may also be generated.

How do I ensure that I've done it right?

Find errors before they become defects! That is, work to improve your defect removal efficiency , thereby reducing the amount of rework that your software team has to perform.

SQA encompasses

(1) a quality management approach,

(2) effective software engineering technology (methods and tools),

(3) formal technical reviews that are applied throughout the software process,

(4) a multitiered testing strategy,

(5) control of software documentation and the changes made to it,

(6) a procedure to ensure compliance with software development standards (when applicable),

and

(7) measurement and reporting mechanisms.

2.2

Error Management in quality testing

An sound error management process ensures maximum efficiency for defect recognition and resolution during software development and deployment to production.

Objectives and Benefits

Maintain a defect tracking system to reliably monitor defects and fixes.
Preserve a history of defects and their fixes.
Ensure prompt and efficient identification and notification of defects
Provide timely fixes and deployment

Workflow Diagram: Defect Tracking

Error Review Team

The above workflow addresses only defects that are identified during development; it does not address the identification and resolution of production defects that are reported to or discovered. Production defects are errors that are identified in “live,” released software.

Because these defects hold high priority and need the most attention, an error review team (ERT) must be assigned to all live products. An ERT provides a prompt and efficient response to defect recognition in a production environment and ensures a timely resolution. The team will consist of the following members:

Development team leader
Project manager
QA team lead
Client representative

ERT Plan of action

When a defect in a production application is reported, the project ERT executes the following plan of action within four hours from the time the bug is reported:

1. All members of the ERT team are notified as soon as the defect is reported.

2. An immediate meeting is called with ERT and the client to discuss the details of the error, the environment, and the steps necessary to reproduce the defect. Known errors are reviewed to ensure that the defect is not a duplicate.

3. The defect is reproduced in-house or in a staging environment.

4. If valid, the defect is entered in the defect tracking system as OPEN.

5. The client is notified of the validity of the error.

6. Prioritization of valid errors is conducted.

7. Appropriate developers are notified.

8. A short-term resolution is discussed. (“How can we get the system functional ASAP?”)

9. A long-term resolution is discussed. (“What permanent changes need to implemented to prevent errors like this?”)

10. Client is contacted with the short- and long-term resolutions and the timelines.

11. The short-term resolution is implemented (Defect is marked FIXED in defect tracker with the resolution). Upon verification of the defect fix, the defect is marked as VERFIED and deployed to production. Upon successful deployment and confirmation from the client, the defect is marked CLOSED.

12. Long-term resolution is implemented, verified, and deployed.

Verification and Classification of Errors

The ERT plan of action calls for the team to classify and prioritize the error once it confirms the validity of a production defect. Valid errors will be classified as follows:

Critical: a serious error that is either a showstopper or of such importance as to radically affect the functionality of the system. Examples include:

A user is unable to complete a transaction because of a consistent crash during processing
Incorrect data is being passed resulting in heavy corruption or system crashes

Major: an error where a less important element of functionality is affected, or data which does not have a major impact is corrupted or lost. Examples include:

A value that is not defaulting correctly must be input manually.
A process is not being completed as intended, but there is an alternative method of completing the process

Minor: a minor error that does not hinder functionality. These types of errors are mainly cosmetic bugs.

Once the defect is classified and the development team has been notified, developers should provide a fix for “critical” errors within 24 hours. This is the turn-around time from when the defect is discussed at the ERT review meeting to when fix is released to the system test environment. (In the event that a critical error prevents the system from functioning, the turn-around should be significantly less.) ”Major” errors should be turned around in 36 hours; and ”minor” errors should be turned around in 48 hours.

Programming Portal

Top Tabs