Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In quality engineering there are 3 phases:

1.quality assurance

2.quality control

3.quality measurement

Quality Engineering is defined as “the branch of engineering which deals with the principles and practice of product and service quality assurance and quality control”.

Quality assurance is a way of preventing mistakes. Quality control is the testing of product to uncover defects. But I am confused, why is quality engineering thought to be difficult?

share|improve this question

marked as duplicate by gnat, Doc Brown, Bart van Ingen Schenau, MichaelT, GlenH7 Mar 6 at 20:22

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2  
I think it is difficult because there's a near infinite amount of test-cases that could be created to test a system. –  Matthew Mar 6 at 15:20
    
When development gets off schedule, development time creeps into QA time. Less QA time makes it harder to test all cases –  DFord Mar 6 at 15:22
    
"quality engineering" is IMHO much less difficult than writing high quality software. –  Doc Brown Mar 6 at 15:40
1  
This question appears to be off-topic because it is about quality engineering, not about programming. –  Doc Brown Mar 6 at 15:40

1 Answer 1

Quality engineering can be quite subjective, and often your own stakeholders are working against you. And as we all know as software professionals, time is always against us.

Subjectiveness

Requirements can be pretty easy to test, e.g. "the edit user screen shall have two buttons to accept or reject the changes." Any lesser primate can look at the screen, see OK and Cancel buttons, and say the requirement is met.

Other requirements are difficult, such as performance. Even if the requirement is specific, there is often much left to interpretation: it is subjective, and especially near the deadline of a project, people will disagree about the requirement or say "what we have is good enough" when it is not. This means arguing, and often due to time constraints, the quality engineer loses.

Stakeholders

I have found that often customers will not understand what they need, not understand their own requirements, change their minds over time, and not update user stories.

What this means is while you are trying to validate requirements and ensure software quality, customers are simultaneously moving your target and possibly not even telling you.

Time

In a business, almost everything you do needs to have an economic justification. Quality engineering activities such as gathering and evaluating metrics, post-mortems, etc. tend to be rushed or discarded because hey, the software was delivered and it is time to move to the next project.

Enlightened employers realize these activities are investing in the future, not the present. They make the next project run smoother, deliver sooner, and with fewer defects (read: nonbillable hours). After all, this is one purpose of quality engineering.

When a quality engineer lacks sufficient time to do his job, he is unable to effect change in an organization that is beneficial. Without enough time, quality is a rush job and it is difficult to improve quality.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.