Part III Agile Activities and Reality Check
(這裡談到在agile activities的agile testing的關係, 在這些activities中testing 要如何運作和apply)
1. Test-First Programming
(1) Developers write unit tests before coding.
- Motivates coding
- Improves design (reducing coupling and improving cohesion)
- Supports refactoring
(2) Many open-source test tools have been developed to support this
xUnit
2. Reality Check: Unit Testing
(Unit Testing是用來和TDD相輔相成)
(1) Units are functions, methods or classes.
(2) Unit tests are in the same language as the code being tested.
(3) Unit tests are written by the programmers who wrote the code being tested.
(4) A test harness or framework collects tests into suites and allows them to be run as a batch.
(5) The X-Unit frameworks are popular harnesses.
- JUnit for Java, NUnit for Dot-Net…
(6) Most agile developers are ‘test-infected
3. Refactoring: Improving the Design of Existing Code
(1) “Changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”
(2) Make the simplest design that will work.
(3) Add complexity only when needed.
(4) Refactor to improve the design.
(5) Run tests to ensure that refactoring didn’t break anything..
4. Acceptance Testing
(1) User stories are short descriptions of features that need to be coded.
(2) Acceptance tests verify the completion of user stories.
(3) Ideally they are written before coding
(CI, Spikes, Frequent Delivery of Business Value, Immediate Acceptance Testing, 用來輔助Refactoring, and Acceptance testing)
5. Reality Check: Continuous Integration
(1) Rebuild the code whenever a new commit is made
(2) Then run the unit tests
(3) Post results to the web
(4) Send email with any errors
(5) Tools:
- Cruise Control
- Damage Control
6. Reality Check: Spikes
(1) The agile approach to architecture
(2) A spike is throwaway code that explores a particular approach to assembling code
- Will it work?
- How will it perform?
- Is it ugly?
7. Reality Check: Frequent Delivery of Business Value
(1) Not just a hunk of code
(2) Actual functionality that is valuable to end users
(3) A vertical rather than a horizontal slice
(4) Delivered to the customer
(5) Allows customer satisfaction to be measured
(6) Regular ‘Beta’ testing throughout development
(7) Usability testing, exploratory testing
(8) System must remain stable to make this happen (hence the need for automated regression tests)
(9) Focus on true customer satisfaction rather than just meeting the letter of the requirements
8. Reality Check: Immediate Acceptance Testing
(1) A story isn’t done until it has been tested
(2) Usually tested in the iteration
(3) “Sometimes you just have to throw a turkey in the engine.”
9. Agile Is About Reality Checks
(1) This conference is a chance for you to make another reality check.
(2) Agile is not about doing what the experts say.
(3) It is about doing what works.
(4) Ask the speakers how agile methods have or haven’t worked for them
10. Automating Acceptance Testing
(1) Characteristics of Successful Test Automation Projects…
- Collaboration between testers and developers
- Automate early
- Team commitment (vs “it would be good if”)
(2) Agile teams have all three
(3) Agile Testing Rules
- Programmers write automated unit tests.
- Acceptance tests must also be automated.
- Programmers and testers work together on acceptance tests.
11. Challenge: Regression Test Tools
(1) Most commercial test tools work poorly in an agile environment. Most have these flaws:
- Vendor-specific languages (vendorscripts)
- Poor integration with source control
- Hard to use with continuous integration
- Impractical to install on every workstation
(2) These problems make them impractical for use by the team as a whole.
(3) Agile teams are building their own test tools and releasing many of them as open-source…
留言列表
