Joep Schuurkes (Posts about devops)

An approach to teaching Agile 20 years after the Agile Manifesto

Joep Schuurkes — Mon, 26 Apr 2021 14:54:34 GMT

For a few weeks I've been thinking about how I would teach Agile¹ in 2021, 20 years after the Agile Manifesto was published. After sharing my thoughts at CitCon Europe 2021 Virtual and having an interesting conversation about the state of Agile and how to teach it, I figured it's time to write a blog post about it.

Why I started thinking about this

As Allan Kelly stated in a 2018 blog post:

"Agile won the war but lost the peace."

Everyone is doing Agile, even though very few people are living the dream promised by Agile. This makes it very difficult to use "Agile" as a label, as a name for something. When someone says "Agile", are they referring to what you're already doing or to something they think you should be doing?

Additionally, the Agile Manifesto was written in 2001, based on what its authors were doing in the 1990s in response to the common ways of doing software development of that time. And since the Manifesto we've seen the introduction of Lean, of DevOps, and of CI/CD. So the amount of history that comes with Agile is large and it raises the question how much (if any) we should teach - especially since a lot of it is folklore instead of history². Doing Agile's history justice would probably cost more time than makes sense if your goal is to teach people how to develop software in an Agile way³. And a lot of that history was a relatively long time ago, which is why I titled my CitCon session "Teaching Agile to people younger than the Manifesto".

Your CI/CD pipeline does not run regression tests

Joep Schuurkes — Mon, 05 Aug 2019 21:47:51 GMT

CI/CD pipelines

The purpose of a CI/CD pipeline is to allow you to deliver small changes in a fast and controlled way. Without any tests in your pipeline you would gain a lot of speed. You'd also lose a lot control, which is why people in general do run tests in their pipeline. The purpose of these tests is to check if that stage of the pipeline meets the minimum level of acceptable quality for that stage.

For example, commit stage tests will consist of mostly unit tests, a few integration tests, and even fewer end-to-end tests, because early in the pipeline speed is more important than comprehensiveness. When I commit my changes, I want the results fast enough so that I will wait for them - ready to fix any issue that might occur.

Regression testing

There are many definitions of regression testing, as you can read in Arborosa's blog post on the topic. I have always defined regression testing along the lines of "testing the parts that weren't impacted by a change to see if they really weren't impacted." (Which is really weird if you start thinking about it: something is regression testing depending on your knowledge of the system and the change.)

The tests in your pipeline are regression tests, …

Most of the tests that run in your pipeline are regression tests. Your commits are small and you have a lot of tests, so most of those will cover parts of the system that shouldn't have been impacted by your changes. So yes, regression tests.

Reflections on my testing manifesto

Joep Schuurkes — Sat, 22 Dec 2018 16:43:10 GMT

Earlier this month I published my Manifesto for software testing. This manifesto is my attempt to bring together what I have learned about testing from the context-driven, agile and DevOps communities. Below you can find the manifesto with my reflections on it.

1. Testing is investigating in order to evaluate a product.

This definition is clearly influenced by James Bach's "questioning a product in order to evaluate it". I'm not sure at which point I started misremembering his definition as "investigating a product...", but it works well with a change I did make intentionally: moving "a product" to the second part of the definition. As explained in 6. I believe that in order to evaluate the product, we need to investigate a number of different things, not only the product.

Manifesto for software testing

Joep Schuurkes — Tue, 04 Dec 2018 19:44:51 GMT

1. Testing is investigating in order to evaluate a product.

2. An evaluation is a judgement about quality – quality being value to persons who matter.

3. This makes testing a fundamentally human and contextual activity.

4. As such, testing is an exploratory and open-ended activity, requiring continuous evaluation of and experimentation with our practices.