Conference:March 6-8, 2017
Workshops:March 9-10, 2017
Presentation: After Acceptance: Reasoning About System Outputs
Location:
- Whittle, 3rd flr.
Duration
Day of week:
- Wednesday
Level:
- Intermediate
Persona:
- Developer
Key Takeaways
- Understand practical real-world approaches to improving the testing of your systems
- Learn how to test your system live in production
- Analyze how to test your code against real data before it reaches production
Abstract
Modern software development allows us to prove that new work is functionally complete. We write a set of executable specifications. We automatically execute them in the form of acceptance tests as part of our continuous delivery pipeline. When all the tests pass, we are done!
This approach is superior to what came before it but is by no means perfect. Testing frequently ends at the point of release, meaning that bugs in production can be caught late and by the end users. Pragmatism dictates that exhaustive acceptance testing is infeasible. Indeed, tests are likely to represent only a simplified version of user interactions. In production, data will almost certainly be generated by code paths that have not been fully exercised in acceptance tests. That data is usually decoupled from our acceptance testing environment. If the current version of the system generates durable data, how do we know that future versions will consider it valid and act upon it appropriately? How can we find out about bugs after acceptance, but before our customers do?
This session will walk through some techniques for bringing your testing to production. It will show you how to sanity check a live system using end to end testing, limiting interference with real user interactions and outputs. Finally it suggests ways to observe and integrate real production data into a continuous delivery pipeline and assert on the validity of the production system's outputs.
Interview
Since I decided to go independent a couple of months ago, I’m focusing on two things: My Cycling app (https://cyclema.ps), which has been my passion and hobby for the past few years. In addition I’m working in performance optimisation of a ratings prediction engine for the ITV TV channel.
These days we’re pretty good at testing. Lots of development happens pretty reasonably: Test driven, with integration and acceptance tests. We can therefore release and release frequently, with confidence that our new features actually work. But there’s frequently a big blind spot in our testing: data.
A continuously delivered system continuously changes. Therefore data that’s been created and modified by successive releases of the system needs to continue to be valid and handled reasonably by future releases of the system. Standard testing approaches just do not do this - tests are usually either simplified user interactions, or very specific cases to guard against regressions. Given that exhaustive testing is impossible, testing with the real data generated from the real system opens a whole new set of opportunities for catching possibly catastrophic issues early.
This approach, that I’ve employed in few workplaces has been a revelation: Basically get your code in contact with production or production like data prior to release and run various invariant type tests against it. I’ve seen this approach catch a large number of issues, from migration failures, logic issues (exceptions), memory issues etc.
It’s your data, it’s there, use it to write tests!
You’ve got to be pretty good at your testing in order to bring it to your production system with its production data. So I’d say Lead, Architect, Developer. It’s language agnostic.
Medium. If you understand testing and continuous delivery, that is.
A concrete plan on how to easily test more using production data. I would like a ‘can do’ person to go to work the next day and think how they can bring the data in their CI environment and make it easy to write tests, so that they can catch the next major bug early, before the code hits production.
I don’t think that a particular type of tech is what’s more disruptive right now. It’s more of a frame of mind. It started many years ago with the move away from enterprise java to more simple models and it’s continuing now. You don’t need a complicated framework that’s impossible to debug and ties you down to a vendor. You need a tightly knit architecture that you build to suit your purposes. It’s the move from expensive ‘enterprise’ architecture to simple solutions that you build to solve your problems.
Similar Talks
Tracks
-
Architecting for Failure
Building fault tolerate systems that are truly resilient
-
Architectures You've Always Wondered about
QCon classic track. You know the names. Hear their lessons and challenges.
-
Modern Distributed Architectures
Migrating, deploying, and realizing modern cloud architecture.
-
Fast & Furious: Ad Serving, Finance, & Performance
Learn some of the tips and technicals of high speed, low latency systems in Ad Serving and Finance
-
Java - Performance, Patterns and Predictions
Skills embracing the evolution of Java (multi-core, cloud, modularity) and reenforcing core platform fundamentals (performance, concurrency, ubiquity).
-
Performance Mythbusting
Performance myths that need busting and the tools & techniques to get there
-
Dark Code: The Legacy/Tech Debt Dilemma
How do you evolve your code and modernize your architecture when you're stuck with part legacy code and technical debt? Lessons from the trenches.
-
Modern Learning Systems
Real world use of the latest machine learning technologies in production environments
-
Practical Cryptography & Blockchains: Beyond the Hype
Looking past the hype of blockchain technologies, alternate title: Weaselfree Cryptography & Blockchain
-
Applied JavaScript - Atomic Applications and APIs
Angular, React, Electron, Node: The hottest trends and techniques in the JavaScript space
-
Containers - State Of The Art
What is the state of the art, what's next, & other interesting questions on containers.
-
Observability Done Right: Automating Insight & Software Telemetry
Tools, practices, and methods to know what your system is doing
-
Data Engineering : Where the Rubber meets the Road in Data Science
Science does not imply engineering. Engineering tools and techniques for Data Scientists
-
Modern CS in the Real World
Applied, practical, & real-world dive into industry adoption of modern CS ideas
-
Workhorse Languages, Not Called Java
Workhorse languages not called Java.
-
Security: Lessons Learned From Being Pwned
How Attackers Think. Penetration testing techniques, exploits, toolsets, and skills of software hackers
-
Engineering Culture @{{cool_company}}
Culture, Organization Structure, Modern Agile War Stories
-
Softskills: Essential Skills for Developers
Skills for the developer in the workplace