In this post I’ll continue on directly from part 1 where we ended up with a lot of models and a recognition of competing interpretations of quality along with a need for testability.
Continue reading Testing: From Aristotelian to Galilean, Part 2
Testing: From Aristotelian to Galilean, Part 1
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.”
Continue reading Testing: From Aristotelian to Galilean, Part 1
When Testing Questioned Orthodoxy
When Testing Questioned Philosophy
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.
When Testing Became Scientific
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.
Testers, We Need a Narrative
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.
Ludonarrative Testing, Part 3
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.
Ludonarrative Testing, Part 2
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.
Ludonarrative Testing, Part 1
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.