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 he shares real-life testability examples which touch on the human process of building software including the relationship between testers and developers.

1. 1
Design for Testability
Who am I?
Nir Szilágyi
Finance, Risk & Compliance, Internet,
Telecom, CRM, Video Streaming.
Engineering, QE, QA, Release Eng
nszilagyi@paypal.com | norberts@gmail.com

2. 2
Goals vs Systems
What is Testability?
• How easy is to test software
• 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).

3. 3
What do the Experts Say?
What is Testability? – James Bach
James
Bach’s
dimensions
of
Testability
-­‐
link

4. 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

5. 5
Design"
"
Code"
"
Test
What is good design?
The
real
criteria
for
quality
of
design,
“minimizes
cost
(including
the
cost
of
delay)
and
maximizes
benefit
over
the
life>me
of
the
so?ware,”
-­‐
Kent
Beck
Design

6. 6
Service Architecture Example
Gateway
Service
B
Service
A
Data
Models
and
Rules
500
Data
Elements
SLA:
2
seconds
SLA:
200ms
Yes,
No,
Maybe
70%
30%
Simple
Data
Model
and
few
rules
Users
Application Layers Example
Service
Interfaces
Message
Types
Business
Workflow
Business
Components
Data
Access
Components
Data
UXliXes
DB
UI
Components
PresentaXon
Logic
Presentation layer
Service Layer
Business Layer
Data Layer
Cache
Users
Clients
Messaging

7. 7
• Separation of Concerns
• Single Responsibility Principle
• 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
• Define Data format for a layer and between
• Define clear contract between layers
• How are you going to test this?
Design

8. 8
• Separation of Concerns
• Single Responsibility Principle
• 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
• Define Data format for a layer and between
• Define clear contract between layers
• How are you going to test this?
Design
• Inner layer dependencies
• Cross layer dependencies
• Code dependencies
• Rule/Code separation
Design - Dependencies

9. 9
Application Layers Example
Service
Interfaces
Message
Types
Business
Workflow
Business
Components
Data
Access
Components
Data
UXliXes
DB
UI
Components
PresentaXon
Logic
Presentation layer
Service Layer
Business Layer
Data Layer
Cache
Users
Clients
Messaging
Testability traps
• Non
determinisXc
dependencies
• Race
condiXons
• Message
latency
• Threading
• CRUD
operaXons
on
shared
data
• Complexity
• Accidental
• EssenXal

10. 10
Distributed Multi-Flow Application Layers
Service
Interface
s
Message
Types
Business
Workflow
Business
Component
s
Data
Access
Components
Data
UXliXes
DB
UI
Compon
ents
PresentaXo
n
Logic
Presentation
Service
Business
Data
Cache
Messaging
Service
Interface
s
Message
Types
Business
Workflow
Business
Component
s
Data
Access
Components
Data
UXliXes
DB
UI
Compon
ents
PresentaXo
n
Logic
Cache
Messaging
Service
Interface
s
Message
Types
Business
Workflow
Business
Component
s
Data
Access
Components
Data
UXliXes
DB
UI
Compon
ents
PresentaXo
n
Logic
Cache
Messaging
User
Login
Add
to
Cart
Pay
Code
• Code
Testability
measurement
-­‐
>
How
painful
is
it
to
write
a
good
unit
test
• ComposiXon
over
inheritance
• No
cyclic
dependencies
• Dependency
injecXon
• Beck’s
five
rules:
• Passes
all
the
tests
• Reveals
intenXon
• No
duplicaXon
• Fewest
elements

11. 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 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”
“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
crabsman
takes
pride
in
his
work
an
strives
to
do
the
best
job
he
can.
WriXng
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.

12. 12
Testing
• Design
paderns
for
testability.
• Treat
test
code
almost
like
producXon
code.
• External
vs.
internal
factors
• Controllability
• Observability
• Service
interface
validator
(AOP)
Service Architecture Example
Gateway
Service
B
Service
A
Data
Models
and
Rules
500
Data
Elements
SLA:
2
seconds
SLA:
200ms
Yes,
No,
Maybe
70%
30%
Simple
Data
Model
and
few
rules
Users

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

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

15. 15
Design for Testability…
Testable software -> Goal
Good design, clean code, effective testing -> Systems

16. 16
…Thank
You…
nszilagyi@paypal.com | norberts@gmail.com