Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
3  
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 '11 at 12:42
    
@Pratik how did things work out for you? Did you manage to end up cooperating better with the QA team? –  flup Feb 17 at 21:05
add comment

3 Answers 3

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 you're 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.

share|improve this answer
4  
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 '11 at 12:33
3  
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 '11 at 13:23
1  
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 '11 at 14:17
1  
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 '11 at 14:26
5  
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 '11 at 15:21
show 7 more comments

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.

share|improve this answer
    
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 '11 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 '11 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 '11 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. –  Pratik Jan 3 '12 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 '12 at 12:07
add comment
  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.

share|improve this answer
add comment

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.