As I'm sure you are aware, there are many different types of software testing, such as unit testing, integration testing, acceptance testing, etc. So it's kind of an umbrella term for all of those, and at this very high level of discussion, we can only really talk about "quality", as a broad term. You are simply validating the software against whatever measurements of acceptability you wish to apply. At different levels and types of testing, these will vary greatly, and the only real common ground is the quality aspect.
Bugs (as traditionally defined) are a specific type of problem with the software, but there are many others. Unless we're discussing a specific, lower level of testing, it doesn't make sense to limit the definition to bugs. Is a UI which is a bit too slow a bug? What about the fact that we forgot to tell the developers to add a basket to our web store? Perhaps the confusion comes in with specific types of testing being referred to as "software testing", but it's really just semantics.
If pushed to formalise the definition, I would say that testing is a process of validating the software against your requirements (which can be qualitative, too). A bug is just a very specific violation of requirements (specifically, one which the developer thought already worked correctly).
EDIT: I should probably add that the word "bug" has very different meanings to different people, and we should actually start this semantic discussion by defining it. I'm using the definition from a developer's perspective - this doesn't work as I (the developer) intended it. It is typically based on either a very specific requirement, or a very specific interpretation of a requirement. The client's definition is typically similar - this doesn't work as I (the client) intended it, which is a very different thing indeed. Using the latter definition, you could almost equate quality and bugs, because anything that doesn't meet the client's wishes is a "bug".