Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

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!


1. On Thursday 15 May 2014, 16:39 by martin


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.



2. On Wednesday 21 May 2014, 23:03 by Mitch

Hi Martin,

Thank-you for your feedback.

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. 

3. On Friday 23 May 2014, 12:57 by martin


Many Thanks for your feedback, it was most useful.



4. On Friday 29 January 2016, 06:59 by Matt

Hi Mitch
Had 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

5. On Friday 29 January 2016, 09:27 by Mitch

Hi Matt,

I would say that it depends on the lifetime of the issues.

  • Issues that are kept open from one sprint to another, of course yes. To remember what needs to be fixed.
  • Issues inside a sprint found by a tester, yes. To show that the tester has done his/her work.
  • Issues inside a sprint found by a developer and fixed by himself, or by a pair (if you do pairing rounds), probably no.


Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed