March 2010 Monthly Meeting Summary
Topic:
This meeting was a roundtable discussion facilitated by Jim Moore and Rick Hower
Potential discussion topics were:
- This was a follow-on to the February discussion of Test Automation Architecture
- What are the key considerations in test automation design?
- What makes a 'good' design?
- How is it similar or different from design for any other kind of software project?
Took place on: Wed. March 3 2010 6:30 PM
Attendance: 13
Meeting Notes:
- In working up a test automation design, consider the target audience
- Audience could include testers, managers, developers
- Should it be a formal process/document, or informal?
- Document can help with understanding between dev and test re testability
and impacts of SUT code and SUT changes on automation
- Document enables others to provide input; ferret out issues
- Document can serve as artifact for future project personnel
- Can include info to answer later questions of 'why'
- Much of the discussion revolved around both architecture and design
- Architecture and design were considered as just different levels of abstraction, the
levels depending on the particular automation project context
- Common architectural approaches are '3-tier' and isolation of common functions
- Advantages of low-level of 'jargon' - better communication with stakeholders
- Consider required business value of automation
- There was some discussion on general lack of automation requirements or, if any, their
quality and specificity
- Design = the development approach
- A design doc is often useful as a way to get folks to stop, reflect, think
- Design can include details of modules, data, data storage, libraries/frameworks used,
implementation details, process flow, information flow, automation objects, patterns to use,
logging, data sources, configuration information for tool/framowrk/SUT/environment
- May be helpful to consider BDD/BDT (behavior-driven testing) and Domain Specific Languages (DSL)
Discussion of the components of design included:
- Goals
- Abstractions
- Automation processing layers
- Naming conventions
- Test run control mechanisms
- Test management platform
- Data sources
- Data repositories
- Hanlding changes to SUT
- Data-driven vs script-driven
- Identify sources of fragility
- Reporting formats, destinations
- Dependencies
- Tools
- Hardware details
- Security issues and mitigations
- Data privacy issues
- Test creation issues
- Test patterns
- Test execution mechanisms: batch - selection; single - scheduling; aggregation
- Discussion of any SUT code hooks needed and issues
NoVaTAIG Home Page
