# Chaos engineering is a testing discipline Chaos engineering deliberately distances itself from [[Software Testing|testing]] practices, but the difference is mainly philosophical. <iframe width="560" height="315" src="https://www.youtube.com/embed/z1-_R-h2unE" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> ## Similarities Chaos engineering and some forms of [[Operational testing]] such as [[Performance Testing]] or [[Reliability|Reliability Testing]] have significant overlap. ### Goal They seek to prepare an application for production by inducing failures before it goes live. Their end goal is to improve and stabilize user experience throughout extreme situations (high load, component failure). ### Destructive testing for constructive refactoring They often employ destructive or experimental methods to stress an application. ### Primary area of concern They are concerned with the reliability of an application and its ability to handle failures. ### Tools Many tools used for [[Disaster Recovery]], [[Load Testing]], and [[Failover Test|Failover Testing]] can be used in chaos experiemnts. ## Differences ### Philosophy Testing traditionally seeks to verify results against an expected outcome, whereas chaos engineering defines the expected outcome (called a [[Chaos engineering terminology#^3a4133|hypothesis]]) but then seeks to *dis*prove it. While many of the activities involved in, for example, reliability testing and chaos engineering are the same, it's the _attitude_ that is different. In many ways, chaos engineering is a call for a revolution of attitude in software testing in general. Many [[Principles of chaos engineering|principles of chaos]] can be applied to other forms of testing. ### [[Chaos engineering terminology|Terminology]] Chaos engineering uses more scientific terminology than does testing. This is a deliberate choice, as chaos engineering embraces the broader framework of the scientific method rather than the somewhat repetitive framework that many testing practices are built on. ### Scope The main differences between chaos engineering and other forms of testing are in their scope. [[Performance Testing]], for example, is primarily concerned with the speed and responsiveness of an application and how they affect user experience. [[Availability|Availability testing]] is concerned with system uptime. Chaos engineering overlaps with both but is broader in scope, going further with disaster recovery and infrastructure-level experiments that touch many other types of testing. ## So why are they typically considered separate disciplines? ### Chaos engineering and testing have different origins. Chaos engineering and testing are two attempts to solve the same problem, but from different starting points. Testing was born out of a need for business needs to be represented in development and for development limitations to be accounted for in business requirements. Chaos engineering began from the [[Site Reliability Engineering]] space as a need to handle, as opposed to prevent, outages from happening. Both are [[Shift-right testing|shift-right]] movements. They just started in different parts of the process. ### Chaos engineers want to emphasize scientific rigor Chaos engineers want to bring scientific rigor to their work, rather than the preconceived notions that testers often bring. Lumping chaos engineering in with these other forms of testing might dilute the strength of this very opinionated stance. However, I think this is a non-issue because I would rather see _testing_ change and adapt to encompass this new way of approaching things than exclude chaos engineering because it's too different. ## See also - [[Chaos Engineering]] - [[Performance Testing]] - [[Operational testing]] - [[Software Testing]]