Software in Medical Devices, by MD101 Consulting - Testing is overrated - CommentsBlog about software medical devices and their regulatory compliance. Main subjects are software validation, IEC 62304, ISO 13485, ISO 14971, CE mark 93/42 directive and 21 CFR part 820.2024-03-27T15:32:28+01:00Cyrille Michaudurn:md5:9c06172e7cd5ed0f5b192883b657eabbDotclearTesting is overrated - Mitchurn:md5:9fcca2a2413c41ccbabd5c7dfc2ab1632016-01-29T09:27:44+01:002016-01-29T09:28:18+01:00Mitch<p>Hi Matt,</p><p>I would say that it depends on the lifetime of the issues.</p><ul><li>Issues that are kept open from one sprint to another, of course yes. To remember what needs to be fixed.</li><li>Issues inside a sprint found by a tester, yes. To show that the tester has done his/her work.</li><li>Issues inside a sprint found by a developer and fixed by himself, or by a pair (if you do pairing rounds), probably no.</li></ul><p> Bye.</p>Testing is overrated - Matturn:md5:098f33f8caef724a84d80fea5d64823f2016-01-29T06:59:44+01:002016-01-29T09:22:54+01:00Matt<p>Hi Mitch<br />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</p>Testing is overrated - martinurn:md5:5b6d5309c4a8aaed800024ec54a55bd32014-05-23T12:57:48+02:002014-05-23T11:57:48+02:00martin<p>Mitch,</p>
<p>Many Thanks for your feedback, it was most useful.</p>
<p>Thanks,</p>
<p>Martin</p>Testing is overrated - Mitchurn:md5:d426c6a2b8ec202edfd8738009c8d1c22014-05-21T23:03:57+02:002014-05-21T22:03:57+02:00Mitch<p>Hi Martin,</p>
<p>Thank-you for your feedback.</p>
<p>I think you only have to publish bugs fixes actually known by the customers.</p>
<p>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. </p>Testing is overrated - martinurn:md5:fb6fa764bd39a035af93cbddf2e27aac2014-05-15T16:39:56+02:002014-05-15T15:39:56+02:00martin<p>Hi,</p>
<p>Wanted to say I really enjoy reading your blog and find it an excellent resource.</p>
<p>My company develop a patient positioning system for radiotherapy linacs.</p>
<p>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.</p>
<p>We are currently in the process of releasing a big maintenance build which contains fixes for a lot of mantis issues.</p>
<p>The problem is everything gets piled into mantis including when developers are fixing issues found in new features (prior to release).</p>
<p>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.</p>
<p>I'm hoping soon we will move to a Test management tool to streamline this whole process.</p>
<p>Thanks,</p>
<p>Martin</p>