Software in Medical Devices, by MD101 Consulting

Comments

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

Hi,

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.

Thanks,

Martin

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

Mitch,

Many Thanks for your feedback, it was most useful.

Thanks,

Martin

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.

 Bye.