Any discipline can focus along a spectrum of thinking. That’s no less true of testing, of course. The spectrum I want to introduce from history is that of moving from an Aristotelian to a Galilean way of thinking and “doing science” which, in many ways, is synonymous with “doing testing.”
In the first post in this series, I ended by focusing a bit on Galileo who started to make the idea of testing what it eventually would be recognized as today. That’s the same thing as saying Galileo effectively produced one of the first attempts to make science as it is known today. Let’s continue this path of investigation.
As I’ve been teaching the history of science and religion recently, some interesting ideas have formed in my head around how to present certain topics as they relate to testing. This is crucial since testing is the basis of effective experimentation. So here I’ll talk very briefly about how testing truly became testing.
I was recently re-reading Houston: We Have a Narrative by Randy Olson and I was struck by certain concepts there that reminded me how poorly framed testing often is, particularly by its own practitioners. Clearly an opinionated statement, of course, but I very much believe that many testers in the industry currently lack a narrative or are using a malformed narrative. And this is hurting the industry more broadly as we see quality problems get worse and worse.
In the second post of this series I looked at a couple of games to drill in the idea of ludonarrative and what it means. Here I want to go back to a game I started with in the first post, Elden Ring, and take a much deeper look at the mechanics and the narratives from a ludonarrative testing standpoint.
Continuing on from the first part, I want to continue to give testers a look into a very specific, and often undocumented, form of testing in the context of games, which is the idea of ludonarrative. This has the benefit of also showing how quality can be very much a function of viewpoint.
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.
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.
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.
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.
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!
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!
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.