I’ve long said that I do believe game testing is one of the best ways that testers can improve their skills. Yet there’s very little out there that’s substantive about game testing, particularly in terms of how testers are asked to think beyond just “test that the game works.” So let’s dig in to this a bit with a two part series that involves something even a lot of game testers seem unaware of, which is the concept of ludonarrative.
Don’t Be A Model Literalist
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.
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.
The Joy of Testing
Awhile back I posted on the idea of wanting to be a tester and, even before that, I posted about why you might stay in testing. So here I’ll somewhat draw those two ideas together.
The Archaeology of Testing
Way back in the Dark Ages of 2011, I talked about finding hidden bugs. A little bit later I talked about how testing is like studying the past. Here I’ll somewhat draw those two ideas together. So as any good archaeologists do, let’s dig in!
Getting Lost in Test
I’ve already talked a bit about how testing is a discipline with a wide-angle lens. This means it’s very possible to get “lost in test.” Getting lost in this context means abandoning that wide-angle lens and abdicating responsibility for testing. So let’s talk about getting lost!
The Theseus of Testing
I was going to frame this post as “The Ontology of Testing” but, while writing it, the Ship ofTheseus, a thought experiment around the metaphysics of identity, seemed apropos. This is particularly the case in an industry where testing, as a discipline, can struggle to find or retain its identity. I was also going to call this post “The Identity of Testing” but the subject was a little more broad than just that. So let’s dig in!
The Basis of Testing
Epistemology is about the way we know things. Ontology is about what things fundamentally are. Ontogeny is about the history of changes that preserve the integrity of something. What does this have to do with testing? Everything. But let’s talk about it.