November 2013 Monthly Meeting Summary

Test Automation Design in an Agile World - Roundtable discussion

Bring your agile project test automation experiences, challenges, successes, and questions to this meeting where we will discuss such topics as:
- How does test automation 'design' fit into the context of agile sprints?
- How is automation design different in agile projects vs 'big automation' efforts?
- What automation design considerations tend to be most important in agile project contexts?
- In an organization with multiple ongoing agile projects, what's the best way to implement/improve automation design while avoiding duplicated efforts and meeting the needs of different projects?
- Experience reports and lessons learned

Took place on: Wed. November 13 2013 6:30 PM

Attendance: 11

Meeting Notes:

At the start of the meeting some other potential sub-topics were listed:

Following are some of the comments made during the wide-ranging discussion:
  • On agile teams testers need wide skills including manual and automation skills
  • A survey of participants revealed most were doing variations on 'true' agile
  • Treatement of automation in within projects or within sprints varied; for some automation efforts were subtasks within sprints
  • It was mentioned that what stage a project is in when autaomtion begins and what stage the automation is in may affect how the automation is tracked/planned in project/sprint
  • There was a suggestion of having a separate project/team for automation when a big effort is needed for automation to catch up to the state of a project, and that they could be assigned sprint tasks or coulkd just provide services to the agile team
  • It was mentioned that for many organizations a big question is 'how to get started with automation' in agile
  • A suggestion was to get product owners to request things like an automation framework or other items added as stories
  • It was suggested that Automation often lags behind dev and is often best for regression; others indicated it was best if dev and test work closely together on tasks such that automation is done simultaneously with development
  • A point was made that agile works best when automated tests are run on every build
  • Some assigned hours not points to tasks/stories in sprints
  • It was pointed out that sprints don't have to be 2 weeks - suggestion was 2-6 weeks
  • There was discussion around the designations of unit/API/integration testing vs small/medium/large and what those meant, including how long it took to run automated tests
  • It was mentioned that it was hard to run automated tests 'nightly' if project/organization teams were worldwide
  • The approach may have a strong dependency on the size of the organization and the size of the automation project (eg, small automated API tests, buildout of big automation framework, etc
  • There was some dicussion of hwo to handle large shared automation efforts via scrum of scrums
  • Some mentioned Technical Debt Sprints, with technical debt sometimes including automation
  • A number of attendees felt that automation in agile was often a 'catch-up' effort
  • Some said an approach that worked well was a completely separate team working on automation framework/infrastructure
  • Design work can take place in a 'Sprint 0' (including automation design)
  • Regarding choosing and learning automation tools, some suggested concept and proof of concept efforts and there was discussion of how to go about that either within sprints or not; some suggested a 'Spike' agile story involving research
  • There was discussion of 'hardening sprints' where at the end of a project there is a sprint to do 'clean up'/bug fixing; some considered this a bad practice

     NoVaTAIG Home Page

Copyright 2013 Northern Virginia Test Automation Interest Group
Northern Virginia Test Automation Interest Group