It’s become tradition — with a bit of dogma — to point to triangles and quadrants to “explain” things about testing and development. A good case in point is presented in the article Agile Testing Automation. My goal is not to critique the article but rather to use it to highlight what I see as some of the problem. So let’s subject tradition to some rational inquiry and let’s subject dogma to a bit of scrutiny.
In previous posts about the integration / integrated distinction (see part 1 and part 2 of that series), I talked about how there is in fact a distinction and provided a little rationale behind why this distinction currently matters. So now let’s talk a little “around” the concept of integration — not integrated — and see where this takes us.
In the previous post in this series, I talked about the counterargument of there being no distinction between integration and integrated. That post ended on a question. In this post, I will start from the presumption that there is a distinction between the terms and explore that a bit.
Here I’ll talk about the difference between the terms integration and integrated when applied to testing. You may read that and say “Um, there is no difference, is there?” Well, let’s talk about it.
Awhile back I talked about being cross-discipline associative. I did something similar to this approach when I asked what time travel could teach us about testing. Let’s see how this works with another domain entirely.
Here I’ll cap off my current round of “modern testing” posts by discussing a bit about the lucid approach that I’ve brought up along the way.
I’ve gone through a lot of posts on modern testing and I’m nearing the conclusion of my thoughts on this. (Or so we can hope, right?) Here I’ll recap a bit and then push forward.
In my previous post on modern testing and resilience, I indicated that testing and quality assurance spend a lot of their time, as disciplines, being in danger from their own practitioners. This is most often a problem when the disciplines are under pressure to change. Here I’ll focus on that a bit, with the understanding that these are obviously purely my opinions, even if they seem stated as fact.
This post follows on from the previous (see part 1 and part 2). Here I’ll close out this series of posts by performing a bit more abstraction and finish up with some thoughts about how and to what extent the Cucumber abstraction fits in.
In the first post of this series, I got us set up with a Serenity repository using Maven as our build tool. I also started us on the path of applying Cucumber-JVM by putting a feature file in place. In this post we’ll start tying Cucumber into Serenity’s runtime operations.