Testing in Organization

If we go in the early days of computing there were no specific,separate identifiable activity known as testing. Developers debugged their code, and that was usually intertwined with some unit of testing task. But that did not turn out to work.

Everyone starts their first job as a programmer.

The place place where they work they have to be assure for quality. so it turn out be a disaster of quality.

But the approach may not work still. It does not work for those throwback, Neanderthal organizations that rely on this approach entirely. It does not work for those cutting-edge companies that think some fancy language or process or tool has solved the software quality problem at last. It does not work for anyone, unless we define work as shift most costs of poor quality onto end users who are too stupid to know better or trapped in a monopolistic market without any real choice. And those organizations that rely on stupid users or a monopoly position had better hope they are right.

With the widespread advent of independent test teams in the late eighty and early ninety, we saw improvements. I was working in an independent test lab in the late eighty and as a test manager in the early ninety, and we made great strides. However, we also saw the emergence of a new dysfunction, the hurl it over the wall to the test guys and hold them responsible for delivered quality mistake. Every now and then, we work with organizations that still suffer from this problem.

Let’s be clear. When quality matters—and should not it always—everyone must play a role. Good testing involves a series of quality assurance filters. Each team in the organization typically participates in and owns one or more of these filters.

Thank you for reading… 🙂

Click here for government certification in Testing