Episode 135: DevOps & Electric Cloud with Anders Wallgren

The Agile Revolution Podcast

Craig speaks to Anders Wallgren from Electric Cloud about Continuous Delivery and DevOps at the Agile 2016 conference in Atlanta. The topic of conversation included:

  • Release It!” by Michael Nygard
  • We can’t declare victory on Agile, but it is the winning methodology
  • We are now plumbing the last mile of deployment and we also need to move it left
  • Joshua Kerievsky Agile 2016 keynote on “Modern Agile
  • Software process is like human DNA, we are different but essentially the same
  • Gene Gotimer Agile 2016 talk “Experiences Bringing Continuous Delivery to a DoD Project
  • You will fail if you don’t pay attention to the cultural aspects of Agile and DevOps
  • State of DevOps Report
  • Critical to automate everything to eliminate manual process errors and loss of valuable data
  • DevOps is starting to push into complex and regulated environments like finance, health and aerospace with an…

View original post 58 more words

Jenkins Gets a Facelift with Release of Blue Ocean 1.0

Jenkins, the popular open source automation server that is used by development teams worldwide for continuous integration and continuous delivery pipelines, has recently announced the general availability of Blue Ocean 1.0.

Source: Jenkins Gets a Facelift with Release of Blue Ocean 1.0

Scrum Shortcuts Without Cutting Corners (Book Review & Summary)

ScrumShortcutsI was priviliged to be an early reviewer for Ilan Goldstein’s book “Scrum Shortcuts Without Cutting Corners” and to also count him as a colleague and a friend. The Agile community in Australia is relatively small, so it is always exciting to see a book come out the community, particularly one that is part of one of the leading Agile Series by Mike Cohn. I was also honoured to be asked to provide a quote for the book. The following is my brief review and notes from the book.

Review

The following is my quote from the front of the book:

“If Scrum and Agile were easy, everybody would be doing it! Now that so many are, this book is the virtual Agile coach I wish I had when I was on the early steps of my Scrum journey. Ilan is a world-class coach, and he has packed this book full of ideas and approaches to all of the common questions and issues that are bound to come up as you transform your world of work to Scrum.”

–Craig Smith, Agile coach and editor at InfoQ

The book is broken into 10 chapters, each with 3 shortcuts each. It is written in a very easy to read and laid back style and feels like you are having a conversation with Ilan. It’s organisation means you can read the book from cover to cover of ad-hoc as a reference. It is clearly written with the Scrum Master / Iteration Manager as the primary audience, although it is suitable for anyone on the Agile team.

The key concept I really liked in the book was the notion of a Chief Scrum Master. As organisations begin to scale, it is a necessary role that is not always taken seriously. The book also covers the notion of One Scrum Master = One Team and deals with the ramifications and alternatives to this setup in a reasonable amount of pragmatic detail.

There were a couple of areas I disagreed with, mainly from an hybrid Agile approach as opposed to Scrum

  • protected sprint – Scrum talks about the idea of a protected sprint so that the team can focus. I can see some merit for new teams, but in this day and age of constant change I much prefer working on the next highest priority and the kanban approach to focussing on one-piece flow
  • sprint lengths – Ilan mentions that “1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks”. I have had a lot of success with 1 week sprints, particularly in business teams. Also, with teams adopting kanban, I have found 1 week sprints a good starting point. I have had some mainframe teams argue that they need 3 week sprints, but I personally find them too long.
  • creating and estimating tasks – Ilan writes “break the PBIs into more granular technical tasks and to estimate each task to the nearest hour”. I find this a complete overkill and much prefer to have nicely sized cards of no more than 3 days. That said. Ilan has some good strategies for splitting stories in the book that I completely agree with.
  • tracking time – further in the book, it is written “before going home each day, everyone on the development team should adjust the remaining time for any tasks they had been working on that day to ensure that up-to-date data is being fed into the sprint burndown chart.” As per the above point, I find this to be in most cases a useless metric, particularly if you cannot get the estimates from everyone in the team. In this age of #noestimates, I personally see this as an administrative overkill.

