tag:blogger.com,1999:blog-4886064834625370180.post4389887441722293194..comments2024-03-28T10:17:59.870+01:00Comments on Scrum FTW - Scrum for the win!: When Scrum meets traditional quality assuranceRichard Kronfälthttp://www.blogger.com/profile/03311642377622034282noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-4886064834625370180.post-37804959033662072862021-03-03T09:25:06.410+01:002021-03-03T09:25:06.410+01:00Thanks for sharing this.,
Leanpitch provides onlin...Thanks for sharing this.,<br />Leanpitch provides online training in Scrum Master during this lockdown period everyone can use it wisely.<br />Join Leanpitch 2 Days CSM Certification Workshop in different cities.<br /><br /><br /><a href="https://www.leanpitch.com/scrum-master-certification-online" rel="nofollow"><b>CSM online</b></a>srihttps://www.blogger.com/profile/10986893727829560363noreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-73607618290443336742014-05-15T13:22:56.809+02:002014-05-15T13:22:56.809+02:00Love the post!keep it upLove the post!keep it upJackeyhttp://www.pmstudy.comnoreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-48855245083677678722014-05-15T11:12:30.033+02:002014-05-15T11:12:30.033+02:00thanks for sharing such a wonderfull article!thanks for sharing such a wonderfull article!Mikahttp://www.scrumstudy.comnoreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-37082997517430392472010-11-27T11:17:18.366+01:002010-11-27T11:17:18.366+01:00These large companies, who can be a big mess, you ...These large companies, who can be a big mess, you have to use the software who visit the quality of the work of employees, if not the situation will get worse.software test consultinghttp://www.rbcs-us.comnoreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-61129261852611324982010-06-27T07:30:45.496+02:002010-06-27T07:30:45.496+02:00I actually enjoyed reading through this posting.Ma...I actually enjoyed reading through this posting.Many thanks.Scrum Processhttp://learnsoftwareprocesses.comnoreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-64581749014537617772009-06-02T17:34:25.476+02:002009-06-02T17:34:25.476+02:00Just wanted to add the URL to this very interestin...Just wanted to add the URL to this very interesting article by Per on this topic:<br />http://blog.crisp.se/perlundholm/2009/06/01/1243890906062.html<br /><br />Thanks for your comments, Per. I appriciate it. <br /><br />And as I wrote on your blog; I agree. Requirements are waste. If we can avoide writing requirements and writing bugreports alltogether, we certainly should. <br /><br />My suggestion is only a workaround in order to manage to cooperate with a non-agile department. Once we reach a point where the entire organization is agile I'm pretty sure the concept of "requirement specification" is history. But until then, I need a way to cooperate with the QA department.<br /><br />Btw, I really like the idea of bug reports being waste too!Richard Kronfälthttps://www.blogger.com/profile/03311642377622034282noreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-85851412341608696222009-06-01T22:07:35.781+02:002009-06-01T22:07:35.781+02:00To me, a test plan is something a tester or a test...To me, a test plan is something a tester or a test leader writes. But it is waste unless the creation of the plan discovers anything.<br /><br />To me, there may be requirements, but the only thing that defines the system, apart from itself, are the test cases. So the requirement spec is waste.<br /><br />User stories are not use cases and are not requirements, they are not form enough.<br /><br />Furthermore, a requirment spec will produce a need to write bug reports that compares the outcome of a test case with the requirment spec. Since the latter is waste, so is the bug report. You only need to know which test case failed.<br /><br />If the test competence is outside of your team, you need to hand over the result of "coding" and you get this discussion of "done-done". Both are waste. Handover requires procedures and they take time so they time between producing a bug and discovering it increases.<br /><br />IMHO, BTW. Keep it up.Perhttp://blog.crisp.se/perlundholmnoreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-40644674411917906622009-05-29T16:29:40.360+02:002009-05-29T16:29:40.360+02:00Very interesting.
So stories are not "Done-Done" ...Very interesting.<br /><br />So stories are not "Done-Done" until it has passed the testing (i.e. is moved to your "Done/Approved" column? And your velocity is lower for it, right? I.e. you don't count stories until they're "Done/Approved"?<br /><br />I'd like to use this approach too because it means that testing is really performed (by the QA resource(s)) inside each sprint, together with each story, and the story is - as you say - not considered done until it has been sufficiently tested. With my current approach, we call the story "Done-Done" when it fulfills the DoD, but the DoD doesnt include that the test cases should be written and executed; it just says that the requirements should be formulated and that the development team should have done unit tests.<br /><br />The reason why we do this and not your approach is that we have very short sprints; we have 1 week sprints. Our tester doesn't feel that's enough time to write test cases and perform the tests... <br /><br />Do you have any thoughts about this? How long are your sprints?Richard Kronfälthttps://www.blogger.com/profile/03311642377622034282noreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-64169302385679520302009-05-29T16:14:13.898+02:002009-05-29T16:14:13.898+02:00We have been/are in a similar situation. When each...We have been/are in a similar situation. When each story is done the developer has to write a little more detailed "How to Test". That, along with the "excpected outcome" (which can change along the way) often surfice for the QA resource to perform her duties. On our scrum board we have introduced "Ready for test", "In testing" and "Done/Approved". When we move stories into the "Ready for test" the QA resource can assign them to herself and read all the information needed (we use Jira to keep track of everything), perform the tests and fail or approve the story (we actually call them issues and that makes me somewhat confused at times since I'm used to stories... hehe).<br />I feel that this approach has been pretty easy to adopt and does not interfere that much with the workflow for the developers. One just have to get used to the fact that a story (sorry, issue) is not actually DONE just because you have completed your coding. And the QA resource feels like she's in the loop and up to speed.<br />As I understand it, just until recently the QA dept. used to work very unscrumish so it's nice to see that the transition to this has been so frictionless for all parties.Danielnoreply@blogger.comtag:blogger.com,1999:blog-4886064834625370180.post-31422458375716175792009-05-29T07:22:09.164+02:002009-05-29T07:22:09.164+02:00On this topic, I will recommend the excellent book...On this topic, I will recommend the excellent book "Agile Testing" by Lisa Crispin and Janet Gregory (Addison Wesley)Francohttp://www.martinig.ch/noreply@blogger.com