Summary

Top 3 Things I learned

1. The very first thing I learned was at the the very start of the first chapter.  How cool is that? Even before the first words.  There is a graphic that is built using a technique I can’t remember the name that is almost a brainstorming technique (is it fishbones?) where the topics presented are shown in a graphic.  Very cool.  I remember!  Its a mind-map.  I like it.
2. Soap Opera testing.  This is where you take a ridiculous set of worst case events to the extreme in a very short time span.

---

 NOTES: Chapter 1: What is Agile Testing Anyway?

SUMMARY: A very gentle introduction.  Lays out what is meant by a customer team and what is meant by a developer team.  Some nice realities of testing in a waterfall vs. what is possible in Agile.  So if you do waterfall perfectly, testing never influences development which implies customers don’t get what they want and if you do it poorly you get squished and delayed releases.

CONCEPT: Customer Team

• Includes business experts, product owners, domain experts, product managers, business analysts, SME
• They
  • Write user stories
  • Provide examples
  • Answer questions
  • Draw examples
  • Review
• Testers
  • Integral to the customer team
  • Elicit requirements and examples
  • Help express requirements

CONCEPT: Development team

• Everyone who delivers code
• Discourage specialized roles
• Testers are on the development team
• Advocate for quality

---

NOTES: Chapter 2: Ten Principles for Agile Testers

SUMMARY: Extracts some (10) of the Agile principles that are relevant to an Agile Tester.  Defines an “Agile Tester” and the mindset needed. Walks through each principle and value and ends with a discussion on value.

CONCEPT: Agile Tester is a professional tester who

• embraces change
• collaborates well with tech and business people
• understands concept of using test to doc req and drive development

CONCEPT: 10 Agile principles for a tester

1. Provide continuous feedback
   1. Because testing drives agile projects, feedback plays a big part the tester works with customers to help them understand
2. Deliver value to the customer
   1. must make sure happy path works, try a thin slice if necessary
3. Enable Face-to-Face communication
   1. Enable (find ways) to go face to face
4. Have courage
   1. Must have the courage to fail fast and learn
5. Keep it simple
   1. doing the simplest test possible to verify that a piece of functionality exists.
6. Practice continuous improvement
   1. AADD: Agile Attention Deficit Disorder, if we can’t learn it quickly it is useless
7. Respond to change
   1. Automation is one of the keys to responding to change, what are the others?
8. Self-Organize
   1. Take initiative
9. Focus on People
   1. Agile teams give everyone equal weight
10. Enjoy
    1. Agile development rewards the agile tester’s passion for work

QUOTE: No Agile team will succeed doing only manual testing

---

NOTES: Chapter 3: Cultural Changes

SUMMARY: This is the first of three chapters on organizational challenges and talks about cultural changes.  The chapter covers many ideas but little depth.  The first part of this chapter is on organizational culture and presents straight-forward, common sense ideas.  The next part is on Barriers to adoption with some good content.  The content continues introducing change, management expectations and end with a discussion on change does not come easy.

IDEA: Testers working closely with the business side learn requirements and define acceptance tests.

CONCEPT: Barriers to adoption

• Loss of identity
• Additional roles
• Lack of training
• Not understanding agile concept
• Past experience
• Cultural differences

CONCEPT: How to introduce change

• Talk about fears
• Give team ownership
• Celebrate successes

CONCEPT: Example of an XP Testers Bill of Rights

• You have the right to bring up issues related to testing, quality, and process any time
• You have the right to ask questions of customers, programmers, and other team members and receive timely answers
• Your have the right to ask for and receive help from anyone on the project team, including programmers, managers, and customers
• You have the right to estimate testing tasks and have these included in story estimates
• You have the right to the tools you need to perform testing tasks in a timely manner
• You have the right to expert your entire team, not just yourself, to be responsible for quality and testing

IDEA: Best way to communicate to management is to speak their language

CONCEPT: tips for Change

• Be patient
• Let them train wreck
• Build you credibility
• Work on your own professional development
• Beware the Quality Police mentality
• Vote with you feet

---

NOTES: Chapter 4: Team Logistics

SUMMARY: This chapter is about building an agile team.  It starts with a discussion on team structure.  The important point is independent not separated.  The next part is on physical logistics, every team members needs ready access to all team members, easy visible progress charts, and an environment that fosters collaboration.  The discussion on resources is limited to avoid ratios and look to what you want to accomplish.  The last part on building a team shows many common sense ideas that boil down to communication.

CONCEPT: An agile team consists of three parts, which part are you:

1. Programmer
2. Domain Expert
3. Tester

IDEA: Physical space must have

• Ready access to all team members
• Easy visibility of all progress charts
• Environment that fosters communication

IDEA: Understand your constraints, and try to find solutions to problems your team encounters rather than just accepting things as “the way it is”

---

NOTES: Chapter 5: Transitioning Typical Processes

