With the drive for continuous integration and delivery, the implications and approaches for designing more testable software are receiving substantial discussion and debate. What does testability really mean in practice? How do you take the idea of testability—how easy it is to test software—and put it into action through the different dimensions of designing and testing a real-world product? Nir Szilagyi recognizes that the challenges of difficult-to-test software can transform a testing cycle from a small automation and exploratory effort to a long struggle of test preparation, execution, and debugging. He says testability starts with software design, goes through implementation, and encompasses building modular software, abstraction, simplicity, clear data interface, separation of business logic into self-sustained entities, and more. On the technical side of testability, Nir explores ways quality engineers and leaders can influence testability from early development through deployment. From his experiences Nir shares real-life testability examples which touch on the human process of building software including the relationship between testers and developers.

1. W6
Session
10/26/2016 11:30:00 AM
Design for Testability in Practice
Presented by:
Nir Szilagyi
PayPal
Brought to you by:
350 Corporate Way, Suite 400, Orange Park, FL 32073
888-­‐268-­‐8770 ·∙ 904-­‐278-­‐0524 - info@techwell.com - http://www.starcanada.techwell.com/

2. Nir Szilagyi
PayPal
Senior quality engineering manager Nir Szilagyi brings more than sixteen years of
experience to the risk platform engineering team he leads at PayPal. Previously at
eBay, he led the products platform quality engineering team in Israel and US. In
both companies, Nir led the team transformation from a classic advisory group to
an agile engineering team, focusing on quality throughout the product
development lifecycle. Passionate about automation and testing smarter, Nir
believes that agility, engineering solutions for quality, influencing testability, and
open communication drive organizations forward. Nir had been involved in
shaping eBay's test automation framework and is leading the development of
similar quality initiatives at PayPal.

3. 9/23/2016
1
Design for Testability
Who am I?
Ni S ilá iNir Szilágyi
Finance, Risk & Compliance, Internet,
Telecom, CRM, Video Streaming.
Engineering, QE, QA, Release Eng
nszilagyi@paypal.com | norberts@gmail.com

4. 9/23/2016
2
Goals vs Systems
What is Testability?
• How easy is to test software
Th hidd t f ft• The hidden cost of software
• Higher Testability –
• Better tests (easier env setup, data prep)
• Higher tester efficiency
• Faster tests
• Better debugability (is that a word?)
• Better test efficiency and effectiveness
• Pain (problem) and B/WCS (solution).

5. 9/23/2016
3
What do the Experts Say?
What is Testability? – James Bach
James Bach’s dimensions of Testability ‐ link

6. 9/23/2016
4
What is Testability? – Kelly & Kedemo
Ben Kelly and Maria Kedemo’s dimensions of Testability ‐link
Why does it matter?
• Testing takes too long.
• What do we have to do to fail the code?
• How long till we find the issue?
• Who can fix the code and how fast?
• How soon ready for re-test?
• An aspect of Technical Debt (SQALE)
• The hidden cost of software

7. 9/23/2016
5
DesignDesign
Code
Test
What is good design?
Design
The real criteria for quality of design,
“minimizes cost (including the cost of
delay) and maximizes benefit over the
lifetime of the software,” ‐ Kent Beck

8. 9/23/2016
6
Application Layers Example
Users Clients
Service Interfaces Message Types
UI Components Presentation Logic
Business Workflow Business Components
Data Access Components Data Utilities
DB
Service Architecture Example
500 Data ElementsYes, No, Maybe
Users
Gateway
Service B Service A
500 Data Elements
SLA: 2 seconds SLA: 200ms
, , y
70%30%
Data Models and Rules Simple Data Model and few
rules

9. 9/23/2016
7
• Separation of Concerns
• Single Responsibility Principle
Design
• Principle of Least Knowledge
• Do not Repeat the Functionality
• Unified Exception Handling Mechanism
• Points of Control and Observation (AOP)
• Naming conventions - for test code too
D fi D t f t f l d b t• Define Data format for a layer and between
• Define clear contract between layers
• How are you going to test this?