Overall, this is a book that belongs on any Agile pratitioners bookshelf as a trusted advisor or useful reference. As you become more experienced, this is the book you will definitely hand-on and recommend to your more novice colleagues as they take on the Scrum Master role.

My full book review and interview with Ilan and Colin is available on InfoQ.

Summary

Here are my key notes from the book:

Shortcut 1: Scrum On The Pitch

  • protected sprint allows the developers to completely fix their focus on what they committed to during the sprint planning session
  • the idea of personal achievement is overshadowed by team achievement
  • ScrumMaster protects the team from disruptive outside influences and removes issues that may be impeding development progress.
  • Scrum promotes transparency as a core tenet

Shortcut 2: Fragile Agile

  • Scrum is a framework not a method – Scrum is a framework of practices tied together by a small set of clearly defined rules
  • a requirement should not be considered done unless it has met the quality requirements stipulated in the definition of done
  • sprint zero – artificial term often used to describe the preliminary work that a team might undertake before it is ready to commence an actual sprint. The issue is inappropriate work is bundled into it that delays the starting of real sprints
  • poor ScrumMaster selection – unilateral product or technical decisions, micromanaging task assignments, driving the team to put in regular overtime, or generally acting like a tyrant

Shortcut 3: Creative Comfort

  • important to ensure that everyone is feeling energized and excited about coming to work
  • teams are made up of individuals, and individuals still maintain a sense of self-worth and appreciate having their hard work recognized.
  • when our value feels at risk, as it so often does, that worry becomes preoccupying, which drains and diverts our energy from creating value
  • basics for the environment: plentiful whiteboard and wall space, plenty of light, open desk space for each team, ample chair space, small round discussion table, readily available large meeting rooms, do-not-disturb zones, private areas, buffering from the noisier elements of the organisation
  • developers who are offered their choice of the latest and greatest equipment see it as the most wonderful benefit – keeping developers happy but also improving overall productivity!
  • jelled teams are usually marked by a strong sense of identity . . . team members feel they’re part of something unique. They feel they’re better than the run of the mill.
  • the more passionate people are about their projects, the more likely they are to fully engage in them each day
  • include the developers in some of the early user story workshops so that they not only feel involved in the conception of the product but also get an early idea of what they will be expected to develop and why.
  • a warm greeting in the morning, a sincere pat on the back for a task well done, and the feeling that you are part of a unique team can often be all that is required to maintain smiling faces.

Shortcut 4: Masterful ScrumMaster

  • begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead
  • 7 abilities: leading without authority, bring about change without fear, be diplomatic without being political, behave selflessly without downplaying the role, protect without being overprotective, maintain technical knowledge without being an expert, be comfortable never finishing, next generation leadership
  • ScrumMasters form part of a new generation of enlightened professionals. The role of the ScrumMaster is deep and complex and should never be seen simply as a laundry list of operational functions
  • although not everyone can be a ScrumMaster, a ScrumMaster can be anyone

Shortcut 5: Rock Stars or Studio Musicians

  • we prefer attitude over aptitude
  • teammates are expected to step up to the plate and, if necessary, temporarily help carry any additional load in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield
  • constant feeling of safety should be generated from the knowledge that teammates will be respectful even if they aren’t particularly enamored with an idea or opinion
  • the effort you’re willing to contribute goes down the more times you hear “You’re wrong!”