SUMMARY: This chapter covers five different areas around mapping processes.  The first area is short and to the point: seek lightweight processes.  The second area is on metrics.  They stress cycle tiem and say metrics used well have value.  Key: 1) ID Problem, 2) Set Goal and 3) Measure.  The third part is defect tracking and they list pros and cons.  The next two areas: Test Planning and Existing Process Maps are not well described.

CONCEPT: Metrics should be developed by:

1. ID Problem
2. Set Goal
3. Measure

QUOTE: There are three kinds of lies: lies, damned lies, and statistics. attributed to Benjamin Disraeli.

IDEA: Why a defect tracking system is good:

• Convenience
• Knowledge Base
• Large or Distributed Teams
• Customer Support
• Metrics
• Traceability

IDEA: Why a defect tracking system is bad:

• Does not promote communication
• Waste of Time and Inventory (lots of time spent around tracking the defect and not on fixing)

---

NOTES: Chapter 6: The Purpose of Testing

SUMMARY: Welcome to the 4 Quadrants (cue the intro to Welcome to the Jungle).  Technology facing is where the programmer is defining quality, business facing is where the customer is defingin what quality is.  TDD is in the Q1, ATDD in Q2 and BDD spans Q2 and Q3.  Tests that support the team aide in development of requirement specification.  Q1 is internal quality, Q2 is external quality, Q3 and Q4 are more user like.  There are 3 topics mentioned briefly in the end.  Doness, technical debt and testing in context.

CONCEPT: Testing Quadrant (overview).  If you do all then you manage your technical debt

• Q1: Technology facing and Supporting the Team
  • Unit Tests
  • Component Tests
  • Always automated
  • TDD lives here
  • Programmer defines quality
• Q2: Business Facing and Supporting the Team
  • Functional Tests
  • Examples
  • Story Tests
  • Prototypes
  • Simulations
  • ATDD lives here as does a part of BDD
  • Customer defines quality
  • Both automated and manual
• Q3: Business Facing and Critiquing the Product
  • Exploratory Testing
  • Scenarios
  • Usability Testing
  • UAT (User Acceptance Testing)
  • Alpha/Beta
  • Manual Testing
  • Real user scenarios
• Q4: Business Facing and Critiquing the product
  • Performance and Load Testing
  • Security Testing
  • “itlity” testing
  • Tools
  • Do not leave Q4 to the end
  • May require specialists
• Q1 and Q2
  • Tests run all the time
  • Aide in development requirement specs
• Q3 and Q4
  • Are user-like

IDEA: Internal quality is not negotiated with the customer, it’s defined by the programmers.  External quality is defined by the customer

IDEA: Exploratory testing uses critical thinking to analyze the results guided by strategy and operates with defined constraints.

CONCEPT: Confidence comes from doing all four quadrants in the interation

CONCEPT: Stock cards can be used for things you do all the time or that you want to get done.

TERM: Technical Debt, Ward Cunningham, 1992

CONCEPT: Testing in Context : it’s a tool, not a rule

• The value of any practice depends on its context
• There are good practices in context, but there are no best practices
• People, working together are the most important part of any project’s context
• Projects unfold over time in ways that are often not predictable
• The project is a solution.  If the problem isn’t solved, the product doesn’t work
• Good software testing is a challenging intellectual process
• Only through judgment and skill, exercised cooperatively throughout the entire project are we able to dod the right things at the right times to effectively test our products.

---

NOTES: Chapter 7: Technology-Facing Tests that Support the Team

SUMMARY: Detail on Q1.  I found the chapter to be a bit preachy.  I believe that good things and practices don’t need a dogmatic approach to convincing but this felt that way.  The chapter also has a lot of dated information when it delves into specifics and when it ia general it is just saying common sense items.

IDEA: Testing in other quadrants cannot make up for a lack in Q1

IDEA: TDD is more about design than testing.

CONCEPT: Ports and Adapters from Alistair Cockburn

• Ports: Accept outside events
• Adapter: Takes event and converts it to a message that can be understood by the application.
• Allows for better decoupling and automated testing

---

NOTES: Chapter 8: Business-facing Tests that Support the Team

SUMMARY: Talks about quadrant 2.  Business facing tests that support the team.   These tests help us understand when we are done and understand the requirements.  There is a neat case study/story about Wizard of Az testing.  They mention how tests mitigate risks and they must be automated.

IDEA: Q2 does these important things:

• Verify external quality
• Help tell us we are done
• Help us define scope

CONCEPT: Requirement formula

Requirement = Story(Who,What,Why) + Example/Coaching Test + Conversation

IDEA: Worst-case scenarios tend to generate ideas

CONCEPT: Wizard of Oz Testing

• sort of a “man behind the curtain”
• One person is the Wizard who plays the role of the computer
• Useful for UI development

TERM: Advance Clarity — one voice of the customer

TERM: Thin Slice, Steel Thread, Tracer Bullet

NOTE: They are not a big fan of edge testing if there is little consequence to those cases going bad

NOTE: Don’t write so many tests that you lose the forest for the trees

---

NOTES: Chapter 9: Toolkit for Business-Facing Tests that Support the team

