<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 12:51 PM, Željko Filipin <span dir="ltr"><<a href="mailto:zfilipin@wikimedia.org" target="_blank">zfilipin@wikimedia.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div>On Tue, Aug 20, 2013 at 10:22 PM, Quim Gil <span dir="ltr"><<a href="mailto:qgil@wikimedia.org" target="_blank">qgil@wikimedia.org</a>></span> wrote:<br>


<div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Shouldn't the next step be a session practicing the step from plain English descriptions to Ruby test cases, running them with Cucumber.? This time the participants would focus on writing, failing, asking and succeeding.</blockquote>




</div><br></div>I think the majority of the participants of the workshop would still be catching up on how this browser automation thing works at all, so more training on that would be useful. I agree that failure analysis would be a good topic once when the majority of the participants are comfortable with writing the tests, but we are not there yet.</div>

</div></blockquote><div><br></div><div>I don't really see these sessions as sequential.  I like that they are granular and we can refer to them depending on context.  If someone wants only to write ATDD Cucumber Scenarios for a feature, there is a recorded online training session for that.  If someone wants to know how to write a test end-to-end, from Cucumber Scenarios through test steps to the Page Object, we have recordings of both the live session that I did in SF and the online session that Željko did. </div>

<div><br></div><div>Since this one would be live in SF, I suspect we would want to attract a large subset of those who attended the last live session in SF.  My idea is that a session with new content would be more likely to attract repeat visitors.  </div>

<div><br></div><div>I have two other motivations for doing a 'failure analysis' presentation besides providing new content: </div><div><br></div><div>For one thing, more people looking at our test results and asking questions about failures would benefit the project overall, and to my knowledge is there is essentially zero information about how to think about failures of Selenium tests in general.  </div>
<div><br></div><div>The other thing is that this project has always emphasized and tried to remove barriers to entry.  If someone does not want to create test scenarios or to code tests from scratch, I would like to spread the word that checking out automated test failures is valuable.  And it's fun to find a bug, too.  Sending mail to the list or filing a Bugzilla ticket saying "hey, I was looking at the failures in the Jenkins build, I checked the feature in my local browser and discovered that the Save button doesn't work any more!" is pretty cool.  </div>
<div><br></div><div>-Chris </div><div><br></div></div></div></div>