Shortcut 6: Picking Your Team Line-Up

  • consider many factors when running your own Scrum “draft pick,” including attitude, compatibility, skill sets, team size, ratio of functional specialties, shared resources, and workplace logistics
  • everyone is a developer – Scrum views all development team members as equals and labels them accordingly with the collective title “developer.” – it is like being a medical specialist; irrespective of specialty, all specialists are still doctors
  • Scrum team size – 5-7
  • development team ratios – 3 programmers : 1 tester : 0.5 “deep specialist(s)”
  • preferable to limit the work in progress and instead encourage as many developers as practicable to focus on completing a smaller number of PBIs
  • in your next sprint planning meeting, agree that one specialist on the team will not work in that specialty for the duration of the sprint. The specialist can advise others who do the specialty work but cannot do the work personally
  • have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team – treat the as consultants and trainers for the rest of the team
  • one team = one ScrumMaster

Shortcut 7: Setting the Scrum Stage

  • keep the team together for the duration of the project
  • a reasonable assessment of startup cost (for a new team member) is therefore approximately three lost work-months per new hire
  • work conducted in ad hoc space has got more energy and a higher success rate. People suffer less from noise and interruption and frustration
  • sitting together is the most effective way I know to build empathy
  • overtime should be the exception, not the rule – symptom of a serious problem on the project,” not simply business as usual
  • big believer in initially running a pilot project. I recommend this approach even if the business is champing at the bit to roll Scrum out en masse
  • as an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations

Shortcut 8: Plan the Sprint, Sprint the Plan

  • by collectively resetting the goals for the upcoming sprint every few weeks, the team can start afresh rather than remain stuck on a seemingly endless treadmill of ongoing work
  • ensure that the product owner (with relevant assistance) not only has determined the next priority requirements for the upcoming sprint but also has fleshed them out in just enough detail to allow the developers to get started
  • 1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks
  • don’t fall into the trap of believing that those who are dedicated full time to the sprint will be able to spend their entire working day on sprint-related tasks
  • 7 Ps – proper planning and preparation prevents piss-poor performance

Shortcut 9: Incriminating Impediments

  • anything impeding your team’s progress becomes the number-one priority for the ScrumMaster to tackle
  • impediments – meetings of large magnitude, illness, broken builds, issues with the tools of the trade, unreliable supplier, unrefined product backlog, absent or unempowered Product Owner, incentive schemes focussed on the individual
  • impediment ConTROL – Confirm, Triage, Remove, Outline, Learn
  • an obstruction that has stopped progress on a particular task but hasn’t necessarily slowed down overall progress (a block) versus an obstruction that is slowing down the team’s sprint progress (an impediment)
  • you want clear visibility of all blocked tasks, irrespective of how temporary the block may be – spin the corresponding sticky-note 45 degrees

Shortcut 10: Structuring Stories

  • an epic story is a user story that will take more than one or two sprints to develop and test
  • not necessary to have detailed user stories for every requirement only the top-priority items that are going to be worked on in the next one or two sprints
  • key is that stories should be written so that the customer can value them
  • if you can split a story into smaller ones and it is possible to independently prioritize them, it makes sense to treat them as actual stories rather than tasks
  • technical stories are things that need to get done but that are uninteresting to the customer, such as upgrading a database, cleaning out unused code, refactoring a messy design, or catching up on test automation for old features.

Shortcut 11: Developing the Definition of Done

  • DoD becomes the governing agreement that guides all developmental activities, clearly stating what is required for a piece of work to be categorically classified as “done”
  • we should be regularly inspecting and adapting the DoD
  • acceptance criteria or DoD – comes down to whether the requirement is applicable to every user story or to a smaller subset of stories
  • be realistic and get the ball rolling with a minimally acceptable DoD that everyone can live with

Shortcut 12: Progressive Revelations

  • inspect and adapt the user stories under development on a day-to-day basis throughout the sprint
  • typically a hands-on demonstration of the work requiring verification/validation, it usually occurs at the desk of the applicable developer

Shortcut 13: Relating to Estimating

  • estimate to make trade-off decisions and help set goals
  • relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing
  • determine the effort required to complete a PBI using three factors: complexity, repetition, and risk