SUMMARY: A long chapter with not much content and what is there is dated.  2 sub-sections, test management and business-facing test tool strategy have very little content.  The tools sub-section was very dated material.  The strategies section was very common sense items but worth mentioning.

IDEA: Considerations for tool selection

• Team Skill Set
• Technology stack
• Team’s automation priorities
• Time and Budget constraints
• Situation Unique

IDEA: Tools to create tests

• Checklists (Templates, impact areas)
• Mind maps
• Spreadsheets
• Mock-ups
• Flow diagrams
• Software-based tools

TERM: Domain-Specific Language (DSL)

CONCEPT: Strategies for writing tests

• Build Tests incrementally (happy path first, confine each test to one business rule or condition)
• Keep the tests passing (when a test in CI fails, should be the highest priority, tests are not temporary)
• Use Appropriate test design patterns (test genesis patterns
  • Build/Operate/Check.  Build input data, invoke code for the data, check results
  • Time-based, see how the calculations work over time, compound runs
• Keyword (Action driven) and Data Driven (spreadsheet)

CONCEPT: Tests should be included in your source code control

---

NOTES: Chapter 10: Business-Facing Tests that Critique the Product

SUMMARY: Discusses Q3.  The chapter starts by reminding us that this quadrant is about critiquing the product.  Demonstrations are a powerful technique when done as early as possible.  Scenario testing was a very good section , I especially like the Soap Opera testing.  There were very good exploratory testing discussions.  Some common sense approaches to Usability and Documentation testing.

CONCEPT: Soap Opera Testing: Take a scenario from a real life, exaggerate events, compress it into a quick sequence of events.  Ask what is the worst thing that can happen and how.

TERM: Exploratory Testing.  Cem Kaner 1983.  Simultaneous test design, test execution, and learning.

IDEAS: For exploratory testing — Continuous Investigation

• No script
• combines learning, test design, and test execution in one approach
• not evaluating software through exhaustive testing
• Add another dimension to your testing
• Just enough to see if the “done” stories are really done to your satisfaction
• Not a technique, but a mindset
• Not just about execution, design too
• Not unprepared

CONCEPT: Exploratory Testing Components

• Test Design
• Careful Observation
• Critical Thinking
• Diverse Ideas
• Rich Resources

CONCEPT: Session-based testing.  One method of testing that designed to make exploratory testing auditable and measurable.  Three types of sessions:

1. Test design and execution
2. Bug investigation and reporting
3. Session setup

IDEA: Usability testing can be both Q2 and Q3.  In Q2 we are using wireframes to feed back into requirements, in Q3 we are using personas to drive our exploratory testing (think Homer Simpson)

IDEA: Don’t forget to test the documentation and help texts.  For reports concentrate on the edge cases.

REFERENCE: PerlClip for test data generation and the url: http://www.satisfice.com

---

NOTES: Chapter 11: Critiquing the Product using Technology-Facing tests

SUMMARY: Lots of little nuggets for lots of topics.  No topic goes into great detail.  The general advice is look at your system and decide what type of testing is needed.  Q4 is essentially nonfunctional testing.

TERM: White-box testing is inside-out and black-box testing is outside-in

---

NOTES: Chapter 12: Summary of Testing Quadrants

SUMMARY: A case study, no new material

---

NOTES: Chapter 13: Why We Want to Automate Test and What Holds Us Back

SUMMARY: This chapter serves as an introduction to the next part, automated testing.  It is a very good overview.  2 main topics are well covered: 1) Reasons to automate and 2) Obstacles to automation

CONCEPT: Why automate

• Manual testing takes too long — gets longer each iteration
• Manual processes are error prone — manual tests get boring quickly especially at midnight before the release
• Automation Frees People to Do their best work — projects succeed when good people are free to do their best work
• Automated Regress test provide a safety net — test coverage gives a great feeling of confidence
• Automated Testing gives feedback early and often — act as your change dector
• Tests and examples can do more — gets you thinking about design
• Tests are great documentation — automated tests are always an accurate picture of how our code works
• ROI and Payback — You focus on root cause versus bug of the day

CONCEPT: Barriers to automation — bret’s list

• Done with spare time
• lack of clear goals
• lack of experience
• high people turnover
• it is a reaction to desperation
• reluctance to focus on testing versus the automation
• focus on solving the technology rather than the testing

CONCEPT: Their list

• Programmer’s attitude — why automate, especially beyond unit tests
• The Hump of Pain — cool concept, when becomes natural and part of the process
• Initial investment — big initial investment that does not pay off for a while
• Code that is always in flux — simple recorders and playback rarely a good choice
• Legacy code — MTF
• Fear — scary if you have never done it
• Old habits — die hard

NOTES: Chapter 14: An Agile Test Automation Strategy

NOTES: Chapter 15: Tester Activities in Release or Theme Planning

NOTES: Chapter 16: Hit the Ground Running

NOTES: Chapter 17: Iteration Kickoff

NOTES: Chapter 18: Coding and Testing

NOTES: Chapter 19: Wrap up the Iteration

NOTES: Chapter 20: Successful Delivery

NOTES: Chapter 21: Key Success Factors