EDA for QAs

Event driven
architecture for
QAs
© 2020 ThoughtWorks

Agenda
• What is an event driven architecture
• Event-driven architecture models
• Challenges with respect to testing
• Ways of testing EDA

What is an event?
An event is not the same as an
event notification
An event is any significant
occurrence or change in state

What is an event
driven architecture
An event-driven architecture consists of event producers that
generate a stream of events, and event consumers that listen
for the events.

Who are the participants
in an Event-driven
Architecture?
Producers: Who emitted the event?
Consumers/Listeners/Sinks: Who is waiting for the event to
happen?
Processors: Who will consume the event?
Reactions: What happen because of the event emitted?
Messaging Infrastructure: How will the event be transmitted?

How does event-driven architecture work?

Event-driven
architecture
models
• This is a messaging infrastructure based
on subscriptions to an event stream.
With this model, after an event occurs,
or is published, it is sent to subscribers
that need to be informed.
Publisher/Subscription model
• With an event streaming model, events
are written to a log. Event consumers
don’t subscribe to an event stream.
Instead, they can read from any part of
the stream and can join the stream at
any time.
Event streaming model

When to
use EDA
Multiple subsystems must process the
same events.
Real-time processing with minimum time
lag.
Complex event processing, such as pattern
matching or aggregation over time
windows.
High volume and high velocity of data,
such as IoT.

Challenges in testing EDA
Integration Testing
and Debugging
Struggling
Coordination
Decoupling of
Databases
Complexity Performance
tracing

Testing EDA
Functional Testing
Non-Functional Testing

Functional Testing
UNIT TESTING INTEGRATION
TESTING
CONTRACT
TESTING
SYSTEM
TESTING

Non-Functional Testing
PERFORMANCE
TESTING
RESILIENCE TESTING SECURITY TESTING

What are we
testing in
Performance
Testing
To find all potential bottlenecks causing
performance issues
Identify the capacity of the application
to handle load
Identify the optimal infrastructure
required to handle peak load
Benchmark the endpoints for existing
performance

Metrics to measure
Data Rate - number of input events
processed per second
NumberOfMessagesSent
NumberOfMessageDeleted
ApproximateNumberOfMessagesVisible
Latency - time taken for the output
events to emerge from the system
after the input event happened.
Information Latency
System Latency

Prerequisites before starting the perf testing
• Get the expected load
• Enable Distributed Tracing
Throughout the Enterprise
which includes monitoring and
logging for all the events
• Setup logging and monitoring
for all the downstream system
and upstream systems
• Setup perf environment
• Setup test data (should not be
mocked)

Factors which
impact
Performance
Network input and output to and from the
message queue
The efficiency of the message queue
The efficiency of the algorithms processing
the event data
The structure of the event messages can
affect the system performance.

Performance Test Visualization

Performance
Testing tools
• Locust
• Gatling
• Apache JMeter
• Blazemeter

Resilience
testing
Resilience testing is one part of
non-functional software testing
that includes compliance,
endurance, load and recovery
testing.

How resilience testing works
Select a system to test.
Setup an isolated test environment
• Identify the relevant metrics
• Establish a performance baseline
• Introduce disruptions & measure impact
• Take preliminary conclusions & discuss with the team
Apply the principles of chaos engineering:

Example -
Network
Disturbances
• The Linux tool TC allows the manipulation of traffic
control settings for specific network devices on AWS
EC2 (Amazon Elastic Compute Cloud)
• Pumba is a wrapper around tc that makes it easier
to selectively apply simulated network issues in
Docker containers.
• tc netem functionality allows manipulating several
aspects pertaining to the delivery of packets
• For instance, suppose you want to induce 10% of
packet loss on the eth0 interface or a delay of 200ms
to scheduler
• tc qdisc add dev eth0 root netem loss 10.00
• tc qdisc add dev eth0 root netem delay 200ms

Issues
Identified in
EDA after
resilience
Testing
• Awareness about logging improvements
(formatting, level, missing diagnostic
messages)
• Improvements to recovery of broken
connections to the Message queue
• Issues caused by malformed messages
• Delay and congestion of message queue due
to node not responding.
• Events not flowing due to memory leaks.

Tools for
Resilience
testing
• The Netflix Simian Army
• Chaos toolkit
• Pumba—Chaos testing for Docker
• FIT: Failure injection testing

Security Testing
Handling of Events
Logging should be
taken care
Multi layer auth
token
Security of endpoints
via pub/sub
Security Threat
Modelling

References
• https://docs.microsoft.com/en-
us/azure/architecture/guide/archit
ecture-styles/event-
• https://cloud.google.com/pubsub/
docs/overview
• https://www.slideshare.net/secret
/2BwWwpiuMJAyNs

About me
LinkedIn Profile:
https://www.linkedin.com/in/kumar-saurabh-
8005a324/
Email id(office): saurabhk@thoughtworks.com
Email id(Personal): kr.saurabh7@gmail.com

EDA for QAs

More Related Content

What's hot

Similar to EDA for QAs

More from vodQA

Recently uploaded

EDA for QAs