Why only focussing on bugs and quality?

Reading all kind of blogs, books and articles we all keep focussing on bugs and quality. There are persons who claim that finding bugs is the main goal for testers. Other people mentioning that we have to advice on quality.

Focus
Sometimes they write about skills other then testing skills like domain knowledge, technical skills, communication skills and more. And more often these skills are claimed to be needed to find more bugs or get better metrics how to present quality.

There are also people who use the words like "added value for customer" and are trying to proof this based on number of bugs the prevent to go into productive system. The pitfall I see in these approaches is that the view of the tester is narrowed from the start. They focus on how to find bugs fast or with certain coverage; they try to convince the customer about quality of a product. While focusing, they used their best practices and lessons learned based on these principles.

This raises the question by me: Are we doing the right thing and can we do better? Obviously we do, as the customer is happy and the product went live without major problems. Is it?

Doing right?
I often hear that if we have to go from A to B we have to know were we are, were A is and how we can get to A. Then we use our knowledge to get to B. During the journey moving towards B we adapt our approach. Another thing I hear often is: Why to invent the wheel again?

For this we use methods and approaches to start from A. We start testing and find the bugs as without no bugs in other men’s view we are not doing the right thing. because we are always under time pressure we tending to adapt our route to get to B to make sure that "our" process will not be the project failure. So w are not adjusting our approach to add value, we merely adjusting our approach to hide the failure of our lessons learned/best practices. If this is the case, are we doing the right thing? Are we focussing on the items which need focus?

Multiple processes
When hiring testers often are skills asked related to: domain knowledge, branch knowledge, programming knowledge, test tools, certifications about testing, communication skills, knowledge about programming methods and sometimes testing skills (something different then testing certifications). Indirectly they might support the test process as defined. Is this still a guarantee that bugs are found, that quality is proven?

If you answer this question with "Yes": Why is it that the benefits of this knowledge are not measured? As far as I know you have to pay for every bit of extra knowledge/skills. It seems that there must be some indirect value hidden behind this knowledge for the test process.

Re-focussing
This indirect value can only be a result of involvement of other processes. These processes providing information for the test process which is valuable. It is important to know what kind of impact this information has on the test process. For example: if branch knowledge is important, then we not only should define a test process which is using this knowledge, it also has to take care of gaining, interpreting and processing information from and towards the people who are working in that company. This is other information then number of bugs or visualization of quality.

I think we also should try to make the indirect value of information from other processes move to direct value. We should also focus on processes that generate information which has impact on the test process. This might result in manager who are able to value information from those processes and add value to them with respect to bugs and quality. This might lead to a situation that a product is shipped to production with unknown bugs and poor quality in certain areas, although it has more value for the processes when shipping it know then waiting when everything is uncovered and tested.

Testing becomes more
With this idea, testing becomes more then finding bugs or providing information about quality, it also process information from other processes and value the product and skills of team members against those processes. The focus of testing becomes broader then just the test process. the test process shall also value the information with respect to the other processes. Pieces will fall together.