Testing is overrated

Software testing is the keystone of bugs discovery. Most of software engineers and project managers think this assertion is true!

But contrary examples exist:
Have a look at this blog article: Testing is overrated. Whereas software testing is truly a good way to find bugs, there are other ways to catch them: coding rules, peer reviews and the like.
A very good blog article!

Comments

Wanted to say I really enjoy reading your blog and find it an excellent resource.

My company develop a patient positioning system for radiotherapy linacs.

Currently we log all bugs in mantis. I am the only test engineer. When we release a maintenance build I construct a word test document which lists all mantis issues addressed.

We are currently in the process of releasing a big maintenance build which contains fixes for a lot of mantis issues.

The problem is everything gets piled into mantis including when developers are fixing issues found in new features (prior to release).

My question is, does the test document have to include all mantis issues for that release or can we just write tests for bugs that have come from customers? I.e real issues in the software not things developers have forgotten to do and raised as a mantis issue.

I'm hoping soon we will move to a Test management tool to streamline this whole process.

I think you only have to publish bugs fixes actually known by the customers.

It's a good idea to keep bugs fixed internally, when testing software, or reminders for developers. These items show that your development process is working. They should be shown to an auditor/inspector. But they don't have to be published to customers.

Hi MitchHad a question about issues which are found during development. We follow the agile way of working where all content to be worked is part of a prioritized backlog. So issues found during development time are solved in the iterations and is part of the done-ness of the story. At the end of development all issues have to be closed before starting final verification of the product. Do we need to identify and track the issues which are part of the regular work during development ? I know that from verification onwards all issues have to be identified and tracked