Shortcut 14: Planning Poker at Pace

  • the issue when using Fibonacci numbers is that people can get into the bad habit of equating 13 points to 13 hours, for example
  • some teams adopt more abstract classifiers, such as T-shirt sizes – requires the extra step of mapping to a numeric value to enable forecasting during release planning
  • ScrumMaster acts as the facilitator throughout and is not involved in the actual estimation
  • Reestimation should be required only when a whole class of PBIs suddenly becomes smaller or larger
  • important to circulate a small number of reference PBIs that correspond to the point levels in the card deck
  • typically advocate removing the big cards (20, 40, 100, infinity) as well as the ½ card from the Planning Poker deck – fewer options equals less analysis paralysis
  • group of PBIs will inevitably rely on some of the same important research or technical plumbing – underlying work should be incorporated into the estimation of only one of the PBIs, not into all of them

Shortcut 15: Transitioning Relatively

  • identify the smallest user story in the product backlog and designate it to be the initial ½-point story – this approach can certainly work, and it seems straightforward on the surface, but the reality is that it can end up taking considerably more time than you might expect
  • map historical work to the new point scale system – identify, sort and stack, sizing up, subclassify, final filter

Shortcut 16: Bah! Scrum Bug!

  • an issue is a problem that occurs during the sprint and is tightly coupled to a user story – not a product backlog item
  • bug is a bug only if it is identified after a user story has been completed and accepted by the product owner – type of product backlog item
  • unless a user story meets the definition of done, it might as well not exist as far as the customer is concerned

Shortcut 17: We Still Love The Testers!

  • loss of identity fear – lose QA identity, lack of skills, won’t get support they need
  • testers think in alternative problem-solving patterns that are, generally speaking, mutually exclusive to the way programmers think
  • pair testing (when a tester pairs up with a programmer) is potentially even more powerful because there is additional scope to encourage functional skills transfer
  • there will always be the need for manual exploratory testing that no level of automation is able to replicate

