tools for software testing

Test is fun, just think for a second.
I proud my self to be an software developer, much more than an manager. I had hard times to think about me as a tester. I know quite a lot of people who dis-consider this activity. I understand them well, as I like a lot how one colleague who systematically try to avoid running documented tests.
Best colleagues I had in the university hated to make tests for others. This is also ok.

But the most efficient software developers I met had a great method to test their work. And this is crucial to deliver from the first time a great result.
Countries like India, Romania, Vietnam and many others (I hope) deliver a lot of test activities. A quarter of these are worthless logs to match the demands for SPICE, CMMI, internal and external audits. One of the reasons is that the test activities do not look for bugs outside of code.
One says that the tailor measures even 7 times, before he cuts once.
Evaluate your toolchain and check whether you are ready to cut, that is to write your tests for developing your software.
I reckon a few criteria in this respect, whether the toolchain meets your needs for productivity.
How much training you need before starting to use the tool chain?
I hate the tools which I cannot use in basic form in maximum two days. If the toolchain is too complicated, than the creativity and knowledge work is concentrated in avoiding the traps of the tool instead of improving the product. It is a decision of the manager, who has a great impact in productivity.
One could say that sophisticated tools are more powerful. Yes, indeed. Might be. But I dont have the time to master such a tool in today’s ever-changing environment.

How much out of total time of development is spent in setting up the mocks, stubs, in one word – to create the test environment?
I don’t know many software developers who enjoy setting up tools and scripts. These guys you can find in other IT areas, but not in development. On the other hand, it is highly expensive not to automatize this step and use the skills of developers in setting up the environment. If the tool is requiring this setup every time, than is not the right tool.
It is not necessary to be a sophisticated tool in order to meet your needs. Remember, all ingenious is simple (Thanks, Andrey for the saying).

I see as very productive tools like JUnit, CppUnit, Cute. I’ve also worked with RTR from IBM, a little bit of Tessy, as accredited tools. I have tried in my team some solutions based on Ruby, XML, C++ and my conclusion is that the best way is the one with less investment. Don’t try to save the world. Save your team’s time instead.

Is it possible to re-run the test cases in one year from now, with minimum effort?
Re-use is the buzz word these days. I would love to reuse the tests, not only the code.


Who can maintain the environment?
Do I need specialist to make things working? Do I have to pay a company to make this special setup?
This is a question to be answered for projects lasting more than 6 months.

What do I need?
It is often the case when engineers give up to their geek impulse and adopt a fancy and expensive tool, without the need of its power. It’s like buying a BMW 745d for commuting to next city, when you earn 30% of its value in one year.
Having a good tool, without a big investment is the biggest benefit.

How confident am I in the test approach?
All customers will speak highly about you when you deliver just minor patches, instead of big design updates. Testing is one key aspect to care about when you plan a new product.

Please comment these thoughts and add your approach.