10. 9/23/2016
8
• Separation of Concerns
• Single Responsibility Principle
Design
• Principle of Least Knowledge
• Do not Repeat the Functionality
• Unified Exception Handling Mechanism
• Points of Control and Observation (AOP)
• Naming conventions - for test code too
D fi D t f t f l d b t• Define Data format for a layer and between
• Define clear contract between layers
• How are you going to test this?
• Inner layer dependencies
• Cross layer dependencies
Design - Dependencies
y p
• Code dependencies
• Rule/Code separation

11. 9/23/2016
9
Application Layers Example
Users Clients
Service Interfaces Message Types
UI Components Presentation Logic
Business Workflow Business Components
Data Access Components Data Utilities
DB
Testability traps
• Non deterministic dependencies
• Race conditions
• Message latency
• Threading
• CRUD operations on shared data
• Complexity• Complexity
• Accidental
• Essential

12. 9/23/2016
10
Distributed Multi-Flow Application Layers
User
Login
Add to Cart
Pay
Service
Interface
s
Message
Types
UI
Compon
ents
Presentatio
n Logic
Service
Interface
s
Message
Types
B i
UI
Compon
ents
Presentatio
n Logic
Service
Interface
s
Message
Types
UI
Compon
ents
Presentatio
n Logic
Business
Workflow
Business
Componen
ts
Data Access
Components
Data
Utilities DB
Business
Workflow
Business
Componen
ts
Data Access
Components
Data
Utilities DB
Business
Workflow
Business
Componen
ts
Data Access
Components
Data
Utilities DB
Code
• Code Testability measurement ‐ > How painful is it to
write a good unit testg
• Composition over inheritance
• No cyclic dependencies
• Dependency injection
• Beck’s five rules:
• Passes all the tests• Passes all the tests
• Reveals intention
• No duplication
• Fewest elements

13. 9/23/2016
11
A Note on Clean Code
“Clean code is like a well written prose. Clean code
never obscures the designer’s intent but rather is full
of crisp abstractions and straightforward lines ofof crisp abstractions and straightforward lines of
control” – Grady Booch
“Clean code does one thing well” – Bjorn
Straustroup
“Clean code can be read and enhanced by a
developer other than its original author. It provides
one way of doing one thing” – “Big Dave Thomas”one way of doing one thing Big Dave Thomas
“Clean code always looks like it was written by
someone who cares. There is nothing obvious you
can do to make it better” – Michael Feathers
A Note on Craftmanship
A craftsman takes pride in his work an strives to do the best
job he can.
Writing clean code is what you must do in order to call
yourself a professional. There is no reasonable excuse to do
anything less than your best.
Sense of ownership. You
fork it, you write it, you
own it.

14. 9/23/2016
12
Testing
• Design patterns for testability.
• Treat test code almost like production code.
• External vs. internal factors
• Controllability
• ObservabilityObservability
• Service interface validator (AOP)
Service Architecture Example
500 Data ElementsYes, No, Maybe
Users
Gateway
Service B Service A
500 Data Elements
SLA: 2 seconds SLA: 200ms
, , y
70%30%
Data Models and Rules Simple Data Model and few
rules

15. 9/23/2016
13
Design Patterns for Test Code
• Factory (ex. abstract request types)
• Builder (ex. construct Service Request)
• Singleton (ex. DB connection)
• Façade (ex. abstract test logic)
• Command (ex. controlling UI elements)
• Template (ex Test objects)• Template (ex. Test objects)
• Learn learn learn
Upfront
A Note on the Role of the Test Manager
• Upfront
• As you go
• Look at the code
• Be there
• Relationships
Confidence• Confidence
• Hands on vs. technical leadership

16. 9/23/2016
14
The Basic Testing Needs
Observability:
• The ability to see the product
we are testing
Controllability:
• The ability to invoke any
possible state orwe are testing
• The ability to determinate
test status and reports
• The ability to observe
behavior and output
possible state or
combination of states of
the product
• The ability to manipulate
interim behavior or
outputs
More Test side impact
• Tester Knowledge
• Team compositionTeam composition
• Relationships
• Eng, PO, Architects
• Environment
• Data, Data, Data
• Dev Process, CI, CD.
• Test Plan - Review

17. 9/23/2016
15
Design for Testability…
Testable software -> Goal
Good design, clean code, effective testing -> Systems

18. 9/23/2016
16
…Thank You…
nszilagyi@paypal.com | norberts@gmail.com