Speaking in everyday, practical terms, I think it totally depends on the context.
In a med-large team, working to high / very high standards (think banking, military, large scale, high budget or business critical systems) then I think clearly "debugging" should be "a result of testing", and they are clearly very different things. Ideally testing leads to debugging (in a staging environment) and in production we need close to zero of either.
Testing is wide in scope, regular and very formalised - while debugging is a particular process that happens occasionally when there's a need to fix a particular failure - which is not obvious and requires a deeper investigation of a system's functioning and resultant outputs.
Here in my mind testing is something essential, while debugging is a specific tool needed only when the resolution to a failure is opaque.
I totally understand the obvious utility in TDD for large teams and or systems than simply cannot afford to be "buggy". It also clearly makes a lot of sense for complex (often "back-end") systems or if there is a high proportion of complexity in the code compared to the output. Then "testing" has a realistic chance of informing when and why failures occur. Systems that do a lot of complex work and or result in clearly measurable outputs are generally readily testable, and so testing is distinct from debugging. In these cases testing strongly implies a procedure based, formalised method of confirming or dis-confirming the match of expectations and actual output. Testing happens all the time, and occasionally informs us of the need for debugging.
It would be lovely if this was a ubiquitous truth, I'd love it if my dev cycles were delimited by clearly defined binary output (red, green) but...
In my case (which is admittedly particular - working 98% solo on small-mid sized, under-funded web based, data focused corporate admin systems) I just really can't see how TDD could possibly help me. Or rather "debugging" and "testing" are virtually the same.
Mainly though the use of the term "testing" implies / closely relates to the methodology of TDD.
I know this is a totally, utterly un-Zeitgeist "shun the non believer, shun, shun", despicably un-cool thing to say. But thinking about my context, with a practical hat on I just don't even vaguely, in my wildest imagination see how TDD could possibly help me deliver more value for money to my clients.
Or rather, I strongly disagree with the common assumption that "testing" is a formal code based process.
My basic objection (applicable in my particular *context*) is that...
If I cant write code that works reliably - then how the hell am I supposed to write code that works reliably to test said presumably sub standard code.
To me I have never seen any example nor argument that (in my particular context) enthused me sufficiently to even bother thinking about writing a single test, I could be writing some laughably insubstantial testing code right now, maybe "does my repository return a User entity with Name == X, when I ask it for exactly - and only - that?", but there's probably more utility in me writing this streaming, maybe-the-internet-really-is-just-pure-foolish-spouting-self-gratifying-wildly-under-informed-blood-boilinglyignorant-wastefully-silly trash, but I just feel the need to play devil's advocate here. (Kind of hoping someone will show me the light and convert me, maybe this will end up giving my clients better value for money?).
Arguably "debugging" sometimes is the same as "testing". By this I really mean that in my daily working life I spend at least a third of my time playing about with the local version of my system in different browsers, desperately trying various different wacky things out in an attempt to break my work and then investigating the reasons why it failed and correcting them.
I 100% agree with the obvious utility in the TDD mantra "red/green/refactor", but for me (working in low-med budget, solo dev RIA land) I would really really love for someone to please show me how I could possibly, logically and vitally realistically get any additional value from writing more (just as potentially flawed testing code) than I do from actually interacting with the full (and essentially only) output of my efforts which are essentially bound to real human interaction.
For me when developers talk about "testing" it generally implies TDD.
I try to code as if there were tests, I think all the patterns / practices and trends that all this testing focused development has encouraged are fantastic and beautiful, but for me in my little world "testing" is not writing more code, its actually testing real world outputs it in an approaching realistic manner, and that's virtually the same as debugging, or rather the active change here is the "debugging" which is a direct result of human, output centric non automated "testing". This is in contrast to the generally accepted view of "testing" as something automated and formal, and "debugging" as something human and ad-hoc or unstructured.
If the goal is really value for money / effort, and you're making web based interactive applications, then the output of the effort is the web pages and very essentially how they react to human input - so "testing" is best achieved by testing those web pages, through real human interaction. When this interaction leads to unexpected or undesirable outputs, then "debugging" occurs. Debugging is also closely related to the idea of real time inspection of program state. Testing is generally associated with automation which I think is often an unfortunate association.
If the goal is really value for effort, and automated testing is efficient and highly beneficial, while debugging is either just an output of that testing, or a poor substitute for automated testing, then why is the second most visited website in the world (Facebook) so often riddled with blindingly obvious (to users, but clearly not the testing team and testing code) bugs?
Maybe its because they're concentrating on the reassuring green lights and forgetting to actually use the outputs of their work?
Do too many developers think testing is something you do with code, and debugging is something you do occasionally with the IDE because an icon turns red and you can't work out why? I think these words have unfortunate value judgements associated with them, which generally obscure the practical reality of what we should focus on to close the gaps between expectations and outputs.