Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
(2 of 2) In my experiences, showing documented processes for a subset of work and associated evidence is sufficient for many auditors, it seems to be in contradiction to AS9100, which is stated to apply to all product development activities (and not just hardware product development). Just because you happen to get lucky with auditors doesn't mean you're doing the right thing. My question boils down to If there's a general understanding that ISO9000 and AS9100 apply to all product development (including software), even if you claim to not recognize the software guidance in ISO90003 and AS9115.
(1 of 2) This doesn't really answer my question. I'm asking what you need to prove during an audit. In my example, AS9100 has requirements for critical items and key characteristics. However, those aren't defined for software in AS9100, but only in AS9115. I'm asking if it's acceptable to say "we ignore AS9115, so we don't have any requirements for software development". In this example, there is 0 documentation of processes surrounding critical items and key characteristics in software and 0 objective evidence of the work happening for software, but processes and evidence for hardware.
@PeterMasiar I think you underestimate Stack Exchange. Many people who are experts in many things post here, and this is the most likely site to attract someone who could answer my question. This is a well-written question that doesn't appear to have an answer elsewhere on the Internet and would be useful to many other people. I'm an expert in software development (check out my profile, particularly on Programmers) and I "waste time" (and by that, I mean contribute my knowledge with the world) on Stack Exchange.
@user970696 FAT is almost always tied to system specifications. Using it in this context would likely be incorrect. I don't know how you can say that these aren't "real testers" or that they aren't supposed to be "finding bugs". If they aren't supposed to be finding potential issues with the software, why do they exist? What value are they adding to the organization?
@user970696 So what? They are still testing your software before it goes live or is shipped. They get tasked with making sure your software doesn't have issues.
@user970696 I don't know what you mean by "not real testers". It sounds like they use your system and look for crashes or bugs. That's testing and looking for defects. Given this information, I'm going to revise my fourth paragraph.
I've never used defect seeding, but I suspect the problem is one that McConnell pointed out: you may forget to remove you seeded defects. The places that are best served by using defect seeding to determine the effectiveness of their testing processes are also the places that would be most impacted by leaving a defect in the system. I can think of ways to mitigate this problem, but it still comes down to a question of time and budget to deal with the seeding and testing not only the seeded code, but the unseeded/releasable code. I would like to here from someone who has tried it, though.
