The definition of “done” is a historic problem in software development. Developers and their product stakeholders tend to look at this problem as “how well the delivered product matches the requirements.” However, there is another problem with “done”, and that is the evaluation as to when a release is ready to be set free to run amok in the wild. This becomes even more complicated when we look at things like working in the cloud where your release may include new system resources – are those “done” at a different time? In a period of continuous release cycles - are things ever done?

This session is based on stories around determining done-ness. We will look at test-cases and test-paths as an evaluation criteria. We will talk about how UI interactions affect the ability to determine “done.” We will also look at risk enhancers, such as configurable business logic, CI/CD, and Infrastructure as Code, and how those enhancers affect our ability to be understand “done.” Lastly, we will discuss some real-world stories about the QA of complicated systems.