Quotes



"Quality is never an accident; it is always the result of intelligent effort." -- John Ruskin

Saturday, January 3, 2026

WHAT QUALITY REALY MEANS (Beyond Testing)


When most people hear the word quality, they immediately think of testing.

Test cases.
Defects.
Bug counts.
Pass/fail reports.

While testing is important, quality is far bigger than testing. In fact, organizations that treat quality as a testing activity often struggle with cost overruns, rework, customer dissatisfaction, and burnout—even when their test coverage looks impressive.

True quality begins long before the first test case is written and continues long after the product is released.

This article explores what quality really means—based on data, proven frameworks, and real organizational behavior.


1. Quality Is a Business Outcome, Not a Department

According to IBM Systems Science Institute, fixing a defect in production costs 30–100 times more than fixing it in the design phase.

Yet many organizations invest heavily in late-stage testing while underinvesting in:

  • Requirements clarity

  • Process discipline

  • People capability

  • Decision quality

This is the first misconception to break:

Quality is not owned by QA.
Quality is owned by leadership.

When quality is treated as a department:

  • Teams optimize for passing tests, not delivering value

  • Defects are detected, not prevented

  • Firefighting becomes the culture

When quality is treated as a business outcome:

  • Decisions improve

  • Waste reduces

  • Trust increases—internally and externally


2. Quality Starts With Thinking, Not Checking

Testing is checking.
Quality is thinking.

Quality thinking asks:

  • Are we solving the right problem?

  • Do we understand who the customer is?

  • Are assumptions validated early?

  • Are trade-offs consciously made?

A study by Standish Group (CHAOS Report) repeatedly shows that over 60% of project failures are due to poor requirements and decision-making, not coding errors.

That means:

  • You cannot “test in” quality

  • You must design it in

Quality begins at:

  • Vision discussions

  • Requirement workshops

  • Architecture choices

  • Risk identification

Testing only confirms the consequences of earlier thinking—good or bad.


3. Process Quality Determines Product Quality

High-quality products rarely come from poor processes.

W. Edwards Deming famously said:

“A bad system will beat a good person every time.”

Data consistently supports this:

  • Organizations with defined and followed processes report 40–60% fewer production defects

  • Teams with stable workflows deliver predictable outcomes, even with average individual performers

Process quality includes:

  • Clear entry/exit criteria

  • Defined ownership

  • Feedback loops

  • Measurable outcomes

Without process quality:

  • Hero culture emerges

  • Knowledge remains tribal

  • Success becomes accidental

Quality is not speed vs process.
Good processes increase speed by reducing rework.


4. People Quality Is the Strongest Predictor of Sustainable Quality

Tools don’t create quality.
Processes don’t enforce quality.

People choose quality.

Organizations that invest in:

  • Skill development

  • Psychological safety

  • Ethical leadership

  • Learning culture

Consistently outperform those that rely on control and inspection.

Research by Google’s Project Aristotle found that psychological safety was the #1 factor behind high-performing teams—not tools, not seniority.

When people feel safe:

  • Problems surface early

  • Data is not manipulated

  • Improvement becomes continuous

When people fear blame:

  • Defects are hidden

  • Metrics are gamed

  • Quality degrades silently

True quality demands moral courage, not just technical competence.


5. Metrics Should Reveal Truth, Not Create Comfort

Many organizations are “data-rich but insight-poor.”

Common quality metrics fail because they:

  • Measure activity, not impact

  • Reward compliance, not improvement

  • Create false confidence

Examples:

  • High test pass rate ≠ high customer satisfaction

  • Low defect count ≠ low risk

  • On-time delivery ≠ right delivery

Good quality metrics:

  • Are uncomfortable

  • Trigger questions, not celebration

  • Connect effort to outcomes

Ask:

  • Are customers returning?

  • Are support tickets reducing?

  • Is rework decreasing quarter over quarter?

  • Are decisions becoming faster and better?

If metrics don’t change behavior, they are just decoration.


6. Quality Is Long-Term Thinking in a Short-Term World

Short-term optimization kills quality.

Cutting:

  • Reviews

  • Training

  • Root cause analysis

  • Preventive actions

May improve short-term numbers—but destroys long-term capability.

High-quality organizations think in years, not sprints.

They ask:

  • What capability are we building?

  • What technical debt are we creating?

  • What culture are we reinforcing?

Quality is the compound interest of good decisions repeated consistently.


7. Testing Is a Subset of Quality—An Important One, But Not the Whole

Let’s be clear:
Testing is essential.

But testing without:

  • Quality thinking

  • Process discipline

  • Leadership commitment

  • Ethical culture

Is like a smoke detector in a building designed to catch fire.

Testing detects problems.
Quality prevents them.


Final Thought: Quality Is a Way of Life

Quality is not:

  • A phase

  • A checklist

  • A certification

  • A role

Quality is:

  • How decisions are made

  • How people are treated

  • How problems are approached

  • How truth is handled

Organizations that understand this don’t just deliver better products.
They build trust, resilience, and long-term success.

Quality is not about perfection.
It is about responsibility.


Saturday, October 3, 2015

SEVEN PRACTICES TO IMPROVE SOFTWARE QUALITY

Analysts Margo Visitacion and Mike Gualtieri, offers practical and reality-based methods teams can make progress on improving their software quality. 

The analysts focus on removal of the top issues that plague application development teams.

Here are the brief notes taken directly from the Forrester report 'Seven Pragmatic Practices to Improve Software Quality':
 
 Practice 1: Define Quality to Match Your Needs

