If you want to learn about software testing, are the tools/technologies/skills the same across languages or do you need to learn different testing tools for each language?
As you can probably tell I don't know a single thing about software testing.
But I would like to learn about it.
If anyone could recommend a good book that applies across different languages, please do.
The overall process is the same, and each language has fairly interchangeable tools. For example, there is JUnit for Java, PyUnit for Python, and lisp-unit for Lisp.
I recommend learning the principles of software testing. JUnit in Action is a good book for learning the practical application of these principles.
They are not the same even in the same language. For instance, ScalaTest, ScalaCheck and Specs all feel very different, and ScalaCheck does something very different from ScalaTest and Specs, by generating random input instead of executing pre-defined scripts.
Furthermore, the language paradigm and even particulars about the language, such as it being typed or not, will change the things you need testing.
So, personally, I recommend finding a popular framework for the language you are most familiar with.
Wikipedia has a fair number of different tools and other things used within testing. It is worth noting that there are a variety of different types of testing,e.g. black box or white box testing, and different levels of testing,e.g. unit tests, integration tests, etc.
One other point is that some places will refer to testing as Quality Assurance and testers as Quality Analysts.
The general processes and best practices are the same across languages. You still want to test for boundary conditions, user input issues, integration issues, and so on.
The specific mechanics of using the various testing tools will vary depending on the tool being used. Automated test tools use a variety of languages and scripting techniques, so the syntax and details of using those tools will vary.
It's much like software development: the theories and high-level patterns are the same across languages, but the implementation details might vary based on the syntax and abilities of a particular language.
I dont know what you meant by bogus. But software testing is an important and integral part of any software development. So just do not call it "bogus" without knowing its importance.
And for your real question, there are totally different tools/frameworks available for different purposes. For unit tests, there are JUnit (for java), NUnit (for .net) etc etc. And for functional testing, there are tools like selenium (for webapps), White (for .net), etc..
Sure, there are differences. There are languages that don't allow programs with certain types of flaws:
Statically typed languages (without any casting to break type restrictions) guarantee that operations defined only on certain types will indeed only be called with values of those types
Unlike C/C++, a language can make it impossible to access memory that isn't properly allocated (including bounds checking of arrays), and impossible to corrupt the heap. Further, you could guarantee that all variables are initialized before use. But in practice, a tool like Valgrind can easily detect uses of uninitialized memory, memory leaks, or access to unallocated memory
A language may have an effect system (e.g. Haskell), where certain routines are pure, that is, having no side-effects - just transforming input values to output values. Testing those routines is much simpler; see "Quickcheck" for a nice scheme for generating random input values based on their types (you supply some properties of the outputs to check given the inputs).
A language may have a concurrency model which permits more or less subtle bugs (e.g. Erlang uses message passing only?). Shared memory threads, while having nice performance, can give bugs that are hard to detect. Alternate concurrency models are often implementable as libraries.
You need to understand whether some escape from the "safe" well-intentioned part of the language is used in the program. Usually one is available (Pascal had peek/poke, Haskell has unsafePerformIO, C/C++ have casts, and many languages support using arbitrary C libraries)
As for tools, obviously those that analyze source only support those languages whose source syntax+semantics they know.
Testing a whole program's behavior can be ridiculously complicated, but doesn't need to understand the source, and should be done to some extent. This can be done just using the program and its specification. You would still focus on different potential defects based on the properties of the language and libraries used.
Proofs of program correctness, testing tools, and tests may have bugs, but this doesn't mean that they're useless. In the case of tools and libraries (used to implement and run tests, or perform machine-assisted proofs), presumably any time a bug is discovered by any of the users of the tool, it's fixed for everyone.
Further, even if some tool bugs always remain, it just means that you get some false positives and negatives. As long as the benefit from finding the true positives (defects detected that are really bugs) exceeds the cost of investigating the false positives and creating the tests/proofs for the tool, you profit by it. False negatives are hardly a reason to drop the tool; they cost you nothing.
Not testing is equivalent to using a crappy test that always reports "no bugs here!", i.e. you have many false negatives and no true positives :)
It's true that you can't prove the absence of bugs by testing.