I'm not sure how to pose this question, as I'm not sure what answer I'm actually looking for.


I've recently started on an Agile project & I'm now fully onboard, certainly with my current clients understanding of Agile (I'm reading around to get other peoples understanding of Agile)


What I've noticed, & what I don't miss, is all the paperwork - the testing documentation I used to have to create in order to support my testing, which invariably would be out of date as soon as it was created and left to collect dust on my desk.


Now, we don't refer to the IEEE standards directly on my current project, but I'm sure they're in the system somewhere!


So, I guess my question is: how do you guys manage the IEEE standards within an Agile environment, if at all please?.


If someone could point me to some articles / blogs / resources it'd be greatly appreciated!


Thanks in advance,




Views: 841

Reply to This

Replies to This Discussion

The Agile manifesto says "working software over documentation", it doesn't say you shouldn't write documents at all if you have to

I prefer to use ATDD in combination with an balanced session-based exploratory testing approach.


You can visualize the testing progress by either putting the sessions on your taskboard directly, or by using a low-tech testing dashboard.


With ATDD you enable your team to implement the right thing from the start rather then getting lost in rework after rework.


Here's a link on one of my blog entries on collaborative chartering for exploratory testing: http://www.shino.de/2011/01/05/collaborative-test-chartering/

For more on testing dashboards, here are some more links:

Looking for more on ATDD, here some pointers:

  • Gojko Adzic's books "Bridging the Communication Gap" and "Specification By Example" are great overviews
  • Ken Pugh has also written a book on ATDD called "Lean-Agile Acceptance Test-Driven-Development" with some examples that I contributed

You may also be interested in Lisa Crispin's and Janet Gregory's book on "Agile Testing" which gives you a great overview about the testing quadrants, and how a whole iteration from the perspective of a tester looks like.

I'm going to implement a dashboard today - will keep you posted.


It only needs to be simple as we already have a fair amount of the progress of the story on our story wall, so I don't want to dupe the effort!

Thanks for the replies - they're greatly appreciated.


@Rsf - Does that imply that companies who need documentation (i.e. IEEE) to conform to certain regulations would struggle to operate in an Agile environment?

Or can the slim docs created as part of the Agile process being adapted to conform to IEEE?


@Markus - Thanks for all the links! I've just started looking the Specification by Example from Gojko (great podast here of an implementation of Spec by Example : http://skillsmatter.com/podcast/agile-testing/specification-by-exam...).


I'm also currently dipping into "Agile Testing" - great read. Its kind of on the back burner at the moment as I'm wading through other testing / agile / development books.


I'll have a read of links later, thanks again.


From my reading / asking around, its appearing more & more like that if require documentation of a particular standard as evidence of testing, you'll struggle to be agile.


I'm sure there are companies operating in safety critical systems who are agile - I'd love to know how they operate. 

first of all I am not an expert in regulation conformance nor Agile, I am answering only based on some experience with both.

When Agile is used in real life it is 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.


Cheers Rsf.


I had a good description given to me today - imagine each story follows its own v-model. Or kind of.


Effectively (although why would you want to?), you could roll up the elements in the story such as Business Requirements, Acceptance Criteria, Test Levels into the IEEE documentation.

I've also moved from a traditional waterfall style background to an Agile team relatively recently. The big issue I suspect you may be having difficulty with, having come from a non-Agile environment to an Agile one, is the shift between focusing most documentation effort on what you plan to test, versus focusing it on what you did test, and how you made those decisions


The degree of documentation you need to deliver should be driven by your stakeholders demands - if you're in a regulated industry, you may find that the delivered product needs to be both working software, and associated documentation - there is nothing un-Agile about that. However, I would recommend against falling into the trap of thinking that 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?


Karen Johnson had a great chapter in Beautiful Testing about testing medical equipment - unfortunately my copy is at work, so I can't tell you more details about it, but I think you would find it interesting to read if you are in that field, and if you're not, it's a terrific story anyway.


Here's a post from her blog referring to WREST, which sounds like it might be worth following up for you:



Thanks for the reply Anna - greatly appreciated.


What really is resounding with me is the comment "...or do they want to see evidence of what testing you actually did, and how you decided whether it was enough?"


That really helps me formulate an answer & ties in nicely with feedback from others.


Thanks again,





© 2017   Created by Rosie Sherry.   Powered by

Badges  |  Report an Issue  |  Terms of Service