February 2010 Monthly Meeting Summary
Topic:
This meeting was a roundtable discussion facilitated by Rick Hower and Jim Moore
- What does the term 'architecture' mean in the context of test automation?
- What are the important considerations in developing a test automation architecture?
- How is it similar or different from architecture for any other kind of software project?
- What's the best approach to coming up with a test automation architecture?
- Is 'architecture' relevant in an agile environment?
Took place on: Wed. February 3 2010 6:30 PM
Attendance: 11
Meeting Notes:
Notes from the initial discussion among attendees of the meaning of 'architecture' in the context of test automation:
- Consider 'architecture' in a heirarchy of terms: 1) Architecture 2) framework 3)design (eg, naming conventions, file handling ,etc)
- Reusable libraries, modules, enable easy additions and maintenance, structure
- Patterns, including types of testing needed (testing patterns)
- Reusable functions, services, messaging/input/output, interfaces
- functional flow
- architecture doc provides development guidelines, goals
- 'metaphor' perspective, 'constitution' - guiding principles of a project
- environments, configurations
- abstraction/high level guide to the automation
- reasoning and info that should affect design
- road map to design
- an architecture doc could be 1 page or 100 pages
- sets a common vocabulary
- provides context
Notes from attendees' discussion of considerations in developing a test automation architecture:
- Focus is testing - so architecture considerations include certain things like a machine-based
unambiguous determinant of pass-fail results
- Learning curve: adaptability of the architecture to expanding automation or adapting to SUT changes;
issue of how much adaptability (same type of tradeoff decision for all kinds of software architectures);
scalability
- Context - budget, management maturity and understanding of of automation issues; how much
reuse expected over time and on other projects; expected lifetime; skills available in team or
organization; SUT maturity and stability; team size and skills
- What aspects of testing to automate
- What aspects of the SUT's functionality should be the target of test automation
- How much work will be needed, and resources available for, keeping automation code/tests up to date
- How to track what is not automated
- Stakeholders/customers/users of the autaomted tool(s) and their needs/expectations such as reporting,
logging, etc
- Is testing/verification of the automation needed?
- Constraints like open source, or a requirement to use a particular tool or scripting language, etc.
NoVaTAIG Home Page
