Tell me more ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.
up vote 2 down vote favorite

The StackExchange search seems to think this is a subjective question. I'm not sure about that. It seems pretty straightforward.

Agile methodologies of software development involve more than just the testing part of things. Developers, technical writers, and customer representatives (product owners) play a large part in the Agile world.

When it comes to regulated industries such as medical, financial, insurance, etc., however, there is a lot of formalized structure that needs to be satisfied. Formally documented specifications, design documents, test plans, test cases, risk assessments, etc., are all necessary in order to satisfy the different auditing agencies that all bases are covered and compliant with regulations.

Testing and Quality Assurance, however, are most heavily under the gun in these kinds of situations because we are the ones that are the "last line of defense" when it comes to making sure things are working well. When it comes to Agile development methodology as applies to testing, how do you satisfy all that required paper trail and other standard procedures and policies?

share|improve this question
In regards to the "subjective question quasher", I suspect the "How do you" is an automatic flag for subjectivity. In my experience, both on SO and this board, subjective questions answered based on experience and research and that meet the criteria in the FAQ welcome, and I feel unavoidable. I believe you cannot objectively answer a "how" question, because there are many ways to approach a problem, all equally valid (even if one is going to be the best) but that doesn't mean it's not allowed. There's a lot of subjective questions on SQA, and many are truly good questions. – corsiKa♦ May 16 '11 at 18:30
tl;dr The primary goal is to keep flaming/fighting to a minimum, and usefulness to a maximum. (Re: Signal to noise ratio) Objectivity lends itself to usefulness, but so can reasoned professional opinion! – corsiKa♦ May 16 '11 at 18:32

4 Answers

up vote 7 down vote accepted

I remember a couple of years ago sitting in a session about Exploratory Testing in regulated environments and having the same question: how can you use ET on environments requiring strict documentation of the tests being done and more-over auditing the traceability between requirements-design-testing-issues-verifications-etc.

Then I heard the explanation and it seemed trivial. You can use the part of ET that fits and still document what you did as part of your test execution. That's when I learned about SBT and how they actually matched their charters to requirements, etc.

But enough of ET and SBT. I think you can approach Agile Development in the same way and enjoy the good parts of the methodology while still complying with the requirements of your industry.

Specially around Agile, I think that if you make a really critical analysis you will reach the conclusion that there is nothing related to "Agile Testing" that cannot be also employed on Non-Agile (let's call it traditional?) methodologies. This prompted me to write a post in my blog about Agile Thinking instead of Agile Testing.

In any case I think that you should really understand what you like about Agile Testing and find the ways of applying this to your current methodology. My guess is that you will be able to implement 80% or more.

share|improve this answer
1  
Up voting. Nicely said Joel. I was going to say something similar, but you beat me to it. Tristaan, James Bach has spoken about achieving the paper trial objectives in a recent project he worked on (where he was helping to test medical equipment). They used a document-light, ET approach. A Google search might result in some interesting advice from James. (As if James gave any other kind of advice; always can always be counted on to keep things interesting). – Justin May 17 '11 at 6:21
up vote 4 down vote

I think the key here is to realize that documentation is no longer a task when you are in a regulated industry. It is now a released feature, with interested clients and external stakeholders that you need to satisfy. You should treat it like a user manual would be treated on a non-regulated project.

For our team, we deal with externally released documentation by putting the documents into the sprint as features to be released. We make estimates for these document user stories and treat them like any other user story on the sprint.

share|improve this answer
I like this way of thinking, it takes documentation out of the "as needed bucket" and moves it to a feature and in this case I think covers it nicely. – MichaelF Jun 10 '11 at 14:52
up vote 3 down vote

I had a similar question, which I posted on softwaretestingclub.com :

http://www.softwaretestingclub.com/forum/topics/ieee829-testing-standards-in

What i've taken from the answers, not only from the site, but also peers at my current client, is that there is still documentation in Agile, but less of it, and less up front. The information in your stories could be rolled up into official documentation as each story could effectively be seen as a micro v-model.

One response from Anna Baik really hit the point home for me :

"...the only way you can document your testing is by planning it all out up front! Is that really what the regulator wants to see, or do they want to see evidence of what testing you actually did, and how you decided whether it was enough?"

Anna also provided a link which be useful to you :

http://www.testingreflections.com/node/view/7771

share|improve this answer
up vote 0 down vote

copy pasting myself from elsewhere- The Agile manifesto says "working software over documentation", it doesn't say you shouldn't write documents at all if you have to. When Agile is used in real life it might be used with some adjustments, few examples from my experience- new HW is involved, the customer requires full specifications before any development is done, the SW is part of a larger system and requires approval from the system's architects. You can still work in short release periods delivering working SW, do LESS documentation, design LESS.

share|improve this answer
That seems to be the problem, though, at least within the company that I'm working. Perhaps it's just my perception but it seems that, when it comes to regulated industries, the idea of less documentation and less formalized design seems to go counter to what auditors of such regulated industries require. They want to know exactly what you did, how you did it, why you did what you did, etc., in order to make sure everything is within necessary compliance – TristaanOgre May 16 '11 at 13:56
I'm not an expert but have some experience with regulations. some of them requires the presence of documents, and auditors verify the documents actually exists, but not the contents itself or the format (I'm not totally correct here- for example you can use a spreadsheet, test file or mind map but will usually have to add dates and changelogs to all). Even NASA uses iterative methods to some extent and keeps the same quality level. – Rsf May 16 '11 at 15:11
What kinds of documents do you generate, then? You make a good point, but it seems, at least in my experience with Agile (which, to be honest, was NOT very well implemented IMO), the design, development, and even testing processes were VERY light on any formal documentation. There was no formal design spec, test plan, or documented test cases, just the User Stories and the brief task descriptions on the KanBan for Developer, Documentation, and Testing tasks. This might just be a very BAD implementation of Agile but its what I have to go on at this time. – TristaanOgre May 16 '11 at 15:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.