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.
Category: Testing
Modern Testing and Resilient Strategy
In two previous posts (on design pressure and sources of truth) I talked about the context that a modern test team is often fitting in with. Here I’ll get more specific, particularly in regards to some strategic elements.
Modern Testing and Sources of Truth
In a previous post, on testing and design pressure, I closed by saying that certain elements of decisions need to be encoded as artifacts, but that putting appropriate pressure on design meant minimizing those artifacts. Here I’ll talk a bit about that and what this means for test teams.
Modern Testing and Design Pressure
I’ve recently had reason to give some training on my overall philosophy and rationale for the introduction of Quality Assurance and Testing into modern development environments. I’ll put up a few posts as an attempt to gather my own thoughts and check if my own thinking is consistent.
Conceptualizing Test Intersections
In my previous post on intersections of testing, I set the stage for how testing is an activity that takes place at various points of intersection. Here I want to conceptualize that idea a bit more and provide some focus on what it means from an operational standpoint.
The Intersections of Testing
A lot of testers I know come across Joe Rainsberger and his declaration that integrated tests are a scam. This always leads to interesting discussions so I figured I would use this post to distill my own thoughts particularly because the opinions of “scam-based testing” are usually predicated upon a profusion of testing terminology.
The Art of Attention to Detail in Exploratory Testing
Testers must have the ability to utilize exploratory testing as well as scripted testing. But exploratory testing is actually not the entirely free-form exercise that some people associate it with. So let’s talk about that.
Continue reading The Art of Attention to Detail in Exploratory Testing
Gaming Like a Tester
Previously I talked about testing like a gamer. So now let’s talk about the other side of that.
The Intuition for Abstraction
I talked about a particular test technique and how intuition can fail us. I’ve also talked a lot about testing and abstraction. But is there an intuition for abstraction? I’m thinking there is. And I’m thinking the better testers I’ve known have shown it. But I struggle with how to make this a useful concept in terms of building up this skill in testers.
Testing Like a Gamer
I’ve said before that testing games is hard and I’ve also shown that I created a game for interviewing test candidates. You wouldn’t be far off the mark to figure that I put a large focus on game-related thinking. This is because, in my experience, such thinking makes some of the best testers. But let’s talk about that a bit.
The Soul of Testing
I recently read the book called Uncertainty: Einstein, Heisenberg, Bohr, and the Struggle for the Soul of Science, written by David Lindley. It made me think a bit about the “soul of testing.”
Test-Driven Is Not (Necessarily) Test-First
In the past I questioned whether our test and development practices become defocused. As most people in the industry know, there has been a lot of comment and debate about whether “TDD is dead.” So let’s talk about that, particularly since this particular practice is said to sit at the intersection of testing and development. This is probably going to be a bit of a free-range over a few topics, so bear with me as we brave the dark waters.
Continue reading Test-Driven Is Not (Necessarily) Test-First
Abstraction Levels for Tests
Previously I talked about the testing craft and abstraction and here I’ll expand on those thoughts a bit more.
Bumping the Lamp During Testing
Most testers have heard of “bump the lamp.” It’s hard to go through a testing career and not be exposed to this concept at some point. I recently found an experience where I was able to keep this kind of thinking front and center.
Test Solution Architects
The idea of a test solution architect is a role that should officially exist but doesn’t. My thoughts are still percolating on this but let’s talk about architects in general and then talk about test solution architects.
The Testing Craft and Levels of Abstraction
Previously I had talked about the craft of testing, focusing on the balance between the creativity of an artist and the methodology of a scientist. In both cases, however, the focus is on communication. To that end, it’s imperative we can express what we test in good English. (Or whatever the native language of your environment is.) So let’s talk about this key skill.
Continue reading The Testing Craft and Levels of Abstraction
Lucid Testing and Description Languages
I believe in the concept of what I call Lucid Testing. I even tried to promote my own BDD-style tool solution called — what else? — Lucid. The focus on lucid testing is making testing a design activity. As such an activity, testing makes the business domain — and how that business domain provides value — lucid (expressive and understandable) to anyone who has a vested interest. Core to these ideas is that testing is a design activity and that the primary value of testing is as a communication activity.
Domain Testing and the Limits of Intuition
The technique of domain testing goes under several names, such as equivalence partitioning, boundary analysis, and category partitioning. And probably a few others that I’m either forgetting or never heard of. While this technique is a formal test design method, many testers will tend to do this technique somewhat intuitively. So what I want to do here is show the basis behind this intuition as well as a few simple working examples of how the technique is applied — with an emphasis on how intuition can fail.
Looking For and Valuing the Modern Tester
The test discipline is an interesting spot right now which is where some testers are considered “too technical” and the fear is they don’t want to do the actual testing. On the other hand, some testers aren’t considered “technical enough” and thus the fear is that they put too much emphasis on the actual testing and not on the tooling around the testing. This should be a false dichotomy.
Testers and the Strategy of Trust
Ask a tester this: “You are given a login form. How do you start testing?” For the most part, you’ll find the answer falls along two distinct lines of investigation. You’ll either be told “First, I would try to log in successfully” or you will be told “First, I will try typing in an invalid password, then an invalid username, and then I’ll try entering nothing.”
This is not a question of whether or not the first tester would have also done those tests. They likely would have. It’s rather a question of what they started with: the success scenario or failure scenarios. So let’s talk about that.