How do you integrate Testing into a Scrum process?

Question

This is really perplexing me. We have a 'definition of done' and it includes dev 'done', unit tests 'done', dev test 'done'. However we also have a user acceptance test that needs to be 'done' but the business wants to know when users stories are complete so that they can see stuff (the uat really isnt a priority until release). But because this is outside of the initial done (where we pass our user stories) how can we say its done? And where does this fit into estimating?

Where can I find information on integrating testing with a scrum process? I think I need to read up this...

score 19 · Answer 1 · answered Feb 27 '12 at 11:24

19

but the business wants to know when users stories are complete

It ain't done until your customer says it's done: any other definition of "done" is delusional. User acceptance tests are the success criteria for a user story: which is why they're called "user stories" not "management stories".

answered Feb 27 '12 at 11:24

1

In my experience, most users don't care how well a story was tested (until it breaks). A DoD is a great yardstick to know when something is ready for acceptance. – Feb 27 '12 at 17:30

score 4 · Answer 2 · answered Feb 27 '12 at 11:20

Typically, the definition of done includes more than what you are including, such as integration tests, acceptance tests, and documentation (both developer-oriented and user-oriented). Once unit tests pass, you can integrate the new feature/components and run integration tests. Once the feature is integrated, you execute the acceptance tests. Once acceptance tests pass, you can make sure any documentation is reflective of any recent changes and the feature is done. One problem is that acceptance testing shouldn't be a priority for a release, but a priority to verify and validate the completion of a story.

As far as estimating goes, your estimate should include everything from validation of the user story through acceptance testing. If you don't account for all of the activities and tasks needed to fully complete, integrate, verify, and validate the user story, the estimate doesn't add that much value. It might be a fairly simple feature to create and test, but incredibly difficult to integrate with your current design, meaning other features need to be refactored and retested. Not accounting for this means your velocity tracking will be off.

score 1 · Answer 3 · answered Feb 27 '12 at 15:30

I'd recommend sitting with the users or appropriate management and going over this issue in a lot more detail. Professional Software development means that you do testing, including for user stories.

You have to make this a priority. It's always easier to not address the issue and just keep writing more code and delivering more functionality. However this is not software that counts, and can be counted on, if part of the QA process is not working.

Focus on process and long-term benefits. "Changing your oil takes time" but you don't put it off forever or suddenly, one day, you get a nasty surprise! So you schedule maintenance, testing, whatever as just part of the software development process. Since you are trying to change an existing system I would recommend making this a bit more formal initially to get the process going. Focus on benefits (people like to hear) rather than current issues (people get defensive and question).

If the organization doesn't fully understand about professional software development you can either educate them or seek another place that does.

score 1 · Answer 4 · edited Feb 28 '12 at 08:26

1

The one thing I would 'RECOMMEND' doing is to implement automated testing. For example; if you are testing things in Windows Forms or C# or WPF use White.Core for testing. This will allow you to test new implementations, builds, features as quickly as possible.

I work as an Automation Engineer and I use White.Core in C++/C# while testing GUIs verifying dev fixes before an iteration is over.

edited Feb 28 '12 at 08:26

Jalayn

9,807

answered Feb 27 '12 at 16:55

Falcon165o

194

I would also like to stress that automating tests are not a total replacement for manually testing. It is a great tool for doing smoke tests to verify that the initial thought or idea works. :) – Falcon165o Feb 28 '12 at 15:02

score 0 · Answer 5 · answered Feb 27 '12 at 18:07

0

The disconnect between different states of done usually is a fabrication of project management desperately wanting to believe that the developers can completely hand off code to non-project resources for UAT and move on.

This is not Scrum. This is not Agile. This is an Agile Anti-Pattern.

There is only one state of "done" for a given user story and that is Accepted. A sprint is NOT over until every assigned user story in the sprint has been pushed out of scope for that sprint, or accepted.

Now a developer can be Complete with a user story meaning that it is ready for UAT, but the developer is really not off the hook until the user story has been accepted as a number of issues could be found during UAT that the developer must address before the end of the sprint.

All phases of design, documentation, implementation, and all types of testing should be accounted for in estimating a user story. QA or the entity that is to perform the UAT should be a project resource during sprint planning.

answered Feb 27 '12 at 18:07

maple_shaft

26,511
11
57
132

1

A sprint is NOT over until every assigned user story in the sprint has been pushed out of scope for that sprint, or accepted. In Scrum, a sprint (like most things) is timeboxed. At the end of the specified time (usually 2-4 weeks), a story must be done (integrated and accepted) or not done (not integrated and not accepted). If it's not done, it returns to the backlog for reprioritization, and the feature is not released (a user has no access to that functionality). I suppose, at the end of the sprint, all not-done stories are pushed out-of-scope, but that seems a weird way to think about it. – Thomas Owens Feb 27 '12 at 18:54
@ThomasOwens I suppose, at the end of the sprint, all not-done stories are pushed out-of-scope, but that seems a weird way to think about it. I don't think so at all. Merely suggesting that the the functionality behind a user story is not accessible to the user for unaccepted user stories at the end of the sprint seems stranger. Consider a simple user story that a developer works solely on for a 4 week sprint. He hurries it up to UAT before the end and some issues are found and there is no time to resolve them. The user story is not accepted that sprint. cont... – maple_shaft Feb 27 '12 at 20:24
... cont Just because the timeline was so tight there is also no time to back the changes out of the code base. The feature could exist in an unusable state at the end of that sprint or a mostly useable state at the end of the sprint but that goes against a core fundamental of Agile that promises a functional release at the end of every sprint. In reality one would have to accept the user story in its current flawed state. Any issues can be promoted to user stories. There are a number of ways that I have seen this handled, none of them ideal. One that I rarely see is backing out the feature. – maple_shaft Feb 27 '12 at 20:29

How do you integrate Testing into a Scrum process?

5 Answers5