18

I am the development team lead of a new project at my company. This is the first project where the company will use Scrum. We have a waterfall/iterative SDLC. The BAs write requirements docs, hands over to dev and test, dev start developing and will release to testing in iterations. Testers take long time to test a release by which devs continue development but also bug fixes for the current release. I have a few questions

  1. In a sprint with say 5 stories when do you release for testing ? Is it as soon as a story is completed by dev or after all stories are completed but before end of sprint giving test the required time to test.
  2. If the BA writes user stories what should be the detail. Traditionally it takes long time to write a spec with all UI layout, behaviour, text etc to be finalised. I guess my question is how to write stories that are implementable and testable.
  3. Our test team is non-technical. How important it is to have automated UI testing for Scrum. The UI is based on WPF.

I have solid development experience using agile methods (TDD, code reviews, refactoring etc.) but new to scrum.

edit: By iterations I mean that if there are 100 requirements we may release to testing when we have finished 30, 35, 35 requirements rather than wait till all 100 requirements have been completed.

Improve this question
2
  • 4
    We have a waterfall/iterative SDLC. Elaborate on this. Waterfall is, by definition, a sequential process, not an iterative one. Although there are modified waterfalls (such as the sashimi model or waterfall-with-sub-projects), they are all sequential. Are you trying to move toward iterative processes from your current sequential process?
    – Thomas Owens ♦
    Dec 29, 2011 at 12:42
  • 1
    @Pratik how did things work out for you? Did you manage to end up cooperating better with the QA team?
    – flup
    Feb 17, 2014 at 21:05

5 Answers 5

Reset to default
13

If testing is separate from development, you have two -- separate -- scrum teams. It is a bad idea to have one hand work to the other.

Your developers must write their own tests, separate from this other team. You must treat this other "test" team as your customers.

In a sprint ... when do you release for testing ?

When the sprint is done. Totally done. That means you've done your own unit testing and are sure that it works. After your development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization.

I guess my question is how to write stories that are implementable and testable.

That varies from team to team. The BA is part of the development team. You have to work on that as a team (BA plus developers) to get the right amount of detail. It's a team effort to get the right information from BA to the rest of the team.

How important it is to have automated UI testing for Scrum.

Essential. Completely required for any UI development. The developers must do all testing themselves before it is given to the "test team". If there's a UI, they must test it. If there's no UI, then automated UI testing isn't required. Testing is required, and a UI must be tested. Automated testing is the current best practice.

Bottom line. A separate "test" team and a BA who writes every little detail is not an optimal organization for Scrum. Scrum means you have to rethink your organization as well as your processes.

Improve this answer
12
  • 6
    After you're development team is done, you release it to other teams for "testing" or "deployment" or whatever else happens in the organization. How is this any different than Iterative Waterfall? In this case the sprint is just a really short Waterfall Iteration. This sort of defeats one of the greatest strengths of Agile and Scrum IMO, that all BA's, Developers, and QA are together on the same team and they all collectively own the sprint that they are releasing. It breaks down the barriers that occur in projects.
    – maple_shaft ♦
    Dec 29, 2011 at 12:33
  • 4
    Can you elaborate on why automated UI testing is essential? Scrum is a project management framework that doesn't dictate any technical practices. The only references to testing that I can find with regards to Scrum that the Scrum Team is a cross-functional team. Although I would prefer automated testing, Scrum doesn't require any automated testing nor any testing at all, although passing tests should be part of the Definition of Done. It just says that any testing that is done is done by the team. Your bottom line is right - the current organizational structure is not well suited to Scrum.
    – Thomas Owens ♦
    Dec 29, 2011 at 13:23
  • 2
    The question is, copied right from the original post, emphasis added: "How important it is to have automated UI testing for Scrum." For Scrum, it's not important at all.
    – Thomas Owens ♦
    Dec 29, 2011 at 14:17
  • 2
    The wording in your answer makes it sound like automated UI testing is part of the Scrum process, and it isn't. But that doesn't mean it's not a good thing that should be done by the development team to improve quality. I agree it's a poorly worded question, but the distinction should be made between "is this required for Scrum" and "should completing automated UI testing be part of my definition of done for a story". Ultimately, the answer doesn't change, but becomes more clear as to why it's required.
    – Thomas Owens ♦
    Dec 29, 2011 at 14:26
  • 9
    Essential. Completely required. needs to be changed to reflect that it's not "essential" or "completly required" by the Scrum process framework. Right now, an uninformed reader would read this answer and make the conclusion that if you aren't performing automated UI testing, you aren't performing Scrum. That is a false conclusion, but completely understandable given the wording of this answer. There's a clear distinction between "something you should do" and "something mandated".
    – Thomas Owens ♦
    Dec 29, 2011 at 15:21
