Abstract: The software delivery pipeline is the process of taking new or changed features from developers and getting them quickly delivered to the customers by getting the feature deployed into production. Testing within continuous delivery pipelines should be designed so the earliest tests are the quickest and easiest to run, giving developers the fastest feedback. Successive rounds of testing lead to increased confidence that the code is a viable candidate for production and that more expensive tests—be it time, effort, cost—are justified. Manual testing is performed toward the end of the pipeline, leaving computers to do as much work as possible before people get involved. Although it is tempting to arrange the delivery pipeline in phases (e.g., functional tests, then acceptance tests, then load and performance tests, then security tests), this can lead to serious problems progressing far down the pipeline before they are caught.
Be prepared to discuss your pipeline, automated or not, and talk about what you think is slowing you down and what is keeping you up at night. In this interactive workshop, we will discuss how to arrange your tests so each round provides just enough testing to give you confidence that the next set of tests is worth the investment. We'll explore how to get the right types of testing into your pipeline at the right points so that you can determine quickly which builds are viable candidates for production.
Learning Outcomes: - Each attendee should leave with a better understanding of their current and desired software delivery process.
- The pipeline is about building confidence that the software is a viable candidate for production. Or realizing as early as you can that it isn’t.
- Do just enough of each type of testing at each step in the delivery pipeline to determine if further testing is justified.
- Different stages of the pipeline are for learning different things about your delivery process. Use them appropriately.
- Do the most expensive tests last. Those are often the manual or subjective ones.
- The pipeline offers a lot of opportunities to do tests that you might not have done if you had to set aside an explicit block of time to do them.
Attachments:
