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.