Shortcut 18: Automation Nation

  • if your programmers are using TDD as a mechanism to write their tests, then they are not only creating a great regression suite, but they are using them to design high-quality, robust code
  • functional testing is also often called acceptance testing. Perhaps one day we will call it user story testing, as the idea is to be able to test and automate the full end-to-end functionality of a particular user story
  • integration testing is all about ensuring that new functionality is able to play nicely with the broader ecosystem and not just in isolation
  • performance testing is to measure the operation of the product when under pressure, typically brought about by increasing the number of users and/or increasing the amount of data processing required
  • recommend running a secondary build in the development environment (traditionally known as the nightly build) that is triggered manually and less frequently. The difference between the CI build and the secondary build is that the latter should be given the luxury of time, and therefore, it can include the full set of tests (including all of the heavier functional and UI tests that take significantly longer to run
  • should configure registry settings, initialize database schemas, set up web servers, launch processes—everything you need to build and test your software from scratch without human intervention
  • while continuous delivery makes every build releasable to users, continuous deployment actually releases every change to users (sometimes multiple times a day)
  • Scrum does not say that you must release at the end of every sprint, but it does say that you should do everything possible to have something releasable at the end of a sprint
  • just start somewhere –  recommend that if you are new to automation, you allocate a percentage of your sprint capacity to chipping away at it

Shortcut 19: Metrics That Matter

  • use them only for good, not for evil
  • good metric – used as a signal to help the team identify roughly where things are at and, more importantly, as a guide to help the team inspect and adapt its processes to improve over time
  • evil metric – used as an inflexible indicator for micromanaging an individual’s performance over time and, more importantly, for beating people up and killing morale
  • meaningful metrics – sprint burndown, enhanced release burndown, sprint intereference, remedial focus

Shortcut 20: Outstanding Stand-Ups

  • GIFTS – good start, improvement, focus, team, status
  • stand-up ambassadors – act as observers in the other groups to pick up on any potential contention and/or lessons
  • if you notice a team member addressing the ScrumMaster without making eye contact with anyone else, a tip is to start slowly turning around or looking up at the ceiling
  • daily scrum is a simple concept, but without care it can quickly turn into a daily mess

Shortcut 21: Taming the Task Board

  • colorful, sticky-note-adorned board has almost become the symbol of Scrum
  • visceral “ceremony” of this movement really appeals to our natural sense of achievement because of the visual recognition of work completed

Shortcut 22: To-Dos for your Sprint Reviews

  • sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate
  • nothing is more embarrassing than so-called technology experts unable to get the projector to work before the session even begins
  • demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team
  • team should demonstrate only stories that meet the definition of done
  • acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down on the whiteboard or index cards

Shortcut 23: Retrospective Irrespective

  • irony is that this session is most valuable when the pressure is on and/or when things aren’t running as expected
  • without an atmosphere of openness, you will never get to the heart of issues; without courage, the team won’t be willing to confront problems head on; without respect, the team won’t present criticism in a constructive fashion; and without focus and commitment, the team won’t care enough to resolve the issues
  • recommend a relaxed setting such as a coffee shop, a break room (if you have one), or even the kitchen area
  • focus areas – communication, processes, scope, quality, environment, skills
  • ensure that all improvement suggestions are documented, but aim to tackle no more than a few issues
  • circles technique employs an affinity mapping variation, bubbles technique requires each person to document on paper the three most urgent issues that he or she feels should be focused on pair and keep bubbling up the top 3 issues

Shortcut 24: Risk Takers and Mistake Makers

  • to successfully implement Scrum, we must overcome a range of fears
  • spend your time and effort helping those who are already enthusiastic
  • the few bad eggs are often the ones who are most afraid of exposure
  • Scrum turns software development into an open book where mistakes are clearly visible
  • when openly discussing mistakes and vulnerabilities is the forging of closer bonds between team members

Shoprtcut 25: Perception is Reality

  • you have a role as the ScrumMaster to keep the sponsor from blowing a gasket
  • reinforce the positive changes that are occurring while also gauging the sponsor’s current perception of how the project is going
  • sponsors become less upset when confronted with problems if they are involved in the resolution
  • take the sponsor on a “Tour of the Task Boards” now and again
  • never say no is a lesson that I have learned over time

Shortcut 26: Our Lords and Masters

  • Chief ScrumMaster – facilitator of the ScrumMaster Community of Practice – training and coaching, challenge existing behaviours, provide and maintain tools, define and refine metrics, help establish communities of practice, ensure consistency, coordinate teams, ongoing Scrum promotion, developing the approach, company-level education, aligning the teams DoD, continual process improvement via Collective Retrospectives, impediment escalation, HR for the ScrumMasters, creating a physical environment conducive to Scrum
  • ScrumMaster – process improvement, impediment management, diplomacy, coaching, managing change, maintaining the DoD, maintainin effective communication, updating artifacts, faciliating workshops, faciliating Scrum activities

Shortcut 27: Morphing Managers in the Matrix

  • requires visionary leadership that is genuinely interested in encouraging continuous improvement as opposed to playing politics
  • intra-organizational coordination, logistical planning, scheduling, and tracking are massive roles and ones that are nicely suited to the traditional project manager
  • the manager in Scrum is less of a ‘nanny’ to the Team and more of a mentor or ‘guru,’ helping them learn, grow and perform

Shortcut 28: Scrum Rollout Reckoning

  • you are either doing Scrum or not – it is binary
  • Scrum is not a mechanical process… it is so reliant on people and culture that even with fantastic quantitative results, the introduction of Scrum may have caused such upheaval that too many people are unhappy and that is not good for Scrum’s long-term survival
  • Benefield and Deemer used a simple survey based on the following six criteria: How much the team got done in 30 days; Clarity of goals—what the team was supposed to deliver; Collaboration and cooperation within the team; Business value of what the team produced in 30 days; Amount of time wasted, work thrown out, cycles misused; Overall quality and “rightness” of what the team produced
  • Comparative Agility – teamwork, requirements, planning, technical practices, quality, culture, knowledge creation
  • 3 questions – are your clients happier, are your team members happier, are your stakeholders happier

Shortcut 29: Eyes on the Prize

  • development team has no top-down command-and-control authority that tells the team how to do its work. Instead, a cross-functionally diverse team of people organize themselves in the most appropriate way to get work done
  • self-organization needs to be grown and nurtured in a particular environment with distinct boundaries, or it risks spreading wildly out of control
  • ScrumMaster should assist management in the selection of team members to ensure that the team has the natural predisposition to self-organize and work together as one
  • ScrumMasters should not become obsolete – impediments are never predictable, perfection is impossible

Shortcut 30: Shortcut to the Final Level

  • if you remain disciplined, follow the Scrum rules, and adhere to the key practices, then, at the very worst, Scrum will act like a mirror, helping you to uncover the dysfunctions that caused the project to fizzle
  • three words to remember from the book: transparency, inspection, adaption
  • A Scrum adoption should be seen as a big collection of small experiments, wrapped up in a big experiment
  • convince every single person in your organization that “agility needs to be seen as a business strategy and not just something the IT guys do

Agile 2009 Day 3 Review

Agile 2009One of the problems of presenting a double session at Agile 2009 is that miss out on a bunch of the great talks that are going on at the conference at the same time. Added to that, the (very) last minute preparations that I was doing with Paul King meant that I only got to sit in on one session (apart from our own).

Automated Deployment with Maven & Friends – Going The Whole Nine Yards

This was a good overview by John Smart of using Maven as a build tool as well as how you might use tools such as Cargo and Liquibase and scripting languages like Groovy to automate your deployment process. I was hoping John would have the silver bullet to linking the Jira release button to a deployment script, however it appears the only way of doing this still is via a plugin for Bamboo.

How To Make Your Testing More Groovy

The session I presented with Paul King, we got a reasonable turnout for a technical double session and the session feedback forms were overwhelmingly positive. The slides are available in a separate post.

Agile 2009 Groovy Testing Paul King
Agile 2009 Groovy Testing Craig Smith

Dinner with Manning & John Hancock

I had the pleasure of having dinner with Todd Green from Manning, Greg Smith (co-author of Becoming Agile) and Paul King (co-author of Groovy In Action). As the technical proof-reader for Becoming Agile and knowing Paul King, I also got an invite for traditional deep-dish Chicago pizza.

Afterwards, Paul and I treked up the “Magnificent Mile” and up 95 floors to the Signature Room in the John Hancock Center (Chicago’s fourth tallest building but best observation deck according to the locals). The views were amazing (the pictures don’t do justice to the city lights that carry on into the distance!)

Chicago John Hancock Signature Room

AAFTT Workshop 2009 (Chicago)

Agile AllianceI had the great pleasure to attend the Agile Alliance Functional Testing Tools (AAFTT) workshop on the Sunday before the Agile 2009 conference in Chicago, and share discussion with some of the best minds in the testing community from around the world.

The location was right across the road from the Willis Tower (better known by its previous name, the Sears Tower). Some of the notable attendees amongst many others included:

There were at least 4 tracks to choose from, these are the notes from the ones I participated in.

Screencasting

Small group discussion led by Jason Huggins about a different way of thinking about test artefacts (basically producing an iPhone commercial)

Photo 3 of 4 from #agile2009 in Chicago at the pre-conference... on Twitpic

  • the Rails screencast sold Rails because it sold the idea and then the product sold itself
  • now, with YouTube, etc, we have the tools available
  • used to be RTFM, not it is WTFV
  • ideal is to produce automated tests like the iPhone commercial, instead of a test report
  • use the “dailies” concept, like in the movies
  • perhaps the movie should be at a feature level, because the video should be interesting
  • best suited for happy path testing, is a way to secure project funding and money, remember that the iPhone commercial does not show the AT&T network being down
  • there is a separation between pre-project and during testing
  • tools currently exist, including the Castanaut DSL
  • part of the offering of Sauce Labs, currently recording Selenium tests
  • from the command line utility vnc2swf, created an API called Castro
  • at the moment you need to clean up the screens that are recorded
  • the advantage, being VNC, is that you can use all sorts of hardware, including the iPhone
  • suggest that you use something like uLimit to stop runaway videos, especially when being run in an automated test, to limit the size of the directory or the length of the video
  • suggest make a rule that no test is longer than five minutes
  • given the current tools are written in Python, DocTest is good for testing

Lightning Talks on Tools

I came in mid-way through this session, but caught some of the tools being discussed at the end

  • some tools are too hard to get passed the basic level, but quick to setup
  • tests are procedural, engineers tend to over-engineer

Robot IDE (RIDE)

  • most tools have a basic vocabulary to overcome
  • IDE is worth looking at
  • Robot has a Selenium plugin, but it is easy to write your own framework

Twist

  • specify tests as requirements, looks like a document, stored as text, write whatever you want
  • refactoring support as a first level concept
  • out of the box support for Selenium and Frankenstein (Swing)
  • write acceptance test – brown shows not implemented, allows developer to know what to implement, turns blue when done
  • refactoring concept “rephrase”
  • supports business rule tables (ie. Fitnesse for data driven tests)
  • support to mark a test as manual and generate the same reports
  • commercial software, licenced in packs
  • plugins to Eclipse, but don’t need to be familiar with this unless you are developing the automation

WebDriver

  • been around for three years

UltiFit

  • Ultimate Software, internal currently, allows to select Fitnesse tests, setup and teardown, close browser windows, nice GUI, etc…
  • uses TestRunner under the covers

SWAT

  • been around for two years, more traction now that Lisa Crispin works for Ultimate Software
  • simple editor for SWAT (& somewhat Fitnesse)
  • has a database access editor
  • uses Fitnesse syntax
  • there is a recorder, only good for teaching, people get lazy and don’t refactor
  • can take screenshots, borrowed from WatiN
  • can’t run SWAT when Fitnesse is running as a server
  • SWAT is a C# library at its core
  • can run macros, tests from other tests
  • run script – write script (eg. JavaScript) to help things that are hard to test

High Performance Browser Testing / Selenium

Jason Huggins led this conversation which was more a roundtable debate than anything else. The group discussed how we can get tests running quicker and reduce feedback times considerably.

This discussion led to a couple of the quotes of the workshop from Jason Huggins:

  • “Selenium IDE is the place to start with Selenium, but it is Selenium on training wheels”
  • “Record/playback testing tools should be clearly labeled as “training wheels”
  • “What to do with the Selenium IDE, no self respecting developer will use it.” Thinking of renaming the IDE to Selenium Trainer.
  • Amazing how many people in the testing community are red, green colour blind”

When Can / Do You Automate Too Much?

This started as a discussion on testing led by Brandon Carlson…

  • get your business people to write the tests – they will understand how hard it is, have seen outcome that amount of scope reduced because they have to do the work

…but ended up as a great discussion on agile approaches and rollout, discussing a number of war stories led by Dana Wells and Jason Montague from Wells Fargo

  • still early in their agile deployment
  • wish to emulate some of the good work done by some of the early agile teams
  • estimate in NUTs (Nebulus Units of Time)

Miscellaneous and Other Links

Some other miscellaenous observations from the workshop:

  • a number of sessions were recorded
  • of those using Windows laptops, a large percentage were running Google Chrome
  • Wikispaces is good to setup a quick wiki

A number of posts about the workshop have been posted since including:

And you can view the photos that I took from the event at: http://www.flickr.com/photos/33840476@N06/sets/72157622521200928/