tag:blogger.com,1999:blog-4531176521073775656.post4928905038702992623..comments2016-06-30T10:15:11.067-07:00Comments on SQAEvangelist: Using the Agile Process makes testing activities more difficult, not easierMichael Burnsidehttp://www.blogger.com/profile/17119415588350045658noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-4531176521073775656.post-29703528178865795262013-07-01T20:48:34.044-07:002013-07-01T20:48:34.044-07:00Hi Rudnak and Jason, thanks for the great comments...Hi Rudnak and Jason, thanks for the great comments.<br /><br />In response to Rudnak: I would say that it is difficult to get the development team to complete all story tasks in 2 days, at least I have not yet been successful in convincing dev teams of the importance of this. Usually we do move stories into the next sprint if dev is not compkete by day 7 of a 10-day sprint because not enough testing will be done to verify acceptance criteria for new story implementation and regression.<br /><br />In response to Jason: I understand that the perception is waterfall method adjusted into an Agile process, but it really is not. There are certain tasks that need to be done as a team to allow for shared responsibility of test cases and acceptance criteria and then waiting for the developer to complete the development task and get the software ready for testing. There are many cases where testing cannot be done until the software is ready to be tested. In some case, you are right, some mock testing can be done in parallel until software is complete, but that is not always the case.Michael Burnsidehttps://www.blogger.com/profile/17119415588350045658noreply@blogger.comtag:blogger.com,1999:blog-4531176521073775656.post-71799498856607468032013-07-01T18:29:51.850-07:002013-07-01T18:29:51.850-07:00Micheal,
It sounds like what you're describin...Micheal,<br /><br />It sounds like what you're describing is more waterfall than agile. In an effective agile environment, you want to start testing activities as soon as the developer starts working on the feature. You should be involved in all the design and implementation meetings, and work with the developer on testing strategies for unit and functional tests. <br /><br />I believe that both developer and QE are responsible for delivering a feature and If the testing isn't done, then the developer needs chips in and writes tests or execute manual tests. When the testing is completed then the feature is moved to done. This will helps to keep developers from getting too far ahead. Anonymoushttps://www.blogger.com/profile/03282679214119098036noreply@blogger.comtag:blogger.com,1999:blog-4531176521073775656.post-28518542901243097762013-07-01T18:18:54.194-07:002013-07-01T18:18:54.194-07:00Rumadak,
I agree that you can let some feature c...Rumadak, <br /><br />I agree that you can let some feature complete items to slip into the next iteration. However, this may set the next iteration up for failure as you start the new iteration with negative equity. Really, the only way to make this work is to obviously evaluate the risk if this feature were to get released into the wild, and also to make considerations for the next iteration that will be impacted by the initial testing that wasn't initially planned.<br /><br />Also, be clear that this is an exception and not the rule.Anonymoushttps://www.blogger.com/profile/03282679214119098036noreply@blogger.comtag:blogger.com,1999:blog-4531176521073775656.post-91050267296556088642013-06-20T19:01:22.278-07:002013-06-20T19:01:22.278-07:00If you think development spans most of your sprint...If you think development spans most of your sprint, then maybe you should revisit the way the user stories are created. If you break down your epic in small enough user stories, it might be FULLY possible to complete each user story within 2 days.<br /><br />It generally depends on the way they are broken down. <br /><br />Moreover, team might allow dev completed items to slip into the next iteration for QA activities. We have been doing this for our current project and its working well for us.<br />Anonymousnoreply@blogger.com