Fumbling at Finding things with Selenium

Finding things with Selenium

At it's root this is easy enough.  Just call findElement() on the driver and give it some matching - we've been using css selector - and viola.  Then I wanted it to be visible - so just call .isDisplayed() on the element, but I kept getting false.

I should note that I was adding this to some functional tests being run against our hybrid mobile application.  So I could track down the css styles viewing it in a browser I'm not sure how to map the Selenium element I'm getting in our tests to the same thing.  (Any pointers would be appreciated. :))  This left me fumbling around wondering why I wasn't matching what I was seeing in the browser.

Then I thought to search for the css selector I was matching on and realized there were two of them on the page and that I need to add another part to the selector.  Not one of my proudest moments - I'd like to blame that I'm not always/often working with css and it takes a bit for my brain to get into debugging when it doesn't work off the bat.

Vagrant

So I had hoped to dig more into vagrant...and I sort of did.  I touched base with our systems team since they use puppet and I was hoping to make use of what they did to quicken things up.  Turns out they use vagrant to test out their puppet scripts, but they don't have access that they'd like to share...yet.  I'm hoping to keep poking at that and get an appropriate access created!

Exploring vagrant and volunteering

Exploring Vagrant

Recently I listened to Ruby Rogues podcast where they chat with Mitchell Hashimoto, the creator of vagrant.  Which I'm sad to say that while I've heard of it I haven't dug into at all.  (This even came up during a hackathon at my company, but I was working on something else.)

We have a dependency on another project that's fairly complex to setup and run locally.  Recently there's been some work done to puppet-ize the setup of the servers for standing up new servers.  Looking through the vagrant docs it seems that it would be easy to make use of that.  Along with the ability to control multiple boxes it seems like it should be easy to setup.  I'm looking forward to exploring this more next week.

Volunteering with Vermont Works for Women

I had the pleasure of TAing during one of the Step Up to IT classes.  It was awesome to see the enthusiasm and drive of all the attendees.  I've certainly been getting more interest in mentoring these past couple years and this was a great day for me.  I'm TAing for two other classes coming up and look forward to see how things progress.

Random Star Trek Bonus

I recently became aware of Star Trek Continues.  I'm still trying to determine how much I like it, but it certainly gets high marks for it stay true to the original series.  The first three episodes they have out are enjoyable.  Needless to say I'm keeping my eye on their latest "Kirkstarter" while I figure out if and how much I should donate. :)

Moving to Rally

Recently my company, in an effort to increase visibility of work and help organize things, has transitioned from Jira to Rally.  Not unsurprisingly we're dealing with learning how to use the new system and the differences between them.  My team likes the flexibility of being remote - at times we've had half the team working remotely - so we don't have a physical board and are keeping things all in the tool.

Here are some of the issues we're having that we have yet to find a work around:

1. Handle unfinished work from an iteration
   
   Rally gives some advice around this, but nothing that just works.  Some options and their downsides:
   
   
   1. Move the story to the new iteration.  You lose sight that it was in a previous iteration so the planned points goes down.
   2. Split the story - which by default creates a second story with the same number of points in the upcoming iteration.  Unfortunately, if you're doing any reporting like the release burnup, then this gets a double shot of points from this one story.  The suggestion in this case is to zero out the points for the left over work, which of course changes the points planned in the last sprint. 
   
   Nothing provides a solution that maintains both the closed iterations planned and actual points as well as the release burnup.
   
2. Starting and stopping an iteration
   
   It doesn't appear to allow any flexibility in the time an iteration is to close - so midnight on the day indicated is when it happens.  Historically, my team has closed the sprint after daily standup (which we do at 10:15) on the day we're planning our iterations.  Which immediately afterward we do our planning for the next iteration.  Since it's all automatic, we'd have to close things up the night before so that any reports look reasonable and aren't missing our last morning of work.  This just seems too rigid and I'm not sure what the benefit is versus our being able to indicate we're done with the iteration.
   
3. Identify what stories/features are being released
   
   Rally has introduced milestones that seemed to be a perfect fit for this.  These can be applied to portfolio items and stories.  However, I have yet to find a way to view everything it has been applied to in one view.  So while I add the milestone to everything I can't a view that will show everything that's going out in the release.
   
   Some of this I'd take as a challenge to avoid working on things that aren't going to get released, but I've learned that reality gets in the way.  So it's not impossible to figure out what's getting released I just prefer indicating it as soon as I know and having a single place where people can look at it.

Some things we've found work arounds for that we're not really satisfied about:

1. Unable to view defects on Task Board view
   
   I've honestly found Defects to be next to useless.  Maybe they work better with the test plans, but they behave differently than tasks and stories.  In the end they are work that needs to get done, but they don't work well with the rest of the system.  So this is just the biggest annoyance with them.  The Task Board view is how we do our day to day work, but defects created under a story don't show up along with the tasks on the story.
   
   Our work around for this is to stop creating defects.  This means we can't report out on things we consider defects in our own work as easily, but we'll see about figuring that out when we get a chance.
   
2. A couple of good views to work with
   
   It seems like every view is not quite all there.  You can do 90% of what you expect, but not everything.  For instance, the Task Board is great for updating tasks and progressing them.  However, viewing the parent story and adding new tasks is awkward.  The Iteration Planning view is good for putting stories into iterations and adding tasks.  However, viewing the story is awkward since it takes over the view and when you come back your location on the page is lost.
   
   Our work around for this is to open stories in a new tab.  Jira certainly isn't perfect, but I really appreciated it's plan and work views that seemed to really focus on the purposed for those views - also it's opening selected items in a sidebar view.

It's not without cause that many coaches advise finding you're own flow to things and keeping tools out of the mix as long as you can.  Because of our desire to work remotely and not wanting duplicate entry of stuff (as in update what we're using and keeping the central tool matched) we're continuing to work inside the tool.  I'm concerned with wanting to keep reporting in Rally with some of these concerns.