Instructor: Monica Luke
Test Automation Architect at IBM Rational
Been doing this for 17 years
Automate early, automate often
Going Agile
Plan for an extended transition – it is a culture shift
Transition is hard for development
Need to build a sense of urgency
Aside: most companies seem to apply only parts of Agile
Benefits:
* Incremental deliveries
* Visibility: deliver often, demo often
* Team morale: better productivity, less burnout
Challenges:
* Quick moving cycles
* Planing is key, as is estimation
* Just enough process to be visible and predictable
Test and Test Automation is the bomb
Aside: most organizations represented here seem to have dedicated groups – for analysis, development, and testing. Few seem to have people that do "everything."
What to automate and when. Avoid automate moving targets. Ask: what are your manual test pain points?
What is the right insertion point:
* API
* GUI
* Product Architecture
Going Agile: A Case Study
1. Select Practices to Adopt
2. Implement, Evaluate, Adapt
3. Adopt or Reject Practices
4. Goto 1
Time boxed iterations
- Three weeks
-- 1.5 days planning
-- 12 days coding
-- 1.5 days testing
Shorter iterations (2 or 3 weeks) build a sense of urgency.
Thursday, June 10, 2010
The Joy of Legacy Code
6/9/2010
Michael Feathers
Legacy systems are not "sexy" but they are still doing useful/interesting work
Code is biological
A kudzu vine that grows and grows, takes over an ecosystem over time
The aesthetic is different in a large system: our standards may need to change
We align with the things that are easier over time
adding code to an existing function is easier
therefore functions will get longer
classes will get bigger
extra work to create a new class/function: think of a new name, more keystrokes, etc
Morale: how are we going to make progress on this code that isn't always pretty
attainable goals: hard to feel like you're making progress
Code coverage as a metric: you could spend your entire career trying to get to 100%
Adding automated tests to code that is already working can be futile
Add tests to code you are about to change, as a feedback mechanism
Some areas are changed much more frequently than others
Hotspots will gain test coverage sooner than you think, you may be pleasantly surprised
Useful metrics:
Change coverage: find the areas where you have the most commits
Count all commits in a file towards this metric once that file has tests
The hardest part of adding tests to legacy code is breaking the dependencies to attain isolation for unit tests
Method Object
Martin Fowler's Refactoring Catalog
Take a method and turn it into a new class with all the code in a run() method
Allows you to move forward in interesting ways
There is a one time cost for testability
Hardest part of creating tests is breaking dependencies
Once you have broken the dependencies adding more tests will be much easier
Isolate Sections
Higher levels of testing are also valuable
Easy to have changes propagate far away from the actual change
It's easy with singletons to modify states from any place: so people do modify it from any place
Componentize large sections are consolidate the globals: totally eliminating them might be too difficult in a large existing system
Exploit Natural Encapsulation
The main problem with legacy code is understandability: use Understand tool to examine the structure of your code and create new classes that are already naturally encapsulated
Name the Thorny Areas
"Quince's Quagmire"
Wall Map with your visualization of the system "here be dragons"
Dismisses the fear associated with particularly nasty code
Some gallows humor...
Wounded Giant Metaphor
Approach it like a doctor: the existing code is not an enemy, you're trying to make it better
Heroic Stories
Sharing war stories. Develop a folklore about the code you're working on
Other metaphors: Code as a garden, code as a playground
Explain your system as simply as possible, ideally 4 elements or less, as a way to start owning/exploring the code. A way to get a foothold of understanding
Scratch Refactoring
You have a big piece of code and no idea where to start refactoring
Refactor it to hell, dont test it, dont even compile it, and then throw it away
Not a waste of time because you will understand more about what's there
Viking Laws
-be brave & aggressive
-be direct
-be versatile and agile
-attack one thing at a time
-be prepared
etc....
attitude is everything
You *can* apply creativity to a legacy code
Michael Feathers
Legacy systems are not "sexy" but they are still doing useful/interesting work
Code is biological
A kudzu vine that grows and grows, takes over an ecosystem over time
The aesthetic is different in a large system: our standards may need to change
We align with the things that are easier over time
adding code to an existing function is easier
therefore functions will get longer
classes will get bigger
extra work to create a new class/function: think of a new name, more keystrokes, etc
Morale: how are we going to make progress on this code that isn't always pretty
attainable goals: hard to feel like you're making progress
Code coverage as a metric: you could spend your entire career trying to get to 100%
Adding automated tests to code that is already working can be futile
Add tests to code you are about to change, as a feedback mechanism
Some areas are changed much more frequently than others
Hotspots will gain test coverage sooner than you think, you may be pleasantly surprised
Useful metrics:
Change coverage: find the areas where you have the most commits
Count all commits in a file towards this metric once that file has tests
The hardest part of adding tests to legacy code is breaking the dependencies to attain isolation for unit tests
Method Object
Martin Fowler's Refactoring Catalog
Take a method and turn it into a new class with all the code in a run() method
Allows you to move forward in interesting ways
There is a one time cost for testability
Hardest part of creating tests is breaking dependencies
Once you have broken the dependencies adding more tests will be much easier
Isolate Sections
Higher levels of testing are also valuable
Easy to have changes propagate far away from the actual change
It's easy with singletons to modify states from any place: so people do modify it from any place
Componentize large sections are consolidate the globals: totally eliminating them might be too difficult in a large existing system
Exploit Natural Encapsulation
The main problem with legacy code is understandability: use Understand tool to examine the structure of your code and create new classes that are already naturally encapsulated
Name the Thorny Areas
"Quince's Quagmire"
Wall Map with your visualization of the system "here be dragons"
Dismisses the fear associated with particularly nasty code
Some gallows humor...
Wounded Giant Metaphor
Approach it like a doctor: the existing code is not an enemy, you're trying to make it better
Heroic Stories
Sharing war stories. Develop a folklore about the code you're working on
Other metaphors: Code as a garden, code as a playground
Explain your system as simply as possible, ideally 4 elements or less, as a way to start owning/exploring the code. A way to get a foothold of understanding
Scratch Refactoring
You have a big piece of code and no idea where to start refactoring
Refactor it to hell, dont test it, dont even compile it, and then throw it away
Not a waste of time because you will understand more about what's there
Viking Laws
-be brave & aggressive
-be direct
-be versatile and agile
-attack one thing at a time
-be prepared
etc....
attitude is everything
You *can* apply creativity to a legacy code
Wednesday, June 9, 2010
Performance & Security Testing in Agile Development
6/9/2010
Tracy DeDore (HP)
Testing baked into each sprint: cant be a manual approach
Not uncommon to take a hybrid approach between agile/waterfall: scrummerfall
Important to be diligent when mixing practices
Non-functional testing often gets deferred till the end: risky
Functional/performance/security testing should be addressed in release planning & each sprint
automated load testing: bottlenecks/root cause analysis etc for performance degradation
wont have a working full application every sprint: need to be able to test components
headless/gui-less performance testing
Service virtualization tools: capture/model target system's behavior/performance so you dont need to use live systems for testing each time
static source code analysis: scan for vulnerabilities during dev: many false positives
step or path-specific business process testing
black box/dynamic web application scanners: requires a fully functioning app
leverage automation tools: allows dev & QA to test without being security experts
Tracy DeDore (HP)
Testing baked into each sprint: cant be a manual approach
Not uncommon to take a hybrid approach between agile/waterfall: scrummerfall
Important to be diligent when mixing practices
Non-functional testing often gets deferred till the end: risky
Functional/performance/security testing should be addressed in release planning & each sprint
automated load testing: bottlenecks/root cause analysis etc for performance degradation
wont have a working full application every sprint: need to be able to test components
headless/gui-less performance testing
Service virtualization tools: capture/model target system's behavior/performance so you dont need to use live systems for testing each time
static source code analysis: scan for vulnerabilities during dev: many false positives
step or path-specific business process testing
black box/dynamic web application scanners: requires a fully functioning app
leverage automation tools: allows dev & QA to test without being security experts
Manifesto for Agile Software Development
First principles of Agile, from http://agilemanifesto.org/
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Tutorial: Agile Use Cases
Instructor: Rebecca Wirfs-Brock
Rebecca is the inventor of the two column use case. She has been doing use cases since 1992. It was in a Smalltalk magazine that she published a use case with two columns. The side-by-side use case was born... no, No, NO.
Agile core values
Actor = a user or another system
Use case body forms
User stories are a similar to use cases.
From wikipedia: "A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software."
Rebecca is the inventor of the two column use case. She has been doing use cases since 1992. It was in a Smalltalk magazine that she published a use case with two columns. The side-by-side use case was born... no, No, NO.
Agile core values
- Design simplicity (use case application: simple writing leads to simple coding)
- Interpersonal communication
- High degree of trust
- Satisfying stakeholders
- Constant learning
- Decision making spread across project duration
- Information when needed ... just in time (often through conversations and additional tests)
- Functionality from a particular point of view
- ... describes a chunk of the system
- Can be a various levels: In the clouds (scope) and at sea level (code)
- Agile use cases are not so detailed
Actor = a user or another system
Use case body forms
- Narritive form
- Step-by-step form
- Side-by-side form (Conversational)
User stories are a similar to use cases.
From wikipedia: "A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software."
Subscribe to:
Posts (Atom)