Is Testing Muda?

    The notion that testing is a "waste" has got me spun up for sure. Let's go back to basics and start from a solid foundation. The concept of "waste" in the Japanese manufacturing has crept into software development. And like many ideas that work well in one domain, they get diluted and perverted when move into another when the core principles are lost.
    The Seven Wastes of the Toyota Production System are:

1. Defects - prevent the customers from accepting the product produced.
2. Overproduction - is the production or acquisition of items before they are actually required.
3. Transportation - each time a product is moved it stands the risk of being damaged, lost, delayed, Add to that this cost has no added value.
4. Waiting - both the time spent by the workers waiting for resources to arrive, the queue for their products to empty as well as the capital sunk in goods and services that are not yet delivered to the customer.
5. Inventory - represents a capital outlay that has not yet produced an income either by the producer or for the consumer.
6. Motion - has significance to damage, wear, safety.
7. Overprocessing - using a more expensive or otherwise valuable resource than is needed for the task or adding features that are designed in but unneeded by the customer.

Now in the manufacturing business these are obvious "wastes." There is some connection to software development. But the lack of physical attributes of software restricts many of the applications of these concepts.
Is Testing a Waste?
    If quality or lack of quality is a "waste," then the question is

How can we assure quality - Quality Assurance?

This of course depends on the CONTEXT and DOMAIN.

Side Bar
    I can't tell you how many times some conversation has started about something around a process or project management topic in the absence of a CONTEXT and DOMAIN. The originator usually throws out some general comment like "testing is a waste." No context, no domain, no foundational principles.
    Using an extreme example. If you were an astronaut riding on the first manned mission of Orion to Low Earth Orbit, how would feel when some came along and said "we thought testing was a waste - no value to the customer, and add no value to the Guidance, Navigation and Control (GN&C) software, so we decided just to have peer reviews, and walk troughs and maybe a Clean Room for the software components."
raB ediS

So in the absence of a context and domain, the conversation is pure theory and no practice. So if we start with the TPS wastes and try to apply them to software what do we get?

1. Defects - build defect free software, using any and all the processes prescribed or known to reduce defects. Apply these process using a "returned value" decision approach. If testing is either mandated by contract, mandated by professional process, or is the best way, then it is not a waste.
2. Overproduction - this is a "just in time" inventory process. In software this can be assessed by the time value of money model. "At what point in the project should I own this software capability?"
3. Transportation - other than disk storage and bandwidth this is a non issue.
4. Waiting - the "just in time" model works here as well.
5. Inventory - since there is usually no "inventory tax" or "storage tax" this is not a real problem in the development of software, other than the cost to have built the product before its needed use.
6. Motion - efficient tools address  this.
7. Overprocessing - using the right resource, tool or process minimizes this.

So is Testing a Waste (Muda)?
    There is no answer in the absence of a context and domain. Any other answer - yes or no - is blather.