9

Most of the answers I am going to give relate to an Agile method of software development versus an Iterative Waterfall method. Scrum just happens to be a popular Agile implementation.

  1. In typical Scrum there is no seperate testing phase, because formal testing should occur throughout the entire sprint. As a developer finishes a User Story, the QA resource should already have his/her test cases prepared and begin testing at that point. If their test cases pass they Accept the user story and move to the next one. Once all User Stories have been completed and Accepted then the sprint is over and you begin the next one. This is all of course dependent on Continuous Integration, so development changes are immediately available to QA. Further development should follow TDD guidelines to ensure regression testing is as quick and painless as possible.

  2. It is a good idea for BA's to write user stories, but for more detailed and specific control, User Stories can accompany formal Requirements documents. The User Story should be written from the perspective of a single user by role. It expresses a need from the user's point of view, so quite naturally if the software currently satisfies all aspects of that need then the user story is being met. User stories can be comprised of child user stories and assignable Tasks. There may be overlap in Tasks for multiple user stories.

  3. Automated UI testing can be a good thing, but I personally feel that more effort on TDD methods and 100% unit test coverage of all Business Logic is more important. Most software development teams cannot seem to achieve 100% coverage of Business Logic, so in my opinion Automated UI Testing would be a waste of valuable time that could be used to write more unit tests for BL. It is a luxury not a need in my opinion.

Improve this answer
5
  • A genuine question regarding 1: if QA tests each User Story as soon as it is done, then moves to the next one, how do you check that a latter story within the same sprint hasn't broken (maybe in subtle ways) one of the User Stories which had already been tested? A sort of "regression within the same sprint". I'm talking about manual QA, not automated test suites, of course.
    – Andres F.
    Dec 29, 2011 at 15:38
  • @AndresF. If following TDD process along with CI, then if a check in breaks existing functionality then unit tests will fail and people will be notified. Of course this is only effective if 100% test coverage of business logic is in place, however simple logic, environment or integration issues, and presentation logic could still potentially have defects introduced in new user story development that go uncaught. Automated UI testing as suggested by S.Lott goes a long way to catch most of these, but ultimately, little more than a quick smoke test should spot these issues. cont...
    – maple_shaft ♦
    Dec 29, 2011 at 15:50
  • ...cont. If you find this is a recurring problem then you may have a deeper design flaws or issues that should be addressed such as tight coupling and low cohesion that make your code especially brittle.
    – maple_shaft ♦
    Dec 29, 2011 at 15:52
  • @maple_shaft: That is easy to say but QA doesn't like a release in the middle of their testing. Also we checkin frequently with CI build but release is done on demand only. The current test team is not capable of writing automatic UI test. They do purely manual testing. This would be difficult for me to change.
    – softveda
    Jan 3, 2012 at 9:47
  • @Pratik I understand how difficult it is believe me. I know the pain. Perhaps you can extend the sprint but have three or four releases to the test environment per sprint? This way the testing team can leave for the day in the middle of a test case and be assured the environment has not been changed overnight.
    – maple_shaft ♦
    Jan 3, 2012 at 12:07
