A recent discussion came up around a particular type of product model and I wanted to cover that a bit here since I’ve find a certain type of thinker — the literalist — will tend to have problems using imagination and abstraction with these product models. I’ve also found this translates to other models, such as those about testing.
Author: Jeff Nyman
Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words.
If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.
The Testing Pedigree
Testers tend to debate a lot as to whether “everyone” can be a tester. The answer is: yes, if you are human, you are automatically a tester. But not everyone is someone who specializes in testing. I talked a bit about this in being a test specialist and whether or not we should hire test specialists. Here I just want to back up that notion that if you are human you test by looking at the pedigree of the concept.
Testing at the Crime Scene, Part 4
In the previous post we did some deep dives, using all the techniques of this series so far, to try and get a feel for the overall landscape of a code repo to look for clues. Now let’s start to narrow our focus again a bit and then wrap up this series with a few points about the journey we’ve taken.
Testing at the Crime Scene, Part 3
In this third post to the crime scene series, we’re going to continue using our crime scene techniques by adding an extra complexity dimension to what we started in the second post. We’re then going to try our analysis on a much larger code base than any we’ve looked at so far. So put on your detective hat and let’s dive in!
Testing at the Crime Scene, Part 2
Following on from the first post in this series, we’ll leverage the forensic techniques we started with and apply those to a code crime scene in an effort to understand where we might have some quality concerns. And we’ll even try to aid our analysis a bit with some visualizations. So let’s dive in!
Testing at the Crime Scene, Part 1
As human beings working in complex situations, like software, we know that we vary quite a bit in our abilities. That’s the case whether we’re testers or programmers or analysts. Any role that provides cognitive friction around these complex situations will amplify variations in our abilities. That’s why you have certain developers that are better at some things than others; likewise with testers. That variation impacts quality and how we look for it. So let’s dig in to this a bit.
The Ethical Mandate for Mistake Specialists
In my post Forgetting How to Test, I said “we are at a time where forgetting how to test is not just a technical dilemma, but an ethical and moral dilemma.” I still believe that. Here I’ll try to show a bit of how test thinking should lead us inexorably to that idea.
Continue reading The Ethical Mandate for Mistake Specialists
Testing Like It Was 1980
In the past I’ve discussed the idea of being able to recover context by test thinking. Here I want to reframe that idea a bit by recovering the context of what automation was like in the early 1980s. I think it’s important for testers to know their history. So let’s dive back to the 80s where, to quote Back to the Future, “we don’t need roads” — but we did need tests!
An Epic Story About Retro-Gaming
In my previous post on product management, I focused on the overall product context in which a story workflow could occur. I mentioned a follow-on post that would get a little more granular regarding that workflow and this is that post. Here we’ll discuss epics, stories, and tasks and I’ll discuss these concepts in relation to a personal project I’m working on. So let’s dive in!
Product Mapping and Quality Insight
Previously I talked about project management and a quality focus. Here I want to take both down a level to get a little more practical, specifically around the idea of how that quality focus strongly encourages delivery teams to create product maps. It’s those product maps that will give a team the first insights into what quality is going to look like.
Product Management and the Quality Focus
In a series of posts I talked about product development. But now let’s dig in a little to the idea of product management. Although not often framed as such, product management is very much an area of quality assurance. The intersection is crucial in the modern technology industry.
Testing at the Horizons of Quality
The notion of quality can be a complicated concept. Quality can be very situational and that very circumstantial nature of quality tends to happen at the horizon, where various aspects come together and meet. So let’s do a (very) deep dive into this with one of my favorite examples: game testing.
The Shape of Testing
I recently talked about the idea of testing being part geometry and part topology. What might not have been conveyed through that post, however, is how powerful the notion of shape is. What’s particularly interesting about shape is also how we can determine shape by how we choose to observe something. And testing is very much about observing. So let’s dig into this particular rabbit hole.
Testing: Geometry or Topology?
In a previous post (on Test Shapes) I was somewhat practical. Here I’m going for a bit more philosophical, but with the hope that this philosophical bent does showcase an actual distinction regarding how to think about testing as an activity.