1 1 Copyright 2011 Gerard Meszaros Much Ado About Agile 2011 Agile Test Automation Strategy For Anyone and Everyone! Gerard Meszaros [email protected]2 Copyright 2011 Gerard Meszaros Much Ado About Agile 2011 Product & I.T. I.T. Embedded Telecom My Background Gerard Meszaros [email protected]•Software developer •Development manager •Project Manager •Software architect •OOA/OOD Mentor •Requirements (Use Case) Mentor •XP/TDD Mentor •Agile PM Mentor •Test Automation Consultant & Trainer •Lean/Agile Coach/Consultant 80’s ----- 90’s ----- 00’s
53
Embed
Agile Test Automation Strategy - Agile Alliance · Agile Test Automation Strategy ... Given... When ... Then .... Preconditions. 8 ... Much Ado About Agile 2011 19 Copyright 2011
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
1 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Agile Test Automation StrategyFor Anyone and Everyone!
3 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Agenda• Motivation
– The Agile Test Problem– The Fragile Test Problem
• Approaches to Test Automation• Test Automation Strategy
4 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Product Owner Goal
• Goal: Maximize business value received
Features Money
Product Owner
Concept
Minim
ize
Maxim
ize
Quality is Assumed; Not Managed
3
5 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Why Quality Often Sucks
• Iron Triangle of Software Engineering:
You can fix any three; the fourth is the outcome
Resources
Time
Functionality
• What about Quality?
Quality
6 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
In Agile, we“Pin” quality
usingautomated
tests
Why Quality Often Sucks
• Iron Triangle of Software Engineering:
You can fix any three; the fourth is the outcome
Functionality
Quality
• What about Quality?
Resources
Time
4
7 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Speaking of Quality,would you ...
... ask your doctor to reduce the costof the operation ...
... by skipping the sterile technique ?
Test Automation is like hand washing:Improved results but an upfront cost.
8 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Minimizing Cost of ProductTotal cost includes:• developing the software• verifying the newly built functionality• verifying old functionality still works• fixing any bugs found• Verifying noting was broken by fixes
Agile Test Automation can reduce thecost of all of these activities.
5
9 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Incremental Development
• Type NF bugs: New Func. is wrong• Type RB bugs: New bugs in old func.
(Regression Bugs)
Concept Version 1.0
EvolvedConcept
Initial NF
Version 1.xVersion 1.0
RB
NF
10 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Exercise 1• Time to test our little application
• Oh, new build, please retest!
• Another build, please retest!
6
11 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
The Agile Test Problem
RequirementsDevelopment
Testing
12 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
The Agile Test Problem
• As development increments reduce induration, testing needs to be reducedaccordingly
TestingDevelopment
Requirements
TestingDevelopment
Requirements
7
13 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
The Agile Test Problem
... and traditional approaches to testing nolonger work
TestingDevelopment
Requirements
TestingDevelopment
Requirements
TestingDevelopment
Requirements
TestingDevelopment
Requirements
14 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Anatomy of an Automated Test
Our System
Other System
Other System
Interface BusinessLogic Database
Container Services
Other System
Test
Test Scenario Name-----------------------
----------------------1. Do Something2. Check Something-----------------------Clean Up
1&2 May berepeated
TestSetup
TestTeardown
Preconditions(State)
AdapterGiven...
When ...Then ....
Preconditions
8
15 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
executiondefinition
• User executes tests manually; tool records as tests• Tool replays tests later without user intervention
Fixture
Test Result Repository
Test Script Repository
TestRecorder
SUT
TestScript 1
TestScript 2
TestScript n
ExpectedOutputsInputs
Inputs
Outputs
InputsTestRunner
Script nResult
TestResults
ExpectedOutputs
(C)OTS Record&Playback
The tests areare code/datainterpretedby the test
runner.
16 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Exercise 2• Record & Playback Test Automation
– Please record a test against the System Under Test– Then, run the test to make sure it works
• New build has been delivered– Please run the test against new build
9
17 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Agenda• Motivation
– The Agile Test Problem– The Fragile Test Problem
• Changing the Role of Test Automation• Approaches to Test Automation• Test Automation Strategy
18 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
The Fragile Test ProblemWhat, when changed,may break our testsaccidentally:
– Behavior Sensitivity» Business logic
– Interface Sensitivity» User or system
– Data Sensitivity» Database contents
– Context Sensitivity» Other system state
Our System
Other System
Other System
Interface BusinessLogic Database
Container Services
Other System
Test
In Agile, these are all changing all the time!
10
19 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Our System
Other System
Other System
Interface BusinessLogic Database
Container Services
Other System
Interface Sensitivity• Tests must interact with
the SUT through someinterface
• Any changes to interfacemay cause tests to fail.– User Interfaces:
» Renamed/deleted windows ormessages
» New/renamed/deleted fields» New/renamed/deleted data values
in lists– Machine-Machine Interfaces:
» Renamed/deleted functions in API» Renamed/deleted messages» New/changed/deleted function
parameters or message fields
Window
Window
FieldButton
TitleCaption
LinkData Grid
E.g.: Move tax fieldto new popup window
20 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Our System
Other System
Other System
Interface BusinessLogic Database
Container Services
Other System
Behavior Sensitivity• Tests must verify the
behavior of the system.– Behavior also involved in test
set up & tear down• Any changes to business
logic may cause tests tofail.– New/renamed/deleted states– New/changed/removed
business rules– Changes to business
algorithms– Additional data requirements
Object
Object
StateIdentity
AlgorithmRule
E.g.: Change fromGST+PST to HST
11
21 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Our System
Other System
Other System
Interface BusinessLogic Database
Container Services
Other System
Data Sensitivity• All tests depend on
“test data” which are:– Preconditions of test– Often stored in databases– May be in other systems
• Changing the contentsof the database maycause tests to fail.– Added/changed/deleted
records– Changed Schema
Table
RowRowRow
E.g.: Change customer’sbilling terms
22 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Our System
Other System
Other System
Interface BusinessLogic Database
Container Services
Other System
Context Sensitivity• Tests may depend on inputs
from another system– State stored outside the
application being tested– Logic which may change
independently of our system
• Changing the state of thecontext may cause tests tofail.– State of the container
» e.g. time/date– State of related systems
» Availability, data contentsSecurity System
User: XPermissions: none
Container ServicesTimeDate
Customer X
E.g.: Run test in ashorter/longer month
12
23 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Agenda• Motivation• Changing the Role of Test Automation
– From Defect Detection to Defect Prevention– Different Tests for Different Purposes
• Approaches to Test Automation• Test Automation Strategy
24 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
The Role of Automation in Agile• Provide a Safety Net for Change & Innovation
– Provide rapid feedback to reduce cost of fixing defects.» On demand (Developer) and event driven (CI build)
– Rapid feedback enables experimentation» Don’t have to choose between Quick and Safe
• Guide Development of the Product– Provide executable examples of what “done” looks like
• Support Manual Testing– Remove the repetitive drudgery so testers can focus on
high value activity by:– Automating entire tests, or by– automating the steps that can be automated.
13
25 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
How is Agile Test Automation Different?
• We automate the tests for a different reason– Defect Prevention vs. Detection– To communicate requirements– To “Pin” the functionality once it’s built
• We automate the tests a different way– Many different kinds of tests
» E.g. We don’t rely solely on GUI-based automation– Using tools that support collaboration & communication
» in addition to confirmation
• We plan the automation based on ROI– Goal isn’t: 100% automation– Goal is: To maximize benefit while minimizing cost
26 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
32 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Prevention: - Building the Right Product
What the customer thought they wanted
What the customer actually asked for
What the customer realized they actually needed
What development thought the customer asked for
What development actually built
What testing thought the customer asked for
What testing actually tested for
17
33 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Building the Right Product
• How do we eliminatethe waste caused bybuilding the wrongproduct?– Missed requirements?– Misunderstood
requirements?– Unneeded functionality?
34 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Building the Right Product
• How do we eliminatethe waste caused bybuilding the wrongproduct?– Missed requirements?– Misunderstood
requirements?
18
35 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Example-Driven Development
• A.K.A.– Acceptance Test Driven Development– Behaviour-Driven Development– Executable Specification– StoryTest-Driven Development
• Concrete examples flesh out requirements
• Testers flush out missed scenarios......before development starts
36 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Life Cycle of an Example / Test
UserGoal
Feature
StoryTitle
StoryNarrative
StoryScenarios
StoryExamples
ExecutableExamples
SatisfiedExamples
FormalizationAutomation
ProductDevelopment
Make ConcreteBy Adding Data
DefineAcceptance
Criteria
19
37 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Agenda• Motivation• Changing the Role of Test Automation
– From Defect Detection to Defect Prevention– Different Tests for Different Purposes
• Approaches to Test Automation• Test Automation Strategy
38 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Test Automation Pyramid
Unit Tests
ComponentTests
SystemTests
Pyramid originally proposed by Mike Cohn
Exploratory Tests• Large numbers of very
small unit tests– Ensures integrity of code
• Smaller number offunctional tests for majorcomponents– Verify integration of units
• Even fewer tests for theentire application &workflow– Ensure application(s) support
users’ requirements• Tools to support effective
exploratory testing
20
39 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Unit Tests
ComponentTests
SystemTests
Workflow
Transactions
Behavior Specification at Right Level• Specify broad scope at minimum detail
– E.g. Use least detail when specifying workflow• Specify most detailed req’ts at narrowest scope
– E.g. Don’t use workflow when specifying business rules
Make examples /tests easy to
understand andeasy to write
Broad NarrowScope
Det
ail
High
Low
BusinessRules
Too vague
Too much detailUnmaintainable
UnitTests
40 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Mega Bank Requirements• Notify user of transactions against their
accounts.• User can configure threshold amount for
notification based on any/all of account,transaction type or region, charge category
• Notification can be sent via e-mail, voice-mailor SMS/IM
• User can suspend notifications indefinitely orfor a defined period of time.
Example:
21
41 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Mega Bank Use CasesExample:
Configure NotificationThreshold
Suspend Notification
Resume NotificationAccountHolder
Process Transaction
TransactionSettlement
42 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Specifying Notification WorkflowExample:
Broad Scope; Minimum Detail;No mention of User Interface!
Use Case:Manage
NotificationThresholds
Use Case:Process
Transaction
Use Case:Process
Transaction
Check outputof Use Case:
ProcessTransaction
22
43 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Alternate form of Workflow Test:Given Bobma has account 1003592877And BobMa sets notification threshold to
$10,000 for all transactionsWhen the bank processes debit for 15,000 to
account 1003592877And the bank processes debit for 9,000 to
account 1003592877And the bank processes debit for 11,000 to
account 1003592877Then bobma receives notification for debit
15,000 to account 1003592877And bobma receives notification for debit 11,000
to account 1003592877
44 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Specifying Suspension WorkflowUse Case:
ManageNotificationThresholdsUse Case:
ProcessTransactionUse Case:Suspend
Notification
Use Case:View
Notifications
Use Case:Resume
Notification
Example:
23
45 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
GUI for Manage Notifications Tx• User Interface
implies specificfunctionality:– List of accounts– Ability to make
changes tonotifications
– List of activenotifications
• This functionalitycan be testedindependently of UI
Example:
46 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Single Transaction TestUse Case:
ManageNotifications
Data to be shown onManage Accounts Tab
Side effect of AddingA Notification
Data to be shownon Manage
Notifications TabMedium Detail; Medium ScopeStill no mention of User Interface!
Example:
Data to be shown onManage Accounts Tab
Data to be shownon Manage
Notifications Tab
24
47 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Business Rule Specs
Configuration Process TransactionThreshold per Charge Type
High Detail; Narrow ScopeCompletely ignores UI!
Example:
48 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Changing Level of Abstraction/Detail• Need to Reduce Detail or Reduce Scope
Broad NarrowScope
Det
ail
High
Lo
w
BusinessRules
Workflow
Transactions
Too vague(Rarely Happens!)
Too much detailUnmaintainable
25
49 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Agenda• Motivation• Changing the Role of Test Automation• Approaches to Test Automation
– Test Preparation Approach– Test Definition Language– Test Execution Interface
• Test Automation Strategy
50 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Why is Automation ApproachImportant?
• Common Failure Mode:–Choose tools, then try to make them work–Wrong tools can prevent achieving goals
• Better Approach:–Choose automation approach to achieve goals–Then, select tools to support it
26
51 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Common Approaches to TestAutomation
TestPreparation
TestLanguage
TestInterface
Test Data
Recorded Code Raw UI Global, StaticRefactored Keyword Adapter Per RunHand-written Data API Per Test
Our System
Interface BusinessLogic Database
Container Services
Test Scenario Name-----------------------
----------------------
-----------------------Clean Up
APIAdapterVia
Raw UI
How Set U
p?
Fixture(state)
Preconditions
1. Do Something2. Check Something
52 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
(C)OTS Record&Playback
TestPreparation
TestLanguage
TestInterface
Test Data
Recorded Code Raw UI # Global, StaticRefactored Keyword* Adapter Per RunHand-written Data API Per Test
Notes:* Keywords, if used, tend to be very low level:
•GotoWindowNamed: name•SelectFieldNamed: name•EnterText: text•(Not the same as true Keyword-Driven testing)
# Most COTS Tools operate at UI or HTTPinterface; many open-source tools do so as well
Poor OK GoodExample Driven X
Lega
cy
Workflow XSystem XBusiness Rules XComponent XUnit X
New
Workflow XSystem XComponent XBusiness Rules XUnit X
27
53 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
executiondefinition
• The tests are expressed in domain-specific vocabulary.• The tests are read & executed by a test interpreter written
by techies.
Keyword-Driven Tests
Prepared like Hand-Coded Tests butwith a much morelimited vocabulary.
Keyword
54 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Keyword-Driven Tests
TestPreparation
TestLanguage
TestInterface
Test Data
Recorded Code Raw UI * Global, StaticRefactored Keyword Adapter Per RunHand-written Data API Per Test
Notes:• While the Keyword Interpreter may go
against the Raw UI, it is better to delegateto an adapter if no API is available.
Poor OK GoodExample Driven X
Lega
cy
Workflow XSystem XBusiness Rules XComponent XUnit X
New
Workflow XSystem XComponent XBusiness Rules xUnit x
28
55 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Scenario Invoice Generation-New Customer
-----------------------------Given: Logged in as ClerkAnd: Item1, Item2 exist-----------------------------1. CreateCustomer “Acme”2. CreateAccount NewCust3. AddPurchase Item14. AddPurchase Item25. GenerateInvoice NewAcct6. ….
SUT
Sample Keyword-Driven Test(e.g. Cucumber, JBehave, or Fit)
ComponentUnder Test
ResultsDocument
Resultof step
Resultof step
Cucumber Library
Cucumber ScenarioRunner
CreateCustomer Interpreter
AddPurchase Interpreter
• Test script defined using keywords• Keyword Interpreter invokes underlying code• Can go direct to API or via an Adapter
56 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Exercise 3 – Keyword-Driven Test• Provide examples for the following workflow (Min. detail)
PlaceOrder
AuthoriseOrder
FulfillOrder
Over$1000
Author-ized?
ReviseOrder
Yes
YesNo
No
Call Handler Supervisor Fullfillment
Note: Can assume an input queue exists for each role if that helps checking.
29
57 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
executiondefinition
• The tests are expressed as tabular data by users.• The tests are read & executed by a test interpreter written
by techies.
Data-Driven Tests
Runs the same testscript many times;once per set of data.
58 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Data-Driven Test
TestPreparation
TestLanguage
TestInterface
Test Data
Recorded * Code * Raw UI Global,Static#Refactored Keyword Adapter Per RunHand-written Data API Per Test
Notes:* The underlying script may be either hand-written
or recorded and parameterized. But the datascenarios (input values and expected outputs)are almost always prepared by hand.
# The inputs/outputs are per test (per row) butthere may be global or per-run data used asreference data by the underlying script.
Poor OK GoodExample Driven X
Lega
cy
Workflow XSystem XBusiness Rules XComponent XUnit X
New
Workflow XSystem XComponent xBusiness Rules xUnit x
30
59 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Sample Data-Driven Test in FIT
• Same script is run for each row of table• Avoids duplication of test script.• Compact summary of input values & results• Sometimes called “Business Unit Test” or “Business Rule Test”
PayrolFixtures.WeeklyCompensationStandardHours
HolidayHours
HourlyWage
Pay( )
40 0 10 $40040 0 20 $80041 0 20 $83040 1 20 $840
41 1 20 $870
---Inputs--- Outputs
SUTComponentUnder Test
ResultsDocumentMarked up
TableFit
Library
Fit TestRunner
TableInterpreter
60 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Sample Data-Driven Test in FIT
• Same script is run for each row of table• Avoids duplication of test script.• Compact summary of input values & results• Sometimes called “Business Unit Test” or “Business Rule Test”
61 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Exercise – Business Unit Test• Rewrite the tests for the Invoice Total logic
using a Data-Driven Business Unit Test thattalks directly to the component that calculatesthe total.
• Focus on single-item invoices.– E.g. Each row describes the total expected for one line
item.• Suggested test cases are in the Testers’
Package• You may use the template provided by “Test
Automation” or you may invent your own.
62 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Agenda• Motivation• Changing the Role of Test Automation• Approaches to Test Automation
– Test Preparation Approach– Test Definition Language– Test Execution Interface
• Test Automation Strategy
32
63 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
What Does It Take...?• to be able to write tests like this?
• We need some technical skills to implementthe “fixtures” or “interpretters” of our testinglanguage, and either
• the right programming interfaces in thesystem, or
• we need to do extensive wrappering tosimulate them
64 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Keeping Tests Simple: Testing via API
• API’s need to be designed in– Design for Testability
• Requires collaboration with Dev’t– Agile fosters collaboration through co-located teams
CoreBusiness
Logic
UserInterface
Test Invoice Generation-New Customer
-----------------------------Logged in as ClerkItem1, Item2 exist-----------------------------1. CreateCustomer “Acme”2. CreateAccount NewCust3. AddPurchase Item14. AddPurchase Item25. GenerateInvoice NewAcct6. ….
What we want to write:
API
Intention-basedKeywords SUT
33
65 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
When There’s No API Available
• Large gap between:– what we want to write & what can be executed– Many tests to adjust when UI changes High Maintenance Cost
CoreBusiness
Logic
Test Invoice Generation-New Customer
-----------------------------Logged in as ClerkItem1, Item2 exist-----------------------------1. CreateCustomer “Acme”2. CreateAccoun NewCust3. AddPurchase Item14. AddPurchase Item25. GenerateInvoice NewAcct6. ….
UserInterface
Test Invoice Generation-New Customer
-----------------------------Goto Login creenEnter “Clerk” in UserName fieldEnter “Pw123Secret” in Password fieldEnter …..-----------------------------Goto Cust ScreenClick “New Customer”Enter “Acme” in Name fieldEnter “123 Main St.” in Addr fieldEnter …..GotoScreen( “Account” )Find customer “Acme”Click “Add Account”Enter “Credit” in Type fieldEnter …..
Without a test API we have to write:
IntentionObscuring
Code
CodeDuplication
No APISUT
66 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011Adapter
Keeping Tests Simple: Testing via Adapters
• Adapters can be tacked on– Single place to adjust when UI changes– But may be complex and error prone
CoreBusiness
Logic
Test Invoice Generation-New Customer
-----------------------------Logged in as ClerkItem1, Item2 exist-----------------------------1. CreateCustomer “Acme”2. CreateAccoun NewCust3. AddPurchase Item14. AddPurchase Item25. GenerateInvoice NewAcct6. ….
UserInterface
No API
What we want to write:Code inAdapter
Intention-basedKeywords SUT
34
67 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Test - After Architecture
System Under Test
• Must test through User Interface
Should weNotify?Process
Transaction
ConfigureNotificationThreshold
NotificationRules
TransactionInterface
ConfigurationUser
Interface
NotificationLog
WorkflowTest
DoNotification.
68 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
System Under Test
Test-Driven Architecture• Need to provide API’s to invoke functionality
directly
Should weNotify?
DoNotification.
ProcessTransaction
ConfigureNotificationThreshold
NotificationRules
NotificationLog
TransactionInterface
ConfigurationUser
InterfaceWorkflow
Test
35
69 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Test-Driven Architecture
Should weNotify?
DoNotification.
ProcessTransaction
ConfigureNotificationThreshold
NotificationRules
NotificationLog
TransactionInterface
ConfigurationUser
Interface
ConfigurationTX Test
70 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Test-Driven Architecture• With the right architecture, automating these
tests is trivial
Should weNotify?
DoNotification.
ProcessTransaction
ConfigureNotificationThreshold
NotificationRules
NotificationLog
TransactionInterface
ConfigurationUser
InterfaceNotificationRule Test
NotificationMethod Test
36
71 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
What About Legacy Systems?• How can we get automated regression tests in
place quickly?
72 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
Call me when you:• Want to transition to Agile or Lean• Want to do Agile or Lean better• Want to teach developers how to test• Need help with test automation strategy• Want to improve your test automation
Jolt Productivity Awardwinner - Technical Books
Coming Soon:
53
105 Copyright 2011 Gerard MeszarosMuch Ado About Agile 2011
References• For Success, Build Record/Playback into Your