Take the 2-minute tour ×
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.

In agile projects, we use the definition of done to ascertain when to consider a user story to be ready for acceptance (implemented and tested). In the project's DoD we have things like following among other things:

  • Unit tests implemented for new functionality and are all green (automated build and CI ensure this).
  • Acceptance/story tests are written and passing.(these are in a BDD tool)
  • Regression tests are green with known failures.(automated)
  • Enough exploratory testing has been done to ensure the correctness of new feature and to determine it works as expected
  • Unsolved defects are available in a DTS or the backlog.
  • Code coverage is above x%. New implementation have not caused any regression or impact on code covergae (i.e code covergae has either preferably improved or remained static since last sprint).

As a tester do you add anything more to this or is it enough ? In case yes; what would be the other things that would help me as a tester to make a decision on when to stop testing a specific user story and pick another one.

PS: I am looking for some guiding principles other than things like testers instinct or gut feeling .

share|improve this question

6 Answers 6

up vote 11 down vote accepted

Ideally, the DoD for each user story should mean all tests for that user story are passing, and all automation is completed, running as part of the overall automation (as opposed to on one person's machine), and running with no errors.

Real world usually means compromises, since there's rarely enough time or resource to cover all the potential implications of any given user story.

Factors to consider with your DoD would be:

  • Timeframe - do you have a 'hard' deadline or can you take the time you need? (or somewhere in between). The harder the deadline, the more your DoD will shift towards the steel thread. In that situation, testing anything that isn't steel threat becomes part of the project, and sometimes the development backlog.
  • External dependencies - the more your work relies on the performance of, or information from, a third party, the more room you need to leave in the DoD to cover failure in communication or performance on the part of the external supplier. Sometimes you need to explicitly state that DoD can't be achieved without Item X from Supplier Y.
  • Integration of user story does not cause regression in legacy functionality (You've added a new feature set as part of a sprint, but you haven't broken the way it used to work) - I think this is probably the only item that isn't explicitly on your list.
share|improve this answer
    
What is a steel thread? I couldn't understand the first point. –  Aruna Jun 13 '11 at 18:39
2  
Hi, Aruna. Steel thread or happy path is the items that absolutely must be implemented to complete the feature. These are the things you can't cut no matter what. –  Kate Paulk Jun 13 '11 at 19:15
    
Never heard the term steel thread, but I like it. +1 –  MichaelF Jun 13 '11 at 19:32
3  
The idea behind "steel thread" is that there is a single, focused feature/path being covered in any one user story. For example, a user story may say "A user will click button X in order to verify data record Y". Anything other than making sure button X verifies data record Y is not the steel thread. So, providing an option for reversing the verification, that's not steel thread and should be relegated to a different user story. –  TristaanOgre Jun 13 '11 at 19:40
1  
So are bugs found on the steel thread called steel bugs? –  dodgy_coder Oct 21 '11 at 7:24

In a previous life, we used Kanban and tasks with time estimates per task to define the work to be done and the time left on a user story. For us, the DoD was when all tasks for a particular user story were all moved to the "Verified" column on the KanBan.

The only problem with this is if there is an inaccuracy in determining what tasks need to be done. We did spend a lot of time in pre-Sprint planning meetings hashing out all the tasks and time estimates so, in good faith, we expect that everything that needed to get done for a user story got done. The possibility exists that we did not task for a unit test that should have been done, or that a particular data configuration was not covered, but, assuming that we did all our due diligence up front, this worked as a DoD.

In reality, what usually ended up happening was hard deadlines snuck up on us and we had to sacrifice our DoD to be only high priority tasks. This meant some things like code reviews, automated regression tests, and other tasks got thrown onto the backlog never to be seen again.

share|improve this answer

There are several useful heuristics for stopping testing. A few I can think of

  • 'No more time' - i.e. we stop due to a business imposed deadline.
  • Have you come to understand what you set out to understand about the feature (you do set specific goals for test sessions right?)
  • Mission critical bug unearthed at which point documenting and fixing the bug becomes higher priority than testing the feature.

Michael Bolton wrote a good blog post listing these (and a few extras) far more eloquently than I can.

share|improve this answer
    
+1 For Michael Bolton's blog post! –  dzieciou Nov 3 '12 at 13:35

My definition of done is generally "we don't have to worry about (e.g. touch, test, do ANYTHING with) that feature again in order to release the code.

One of the better discussions I've seen on this is this presentation last year by Ken Schwaber at a Canadian company called Pyxis, it's up on U-tube in three parts, the first part is here

share|improve this answer
    
+1 for the excellent reference and "we are done when no work is left to be done" :-) –  Rajneesh Jul 18 '11 at 11:51

The elephant in the room: maintenance.

How do we maintain this new feature:

  • what things need to be configurable?
  • can we easily roll this out (what's the roll out?)?
  • what support tools do we need to resolve issues with this in production quickly?

I worry that one day all of humanity will be maintining code of our forefathers... think of the children!

share|improve this answer
    
+1 for bringing in new points which mostly are ignored due to plain oversight. –  Rajneesh Jul 18 '11 at 11:27
    
If you are using proper engineering practices (pretty essential to be successful when building stuff via iterations) then the code as a whole tends to be easier to maintain. (the work done in the 'next iteration' is in many ways exactly like 'maintenance' of the code produced in the prior iteration. If support will need tools etc, the customer should be specifying that as some of the stories they want built during the project, along with things like configurable/customization features etc. In any case, trust me, you'd much rather maintain code produced by an Agile team than a BDUF team. –  Chuck van der Linden Jul 21 '11 at 23:29

I dont really have time to form an opinion of my own, but here's one from Michael Bolton, whose opinion I value & trust.

It may help you to make up your mind...

share|improve this answer
    
Could you summarize his opinion in your post? StackExchange etiquette frowns on answers that are a little more than a link. –  Kazark Feb 21 '13 at 21:21

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.