Impact on Quality: Meet business requirements; achieve a satisfying user experience.

Benefit: Your ability to achieve quality is improved because the application development team is not charged with unrealistically perfect expectations. Rather, it is chartered with a definition of quality that fits the given time, resource, and budget constraints.


Practice 2: Broadcast Simple Quality Metrics

Impact on Quality: Reduce defects.

Benefit: Highly visible metrics keep quality top of mind for the entire team and expose when efforts fall short.


Practice 3: Fine-Tune Team/Individual Goals to Include Quality

Impact on Quality: Meet business requirements; achieve a satisfying user experience; reduce defects.

Benefit: Team members perform according to their incentives, making quality improvement part of their goals reinforces desirable behavior.


Practice 4: Get the Requirements Right

Impact on Quality: Meet business requirements; achieve a satisfying user experience.

Benefit: Less rework means less retesting and fewer cycles, which greatly reduces the overall effort.

Practice 5: Test Smarter to Test Less

Impact on Quality: Reduce defects.

Benefit: A focus on testing the most crucial and at risk areas ensures that they receive the lion's share of test resources and that any bugs that slip through are likely to be confined to the least-important features.
 
Practice 6: Design Applications to Lessen Bug Risk

Impact on Quality: Reduce defects.

Benefit: Simpler, cleaner designs result in code that is simpler, cleaner, and easier to test and rework—which means that the code will have fewer bugs and that those bugs will be easier to diagnose and repair.

Practice 7: Optimize the Use of Testing Tools

Impact on Quality: Reduce defects.

Benefit: Automation frees resources from mundane testing to focus on the highest-priority tests and increases test cycles' repeatability.

Visitacion and Gualtieri conclude that software quality is a team sport, and everyone needs to play:

"Quality must move beyond the purview of just QA professionals to become an integrated part of the entire software development life cycle to reduce schedule-killing rework, improve user satisfaction, and reduce the risk of untested nonfunctional requirements such as security and performance," 

Source: www.cio.com

DEMING'S FOURTEEN POINTS OF QUALITY

1) Create constancy of purpose towards improvement of product and service.

2) Adopt the new philosophy. We can no longer live with commonly accepted levels of delay, mistakes and defective workmanship.

3) Cease dependence on mass inspection. Instead, require statistical evidence that quality is built in.
 
4) End the practice of awarding business on the basis of  price. 

5) Find problems. It is management’s job to work continually on the system. 

6) Institute modern methods of training on the job.

7) Institute modern methods of supervision of production workers. The responsibility of foremen must be changed from numbers to  quality.
 
8) Drive out fear, so that everyone may work effectively for the company.
 
9) Break down barriers between departments.

10) Eliminate numerical goals, posters and slogans for the workforce asking for new levels of productivity without providing methods.
 
11) Eliminate work standards that prescribe numerical quotas.
 
12) Remove barriers that stand between the hourly worker and their right to pride of workmanship.

13) Institute a vigorous program of education and retraining.
 
14) Create a structure in top management that will push on the above points every day

Source: pp-s.com

Thursday, December 30, 2010

GARVIN'S EIGHT DIMENSIONS OF QUALITY

Quality characteristics can be analyzed with the help of eight dimensions of product quality management. David Garvin has defined the concept in the form of Eight Dimensions of Quality. These are summarized here:

  1. Performance: Performance refers to a product's primary operating characteristics. This dimension of quality involves measurable attributes; brands can usually be ranked objectively on individual aspects of performance.
  2. Features: Features are additional characteristics that enhance the appeal of the product or service to the user.
  3. Reliability: Reliability is the likelihood that a product will not fail within a specific time period. This is a key element for users who need the product to work without fail.
  4. Conformance: Conformance is the precision with which the product or service meets the specified standards.
  5. Durability: Durability measures the length of a product’s life. When the product can be repaired, estimating durability is more complicated. The item will be used until it is no longer economical to operate it. This happens when the repair rate and the associated costs increase significantly.
  6. Serviceability: Serviceability is the speed with which the product can be put into service when it breaks down, as well as the competence and the behavior of the service person.
  7. Aesthetics: Aesthetics is the subjective dimension indicating the kind of response a user has to a product. It represents the individual’s personal preference.
  8. Perceived Quality: Perceived Quality is the quality attributed to a good or service based on indirect measures.
Source: Wikipedia

Friday, March 27, 2009

WHAT MAKES A GOOD TEST ENGINEER?

Characteristics of a good Test Engineer:
  • A ‘test to break’ attitude,
  • An ability to take the point of view of the customer,
  • A strong desire for quality, and an attention to detail.
  • Tact and diplomacy are useful in maintaining a cooperative relationship with developers,
  • An ability to communicate with both technical (developers) and non-technical (customers, management) people is useful.
  • Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming.
  • Judgment skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

Important Skills Required:
1. Communication Skill
Customer communication as well as team communication most important for this job. Written communication as well!

2. Technical skill
  • Knowledge of Project life cycle,
  • Knowledge of Testing concepts,
  • Knowledge of testing types,
  • Programming languages familiarity,
  • Knowledge of Database concepts,
  • Test plan idea,
  • Ability to analyze requirements,
  • Documentation skill,
  • Knowledge of Testing tools

3. Leadership Skill

4. Analytical and judging skill

Don’t worry if you don’t have some of the skills mentioned above. You can always learn the things if you have interest. Non-IT personas can also grow fast by gaining necessary skills.