All About Agile | Agile Development Made Easy!
Validation in Agile Development
Here's a question we were faced moving forward to Agile - we're all happy doing sprints, TDD and Unit Testing - but for us the definition of DONE must include the overall System functionality. So yes, we can implement functionality into user stories and implement them as such, but in the end we are building sub sets of feature set - most of which have some sort of dependancy; so to be sure (Safety Standards 61508 apply) the view is that the whole of the system needs to be tested as a unit - this then inevitably creates a bottlekneck at the end of the dev. cycle.
How does agile solve this situation ?
Views: 117
Replies to This Discussion
-
Permalink Reply by Patrick on -
Interesting you are using agile on an IEC 61508 project! My recommendation would be to build out each sub set, and have that definition of done include only your unit testing and whatever integration testing you can accomplish. For the safety testing, perhaps you can have a "Safety Certification Hardening" sprint that is executed when all the dependencies are in place and you can perform your overall system -ility testing. You can have user stories that reflect your safety objectives, and that can have a separate definition of "done" that reflects your safety objectives.
I am very interested in learning more about your efforts. It's rare that projects implementing safety critical software (61508, DO-178B) using an agile approach. If you'd like to discuss more, please feel free to contact me.
Thanks,
Pat
-
Permalink Reply by Sina Jazayeri on -
Thanks for your interest and insight about doing the Safety Certification Hardening" sprint. Some of the challenges here are the partitioning of safety and non-safety code to optimize development - and part of the difference is perhaps going to be the additional Saftey specific sprint.
-
Permalink Reply by Ilja Preuß on -
Are you doing Acceptance Testing?
-
Permalink Reply by Sina Jazayeri on
-
We're only starting to put together the framework for moving forward; there is general acceptance to move our processes into a more 'agile domain' - Acceptance testing is on the cards but again it 's the overall functionality that needs testing (in addition to individual components). The way I see it, there is no way of removing the 'validation bottlekneck' but agile methods will ensure the kneck of the bottle will be as wide as it can get !
-
Permalink Reply by Ilja Preuß on
-
I don't understand the "but" - in my book, Acceptance Testing *is* about testing overall functionality, unless I misunderstand what you mean by that term.
-
Permalink Reply by Sina Jazayeri on
-
I need to to understand the scope of acceptance testing - is it appied to a user story or to the system after it is deemed fully functional. So far what I understand is that we build testing (TDD and unit testing) into the development process - but I don't have a good picture of what in Agile terms is advised when you get to the end of an agreed Release backlog - what I've read points at the fact that at the end of each sprint you have a potentially shipable product - in reality the functionality build in during the X sprints to satifsy the Release requirements still needs Validating.
-
Permalink Reply by Ilja Preuß on
-
If done well, at the end of a sprint, all the developed functionality up to that sprint is validated by acceptance testing. For that to work, the acceptance testing needs to be automated, of course. Most teams write those acceptance tests in the same sprint the functionality is developed; for some teams, the PO/customer actually already brings the acceptance tests to the sprint planning meeting, to help communicate what is required for acceptance of a story.
Does that help?
-
Permalink Reply by Sina Jazayeri on
-
Let's say feature A was developed and done in Sprint 1. Feature B was done in Sprint 5; there is some indirect dependency between the two features. The question is does acceptance testing of feature B cover all dependencies it has with other sub-systems ?
-
Permalink Reply by Ilja Preuß on
-
What if it would?
What if it would not?
-
Permalink Reply by Sina Jazayeri on
-
so we write acceptance tests for a story - then we develop 10 stroies in the sprint. This point we have not doen anything that ensure the functionality of the 10 stories works well as a unit; so we haven't explored integration weeknesses. So as an activity to consider we have to look at every story implemented and its interactions with the system and write automated integratoin tests or perhaps we could call them OUR acceptance tests, not those specified by Customer or PO to ensure overall functionality so far. This could result reduing the final validation efforts.
-
Permalink Reply by Ilja Preuß on
-
I think I don't understand what kind of dependency you are thinking of that would make additional testing necessary. Do you have a concrete example?
-
-
Permalink Reply by Urs Enzler on -
We deal with our regulatory constraints in this way:
We use TDD and Acceptance Tests/Story Tests to ensure quality of individual units (TDD) and of integrated parts of the system (Automated Acceptance Tests).
Our System consists of a control unit where our software is running on and several instruments (hardware we control). All autmated tests use mocks for these external "components". Otherwise, they would run simply much too long.
Tests with the real hardware cannot be automated because the instruments need manual interaction (like pipetting, load and unload stuff and things).
Therefore, our system is tested manually on a release base (release in the sense of the result of several Sprints). All manual testing and validation and tracing needed to fufill regulatory constraints is done in this "release cycle". It is not contained in the Sprint cycle.
Okay, that leeds to some difficulties, which have to be controlled. For example, development and validation have to be in balance so that none of them gets a bottleneck of the other. Good engineering practices (like TDD) help in the way that it only a few defects survive till the validation step. But this is still extremely difficult.
Not a perfect solution regarding effort needed, but we don't see a better solution (yet) how to fulfill all regulatory constraints otherwise.
And to answer your question "How does agile solve this situation": agile doesn't solve it, but it helps to surface problems that would lead to poor quality or delays.
Cheers,
Urs
© 2012 Created by Kelly Waters.
