Let’s continue the from the last post where you saw a working implementation of a learning environment called Pacumen. Here I want to provide you more details of the basis for this kind of work and use that as a springboard for thinking about how testers fit in these situations.
Category: Testing
Testing and AI
What’s been interesting in the testing world — at least the part of it that I hang out in — is the application of different AI-based learning algorithms to the act of exploring an application and seeing what (if anything) that tells us regarding the algorithmic and non-algorithmic parts of the testing discipline. Let’s talk about this because I think is fertile ground for testers to be exploring.
Testing As Experiments Around Project Forces
A lot of people writing about testing draw the correlation between testing and experimenting. You’ll often hear something like “testing is evaluation through experimentation.” But, as advice to testers, this falls far short of helpful if the notion of what being a good experimenter entails is not covered. So let’s talk about that.
Continue reading Testing As Experiments Around Project Forces
Testing and Model Building
In his book The Black Swan, Nassim Taleb talks about “Platonicity,” which is defined as the desire to cut reality into crisp shapes. This is a form of dividing up a large domain into a smaller domain. This, by definition, means establishing certain boundaries. This is a key part of how people experiment and thus of how they model … and thus of how they ultimately explain things. So let’s talk about what this has to do with testing.
The Unique Discipline of Testing
In my post on porting development lessons to testing I mentioned getting into the ideas of what makes the testing role something uniquely distinct from that of the development role. So let’s talk about this.
Development Lessons Ported to Testing
There’s often talk about how developers should think more like testers. But there’s often not as much discussion about the corollary: testers learning to think more like developers. So let’s talk about this.
Levels of Description
I’ve talked about the notion of test description languages quite a bit. A lot of these discussions get into debates about being declarative versus imperative, or focusing on intent rather than implementation. All good things to consider. But such “versus” terminology tends to suggest there is a “right” and a “wrong” when often what you have is “What makes sense in your context.” And you may have to flexibly shift between different description levels. Let’s talk about this.
Describing My Role
Recently I engaged in a fun exercise with a test team wherein each of us had to answer the following question: How do I describe my role? It’s always interesting to me to see how people answer this, particularly in the fields of testing and quality assurance. So here I’ll provide the answer I gave, along with a bit of context for it.
My Future in Testing
I had two major series of thematic posts that I tried out this year: Modern Testing and Indefinito. The former was eminently focused on the tactical and the latter more on the strategic and perhaps even philosophical. In some ways these provided my focus as I find myself on the doorstep of 2017.
Testing and Things That Matter
I wrote about how testing is like writing fiction. Testing can actually influence reading fiction as well. And reading fiction can be great practice for exploration in a lot of ways. I recently came across a good example of that.
Test to Put Pressure on Design
In a previous post on test dogma and tradition, I talked about the famous “test pyramid” as an example of what people cling to as means of explanation. My concern there was that people often run too far with this or draw the wrong conclusions from it. Let’s look at a particular example of that.
The Challenge of Testing
Awhile back I talked about what makes testing complicated. To be honest, that post is embarrassingly written as I look back on it. That said, I think there is some value in what it says. But to show how my thinking has refined, as well as become a bit more operational, let’s piggy-back on my previous “code as specification” posts and look at why testing is challenging.
Driving Design with Code as Specification
This post follows on from my code is a specification. I highly recommend reading that post to get the context because here I’m going to add a bit to the sample code from that post. This is being done to illustrate the idea of test code and production code working together to act as an executable specification. Here I’m going to focus a bit on how this has relevance to the business as well.
When Code Is The Specification
Early on I talked about business needs becoming specs that become code. More recently, in my modern testing posts, I talked about the idea of production code being the specification of behavior. I wasn’t necessarily very descriptive in all of that, however. Let’s see if I can do better here.
The Use of Tradition and Dogma in Testing
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.
The Integration Pact
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.
Integration and Integrated, Part 2
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.
Integration and Integrated, Part 1
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.
Modern Testing and the Lucid Approach
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.
Modern Testing and the Artifact Crutch
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.