It's not a one size fits all proposition.
Testing is a technical vocation, performed by professional computer scientists throughout the software lifecycle.
Testing is assurance. It is the National Transportation Safety Board of software construction. It is there to prevent accident, to determine probable cause and to formulate safety recommendation.
Testing assures software correctly achieves stated requirements and allows objective measures and assessments as to the degree of this conformance. Critically, Testing provides a bedrock of assurance and reliability; the underpinnings of responsive and agile construction.
Testing can also grind software construction to a halt.
The potential to shut down progress is real. Testing has an extremely broad set of professional techniques each evolving within dramatically different environments and sharing only distantly related evolutionary pressures and influences. This breadth of technique is a reflection of the incredible spectrum of purpose for which software is applied, and the maturity of modern software construction practice.
Put simply, there are many more ways to apply the wrong technique than there are ways to correctly assemble a useful Testing strategy.
Think of Testing as the underwriter’s insurance of your project. Underwriting is the business of determining risk potential and quantifying the results of safety procedures.
If the one-and-only concern of the NTSB were safety, the investigative agency would simply ground all airplanes and close all roads.
Testing must consider the economy in which it operates.
Developers should definitely be testing the code they write. However, this is true not only for developers, but for everybody. Marketing, sales, operations and engineering should have metrics that they should be measured by.
The question is how much testing and what type of testing – these are business driven. For example if company values ‘time to market’ more than ‘quality’ that they will do very basic testing and check if there is demand for the product. Only if there is demand, they will invest more into product.
Developers – in my opinion they should ‘prove’ that the software meets the requirements (functional and system). These days it is easy to do: there are lots of techniques and tools.