4

  1. In Scrum, you're supposed to produce a potentially shippable software increment at the end of each sprint. As a result, Scrum promotes the concept of whole team or cross-functional team where every skill required to lead a given user story to done has to be present in the team.

    In my current project, since a fully-tested story is part of our definition of done, we have embedded testers in the teams. During the first few days of a sprint, while developers start working on the first user stories, the testers will prepare test scenarios and set up some test data. As soon as the dev for one of the user stories is finished, they'll test it.

  2. This is one of the biggest difficulties in Scrum IMO. You have to find the right amount of specification necessary to get an implementable, testable user story. Too much upfront analysis, documentation and specification will result in a rigid plan that will inevitably prove wrong over the course of the sprint. Conversely, a user story that hasn't been clearly defined and expressed by the Product Owner will lead to a saturated communication bandwidth between the developers and the PO during the Sprint and delays in development while the PO makes decisions about user stories halfway through the sprint.

    In our case, we have defined the right amount of detail for a user story to be 1/ a description in the form of "as a ... I want ... so that..." and 2/ a series of acceptance criteria. We seldom make mockups of the UI beforehand, it can happen during sprint plannings but they are more sketches that are discarded afterwards.

  3. In my experience, automated UI testing is extremely time-consuming and extremely brittle. There are ways to do that in WPF but I would carefully ponder the upkeep cost of such tests with the benefits before going that way.

Improve this answer
2

Working in shorter and shorter iterations makes all these handoffs more and more expensive. You can reduce these costs by following a stupid, simple rule: cut batch sizes in half, change how you work to make that comfortable, repeat until happy.

Take your 5-story sprint example. If your teams are accustomed to write the code for all 5 stories, then testing all 5 stories, then the batch size is 5 stories. Cut that in half. In the next sprint, work on the 3 most urgent stories first, getting them ready for testing as early as you can. As the testers are testing those 3 stories, the rest can get the remaining 2 stories ready for testing. This will cause some growing pains. Change how you work in order to make this more comfortable.

For example, more people will work on each story together, so try more pairing and see if that helps you work more steadily. Or, perhaps, the testers will find problems in story 2 that distracts some programmers while they're trying to work on story 5, so encourage the programmers and testers next sprint to discuss earlier how to test one of the story in the "first batch" so that the programmers are less likely to make a mistake that a tester can easy catch with a test.

It might take a few sprints to work out the big problems associated with testers testing a small batch of stories while the programmers work on the next batch of stories. Once it becomes comfortable, cut the batch size in half again. And again. Within a year or so, the team will be comfortably testing stories as the programmers believe they've finished with them and probably making fewer mistakes along the way. Each story will be done sooner.

Of course, at this point, now you can do the same thing with the batches that the team receives from the product owners, or that the team ships to the operations organisation. And so on. At this point, you can tackle the "how much detail should the BAs write for stories?" problem.

By the way: in order for the testers to be able to lower their turnaround time, they will have to adopt some automation, by some combination of learning how to automate and programmers helping them automate. As you try to reduce batch size, you'll find out when you need to fix those problems. Don't add automation just because a book says you need it.

I hope that helps you.

Improve this answer
0

Just want to share some experiences as below, hope that it's helpful to you.

In a sprint with say 5 stories when do you release for testing ? Is it as soon as a story is completed by dev or after all stories are completed but before end of sprint giving test the required time to test.

For each big user story, it should be broken down to many sub-tasks and when sub-tasks are completely done by developer, they should be released to QC for testing immediately. Defect should be fixed after testing for those sub-tasks finish testing.

If the BA writes user stories what should be the detail. Traditionally it takes long time to write a spec with all UI layout, behaviour, text etc to be finalised. I guess my question is how to write stories that are implementable and testable.

In Scrum, user stories should be in any format so long as the conversations surrounding the stories occur and not expected to be completed or static. A small story, called simply a user story, is one that is well understood and can be implemented within a sprint. A story’s priority can be based on ROI, business value, or whatever else the user agree is important. This is activities by PO.

Our test team is non-technical. How important it is to have automated UI testing for Scrum. The UI is based on WPF

Applying the automation testing in Scrum is quite difficult activity. Because all functions are implemented incompletely and not really stable to let QC implement the test case by some auto-testing tool. It should be done for a sprint called: regression.

Improve this answer

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