diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..5ca0973
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,2 @@
+.DS_Store
+
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..e69de29
diff --git a/GROK.md b/GROK.md
new file mode 100644
index 0000000..e69de29
diff --git a/articles/Agile-Or-Whatever-You-Call-It.md b/articles/Agile-Or-Whatever-You-Call-It.md
new file mode 100644
index 0000000..2fee7d8
--- /dev/null
+++ b/articles/Agile-Or-Whatever-You-Call-It.md
@@ -0,0 +1,85 @@
+Over the course of my career on the development side of tech, I’ve worked in a wide variety of different environments, and been a participant in many different kinds of work processes. Some great, some not so great. Some extremely rigid, some extremely fluid. Some entirely paperwork bound, others completely undocumented. But one thing they all had in common, was the wide-eyed insistence that “*We’re an Agile shop!*” The one question that always comes to mind when they tell me this, especially after seeing how they actually work, is: “*but… why?*”
+
+## Where Is The Evidence?
+
+As a tech nerd, I’ve always been partial to very utilitarian answers to my problems. If you give me something that actually solves my problem, I’m satisfied. End of story. More to the point here, I’ve always had a natural suspicion of trends within the tech field that “smell” ideological, and at first the so-called “Agile Methodology” was one of the smelliest of these trends. The fact that it comes complete with it’s own “Manifesto” is certainly not helping its case. If your solution fixes my problem, it doesn’t need a “manifesto”, and if your “manifesto” doesn’t appear to be solving any problems, then it kind of doesn’t matter how pretty it looks on paper.
+
+As a tester, I am partial to empirical methods, and my “facts on the ground” experience of Agile in practice has been very mixed. Some organisations policed themselves excessively, with product owners and scrum masters functioning as ersatz clergy enforcing very meticulous doctrines considered “Agile”, chastising transgressors, and turning the metaphor of the “ceremony” into a barely tolerable literal reality. Other organisations took “Agile” to mean whatever the organisation wanted it to mean, using the label it as a hollow “bat signal” to the kinds of engineering candidates the organisation believed it needed to attract.
+
+Somewhere in between must lie a “golden mean”, as it were. An engineering team that is motivated and disciplined will certainly want to consistently employ practices that are conducive to building better products. But following practices for their own sake, or because they have a trendy label on them, is not actually the point of Agile.
+
+It is true that, for a few organisations, the Agile methodology is obviously not going to work (the military, for example). It’s also true that for certain projects, the iterative Agile approach would be ridiculous (building a bridge, for example). However, it’s also true that, for the vast majority of business ventures (particularly tech-focused businesses), where uncertainty is high, creativity is essential, and the product landscape is constantly changing, the Agile methodology is the single best tool of success.
+
+This is not the mere assertion of an enthusiast. There are hundreds of [examples](https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation "https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation") of [companies](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/a-tale-of-two-agile-paths-how-a-pair-of-operators-set-up-their-organizational-transformations#/ "https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/a-tale-of-two-agile-paths-how-a-pair-of-operators-set-up-their-organizational-transformations#/") over the [last](https://www.fosway.com/innovation-profile-sky/ "https://www.fosway.com/innovation-profile-sky/") twenty five years that [have](https://www.forbes.com/sites/stevedenning/2018/04/06/transforming-hr-as-agile-business-partner-the-case-of-vistaprint/ "https://www.forbes.com/sites/stevedenning/2018/04/06/transforming-hr-as-agile-business-partner-the-case-of-vistaprint/") employed [Agile methodologies](https://www.techwell.com/2012/03/jp-morgan-chase-going-agile "https://www.techwell.com/2012/03/jp-morgan-chase-going-agile") (often coupled with Scrum practices) to improve their businesses and benefit their customers. Some are not even tech-focused. One particular example that might be relevant to us (because of our focus on audits), is [Mission Bell Winery, a California wine manufacturer](https://hyperdriveagile.com/videos/agile-in-wine-how-an-agile-mindset-transforms-traditional-manufacturing-67 "https://hyperdriveagile.com/videos/agile-in-wine-how-an-agile-mindset-transforms-traditional-manufacturing-67") that used Agile and Scrum to attain both [Safe Quality Food Institute certification](https://www.sqfi.com/ "https://www.sqfi.com/") and an ISO 9001 certification. But if anecdotes are not enough, there are [loads](https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071 "https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071") of actual [academic](https://www.sciencedirect.com/science/article/pii/S0164121212000532 "https://www.sciencedirect.com/science/article/pii/S0164121212000532") studies that [argue for it’s value](https://www.forbes.com/sites/tracybrower/2019/10/06/is-agile-really-worth-it-evidence-says-yes-if-you-do-these-4-things/ "https://www.forbes.com/sites/tracybrower/2019/10/06/is-agile-really-worth-it-evidence-says-yes-if-you-do-these-4-things/") as well, or at least [take it seriously](https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071 "https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071").
+
+So, whether we’re talking about hypotheticals, real world case studies, or academic statistical analyses, the evidence is fairly clear: at worst, it suggests potential improvements to a business may be possible; at best, it has the potential to completely transform a business. But what about here at Perspectum? Would it have the same effect on us?
+
+## Which End of Pareto Are We On?
+
+Academic abstracts and hypotheticals aside, the question remains: Is Perspectum a place where Agile would (a) reasonably apply, and (b) add value to the business as an internal practice?
+
+Some have already told me, unequivocally, no, it is not. They cite the regulatory regime within which Perspectum operates, they argue that Agile is too “casual” or “imprecise” to meet the demands of an exacting medical industry clientele, they argue that the academic nature of R&D does not lend itself to Agile processes, and they insist that Agile is just “an engineering thing”, not relevant to the rest of the business.
+
+As simple facts, *some* of these things are true: Perspectum does operate in a highly regulated industry, Perspectum’s customers are very particular in their expectations, and R&D is heavily involved in the execution and publication of academic research studies. But it’s not at all clear to me how these facts are connected to any argument against Agile as a practice. Rather, each appears to be nothing more than an attempt to avoid the potential changes that correctly enacting the methodology would require.
+
+Still, is asking for this change reasonable? Perhaps Agile at Perspectum is just a “solution in search of a problem”, as it were. Even if what we do might be amenable to Agile practices, perhaps the practices we already have, though not perfect, are “good enough” – and even if we work in a field of businesses that are typically structured along Agile lines, maybe doing what everyone else is doing, is not a great plan for us. Perhaps we are indeed among the exceptional 20%, who cannot make good use of Agile practices, for various circumstantial or structural reasons.
+
+## Yes, Agile Applies To Us
+
+I do not think it is the case that we are special, with regard to the particular product development practices we adopt internally. Even the academic R&D is something that could feed into an Agile approach to product development. Indeed, I think we are actually situated as precisely the kind of industry “disrupter” that everyone in tech was fawning over a decade ago, and precisely the kind of organisation that could benefit from a more serious commitment to Agile practices.
+
+Let us address the claim above that Agile practices necessarily encourage sloppy, inexact, or low-quality product development. Near as I can tell from my three months in the company so far, is that this complaint comes directly out of a move toward agility internally that has largely taken place without any vision for what structure would replace the old command-and-control approach – and yet, everyone is still calling whatever this new approach is, an “agile” approach.
+
+While the relaxation of command-and-control structures and the reduction of bureaucratic oversight processes may make the firm more responsive to market demands and more nimble with regard to its competitors, that doesn’t necessarily make it an “agile” business. Those who see rigid structural oversight as synonymous with a high quality product are going to protest at the relaxation, and because the relaxation of these structures is being called “agile”, they will necessarily associate the Agile methodology with a diminishment of the product offering.
+
+The point of Agile is not the avoidance of bureaucratic overhead, the liberation of workers from command-and-control structures, or the avoidance of rigorous quality standards. The point of Agile is *delivering maximum value to customers*, in t*he best possible way*. Depending on the market, that very often requires incredibly exacting quality standards, and very demanding delivery schedules. Neither of which necessarily makes Agile an ill-fitting approach to the business. An excellent example of the fact that Agile does not by itself encourage low quality or inexact standards, is Apple computer.
+
+After Steve Jobs return to Apple in the early 2000’s, the bulk of Apple’s development efforts – from the iMac, to the iPhone, to the MacBook – were guided by Agile practices. At the same time, over that period (particularly during the tenure of Jony Ive), Apple was *infamous* both among its customers and its manufacturing partners, for its extremely demanding quality standards. Apple engineers are some of the most sought after in the tech field, for their capacity for creative collaboration, and for their technical competency and attention to detail. And yet, they worked in an Agile way.
+
+There is no question that what we do at Perspectum is both technically sophisticated and high stakes, and that the nature of the business demands exacting standards for products in which the total landscape of risk includes life and death (at least, indirectly). That is certainly nothing at which to thumb one’s nose. But it is a mistake to think that the only way to insure a quality product is to anticipate every risk, and avoid every error before the product leaves the paper stage. It is to make fear the primary motivation of the company, rather than the desire to do good.
+
+It is true that Agile development, which is an iterative process of self-correction over time, *expects* errors and mistakes to be made as part of the process. It is also true that Agile development discourages attempting to “plan” your way out of those mistakes. Indeed, one of the four primary Agile principles is “*Responding to change **over** following a plan*”. However, this is not a counsel of despair. Agile is not suggesting that you abandon care and do whatever feels good in the moment. Rather, it is suggesting that our impulsive response to risk might not be the best answer to the problem of risk, and that *deliberate adaptation* is preferable. To [paraphrase the stoic Epictetus](https://www.instagram.com/p/BurJYwhgm4t/ "https://www.instagram.com/p/BurJYwhgm4t/"): *“You cannot control what happens, but you can control how you react to what happens.”*
+
+Near as I can tell, there is nothing we do at Perspectum that suggests that this approach to product development is not a possibility for us. We are in the business of providing high quality information to medical practitioners, through the use of computing technologies. Abstracting the specific customers, the same could be said of any number of other businesses in the tech space – from sports betting to space travel. The vast majority of which, employ Agile processes of some sort or another.
+
+Certainly, being in the medical market requires us to comply with various legal and regulatory demands. But this is also true of almost every consumer product manufacturer and food producer, and many kinds of service business. From frisbees to automobiles, taco stands to tax consultants, there are a wide array of legal and regulatory expectations that these businesses must comply with, in order to remain in business. That doesn’t stop many of them from adopting Agile practices – including such top-heavy examples as [JP Morgan Chase](https://www.techwell.com/2012/03/jp-morgan-chase-going-agile "https://www.techwell.com/2012/03/jp-morgan-chase-going-agile"). So, why ***not*** us?
+
+## What Are We Talking About, Exactly?
+
+<img title="" src="file:///Users/gregory.gauthier/Documents/BlogPosts/76bbc630-67bf-4c78-9343-543f6a32786f.png" alt="" width="599" data-align="center">
+
+For all my suspicion of “manifestos”, if we actually inspect [the Agile Manifesto](https://agilemanifesto.org/ "https://agilemanifesto.org/") what we find is not an ideological doctrine, but a list of *pragmatic* value preferences around the way that the authors work on software projects. The primary statement of the four values is also mercifully short. Let’s have a look at them here:
+
+This is an interesting list. Let’s examine it in broad strokes to begin with:
+
+- The first thing we notice (unlike ideological manifestos), is that the language is extremely *terse*, and *very nonspecific*. Which individuals? What processes? What sorts of changes? Who’s plans? This, it turns out, is by design. One of the central features of Agile, is that while the manifesto is meant to express a *value judgment*, it was not meant (also unlike ideological manifestos) to *prescribe solutions*.
+
+- Another thing we notice immediately: the value statements are neither categorical, nor absolute. While there will be more absolute assertions later (in the 12 principles), these initial assertions are *value preferences*, not edicts or rules or even a procedure for choosing between them. What’s more, the authors make this explicit in the final clarification: “*we value the items on the left more than we value the items on the right*”. The language is intentionally “more” and “less”, not “shall” and “shan't”.
+
+- Finally, what stands out, is the de-emphasis of *transactional* ways of working, and the emphasis on *relational* ways of working. The first and third principle speak directly to this. Processes, tools, and contracts, all suggest a highly transactional environment: I advertise a service. You make a request. I agree to satisfy the request in a certain way at a certain time. I employ certain tools and processes to satisfy the request. You receive the output according to the agreed upon conditions. This is the way we engage with vending machines, coffee makers, and ATMs. But the authors of the manifesto are recommending an *interpersonal* approach to software development: “individuals”, “interactions”, “helping people”, and “collaboration” all evoke an image of conversational engagement, rather than service window processing.
+
+## The Underlying Principle
+
+This short list of primary values opens into [a more specific list of 12 “principles”](https://agilemanifesto.org/principles.html "https://agilemanifesto.org/principles.html"), each one providing a more pointed clarification of the value set. The first principle in the list demonstrates this:
+
+<img title="" src="file:///Users/gregory.gauthier/Documents/BlogPosts/faf64c11-e473-487e-8e61-b1b37bf1a0bb.png" alt="" width="491" data-align="center">
+
+Here we have the value of “***working software***”, implemented in the principle of “continuous delivery”, culminating in *customer* *value*. Implicit in this principle, is the value of “***customer collaboration***”. The customer is necessary to determine what “valuable” actually means. However, as put by one Agile author, what the customer wants is not what the customer needs. The customer wants his problem solved. He is best placed to understand what that problem is, but not what the solution to it should be. What the engineer is best placed to understand, is how to solve that problem. This is where the “collaboration” part of the “customer collaboration” comes in. Conversations about wants and needs, priorities and preferences, constraints and possibilities, end in a shared idea of a solution to a problem. That is not one conversation, that is many. And it happens in frequent iterations through the continuous delivery of working software.
+
+In this principle, you can also see the implicit appeal to the value of “***individuals and interactions***”. Developers and customers are motivated by the same desire to solve a problem, and interactions refining that solution will occur organically if the software is delivered frequently. While not entirely eliminated, there will naturally be far less need for fixed schedules of meetings, and far less dependency on the legalese of requirement specifications, in such an environment.
+
+The remaining eleven principles all orbit around the four values, and this initial principle: working software, frequent iterations, frequent collaborations (between business and engineering, as well as between business and customer), self-organisation, simplicity, regular self-correction, technical excellence, good design – all of these are part of the principles, and all of them lead back to one thing: *value to customer*.
+
+Fundamentally, it doesn’t matter how skilled, how fast, or how efficient you are as a team, apart from one additional metric: does it solve your customer’s problem? If you want to solve your customer’s problem, you would certainly be better off with these attributes than without. However, putting them to good use requires *collaboration*.
+
+For example, principle 7 of the manifesto says, “***Working software is the primary measure of progress***”. The question the development team needs to ask itself, is “*what does ‘working’ mean?*” It cannot answer that question in isolation. It can only be answered in the context of the first principle: working software is *valuable* software, and valuable software is software that *solves a problem for a customer*, and we know when that problem is solved, when we have a conversation with the customer over the software we have delivered to him, and he expresses *satisfaction*. Without regular collaboration with the customer, this is not possible. Without regular delivery of software, the collaboration would be pointless. Hence, *working software is the primary measure of progress*, because working software is the manifestation of customer satisfaction.
+
+## The Value For Perspectum
+
+The most interesting feature of the Agile Manifesto (and its accompanying methodologies - e.g. Scrum and Kanban), is that it has demonstrated the utility of its principles not merely in the successfully delivered software products of other organisations, but also in the fact that the Agile organisational approach is itself *an effective solution to organisational problems*. It’s very practice is intentionally introspective and adaptive (something that ideological doctrines *rarely ever* are). It is meant to be structured enough to offer a principled approach to praxis, but fluid enough to enable working relationships of enormous variety and quality, all with the same goal: *delivering value to customers*. Far from being a “solution in search of a problem”, Agile has the potential to be one of an organisation’s most valuable assets.
+
+But can it be so valuable to Perspectum? Very simply put, Perspectum is still primarily a “plan-driven” development organisation. “Plan-driven” is the polite new way to say “Waterfall”. As I’ve mentioned above, this isn’t *necessarily* a “bad” thing. It could be that top-down plan-driven solution development is the best approach for us, given the nature of our customers (largely hospitals, clinics, and commercial Pharma research organisations). But I wonder (aloud now, via this blog post) if that is actually the case.
+
+I have heard Banjo say things in our Update Meetings that heavily suggest he may be sympathetic to the “Agile” approach to what we do. But this is in some sense, paradoxical. One of the principles of Agile is “self-organisation”. Specifically, principle 11: “T***he best architectures, requirements, and designs emerge from self-organising teams.***” If this is true also for the architectures of organisations themselves, then a C-suite imposition is probably a bad idea. In short, having someone like Banjo impose a transformation plan from the top down, is a self-defeating desire in the face of the Agile principle. What’s more, if the outcome of self-organisation is precisely what I see around me now, then perhaps I am still too fresh to realise we’re already optimised.
+
+Call me stubborn, but I remain unconvinced of this.
diff --git a/articles/Testers-As-Explorers.md b/articles/Testers-As-Explorers.md
new file mode 100644
index 0000000..9e86d79
--- /dev/null
+++ b/articles/Testers-As-Explorers.md
@@ -0,0 +1,29 @@
+The testing function in software development has many analogues in “real life”.
+
+Testers are like home inspectors, in one sense. We’ve been tutored on a set of criteria that must be satisfied according to a standard, and taught where to take measurements to test those criteria. We are tasked with entering the home and taking the appropriate measurements, and then reporting when the measurements fail to satisfy the criteria.
+
+In another sense, testers are like scientists. We are handed a world constructed by developers, told what we should expect the world to be like, and then we’re tasked to set up experiments in that world that test those claims by developers, using a method of scientific falsification.
+
+In a third sense, we’re like exemplary software users. Our job is to exercise every feature and facet of the application before us. We function as avatars of various different kinds of users, taking on goals and tasks as if we were users ourselves, and reporting when we fail at those pursuits.
+
+But the analogy that evokes the most mystery (and perhaps the most controversy) is that of the explorer. The tester as explorer is a wilderness expert, a survivalist, a tracker, and a DIY tinkerer. Unlike the scientist, whose experiments are based on carefully constructed interrogations of the environment, the explorer has only a direction of travel in mind. Unlike the software user, that direction of travel need not be pre-determined or identify any particular destination (e.g. ‘let’s go north today', rather than ‘let’s go to the mall today’). Like the inspector, the explorer is definitely looking for things that are odd or out of place, but unlike the inspector, the explorer is not constrained by an authority telling him what to look for.
+
+## The Right Kind Of Explorers
+
+Exploratory testing has often been reputed to be voodoo nonsense or simply an excuse to avoid the rigour of a test plan. Sympathy for this view is understandable, since testing has always been anchored in a concern for meeting requirements, or avoiding defects, or insuring customer satisfaction. This is something done against a standard of measure and the explorer does not appear to have a standard.
+
+But then, how could he? The whole point of exploring an unexplored terrain, is discovery. An explorer would be hard-pressed to explain to his financier, exactly what it is he was going to discover. When Christopher Columbus provided just such an attempted justification to the queen of Spain, it completely skewed his interpretation of what he ended up discovering. Believing he’d landed on an unpopulated shore of the Indies, by way of the Atlantic, he thought he was encountering residents of India.
+
+Still, exploratory testing is not quite that intrepid. As [Elisabeth Hendrickson carefully explains](https://www.amazon.co.uk/Explore-Increase-Confidence-Exploratory-Testing/dp/1937785025/ref=sr_1_4?crid=TBONC795KZNA&dib=eyJ2IjoiMSJ9.-kkYdpj5QRgwnCvkt-s1PvXrl-FC3gB1Wzui-Rzru6jhSod28jH0NBbevoWrP83RVlHcY2JqJ5agQkelngmADvhCHxD3kGow1reK-9nOx8aEsrDl9ei7Gu7y4yoJtTCKsaRGqEZtg8rvm3Yk9fxIufRrF2nPqQC0JjGvJKeLfADDvnWxy_jgZq4081CjuC5ROZuxo8zHLCNT1UXs5BKDZ2eKMkdHEm69qbpCyNZ9ILg.ocOhH0HzTHyXrQdmW2f0Oq-SQHvNStrlup8zQibxHQE&dib_tag=se&keywords=Explore+It%21&qid=1747059922&sprefix=explore+it+%2Caps%2C90&sr=8-4 "https://www.amazon.co.uk/Explore-Increase-Confidence-Exploratory-Testing/dp/1937785025/ref=sr_1_4?crid=TBONC795KZNA&dib=eyJ2IjoiMSJ9.-kkYdpj5QRgwnCvkt-s1PvXrl-FC3gB1Wzui-Rzru6jhSod28jH0NBbevoWrP83RVlHcY2JqJ5agQkelngmADvhCHxD3kGow1reK-9nOx8aEsrDl9ei7Gu7y4yoJtTCKsaRGqEZtg8rvm3Yk9fxIufRrF2nPqQC0JjGvJKeLfADDvnWxy_jgZq4081CjuC5ROZuxo8zHLCNT1UXs5BKDZ2eKMkdHEm69qbpCyNZ9ILg.ocOhH0HzTHyXrQdmW2f0Oq-SQHvNStrlup8zQibxHQE&dib_tag=se&keywords=Explore+It%21&qid=1747059922&sprefix=explore+it+%2Caps%2C90&sr=8-4"), the exploratory tester is not embarking on a purely blind escape into the wilderness, but a *chartered expedition*. It’s the difference between what Columbus did with Spain’s blessing, and what Louis and Clark did, on the instructions of Thomas Jefferson. To be more specific: Columbus imagined a new route to the East Indies, and set sail to prove it real (he didn’t, but arguably, what he did find was better anyway). Whereas, Jefferson told Louis and Clark to get to the west coast, and in the process of getting there, catalogue everything they encountered and make a report when they return.
+
+## The Right Kind Of Exploring
+
+What differentiates the modern test engineer from Louis and Clark, however, is that the charter isn’t spelled out for us by political luminaries like Thomas Jefferson. We have to do quite a lot of *investigative journalism*, before we can begin the expedition: moving with purpose between team members and between teams, and asking lots of questions as we do. That process exposes the unspoken assumptions, the mismatched expectations, and the insecurities of the development process pointing in the direction the expedition will need to head. In other words, exploratory testing begins with exploring what we *think* we’re building*,* and only then proceeds to explore what we actually built.
+
+The charter is, therefore, something drawn in silhouette around the “requirements”. It is the shadow cast by *expectations and intentions*, and when that shadow does not fall on the ground where the requirements claim it should, then we have our falsification.
+
+To clear away all the metaphorical language, this is essentially the work of the exploratory tester: to triangulate the truth about the software, from expectations, requirements, and the material reality, as his data points. That truth may be that “the requirements are not met”, but it also may be that “the requirements are insufficient”, or that “the expectations are incongruent with the requirements”, or “the product owner didn’t understand the customer”, or “the api doesn’t accommodate enough volume”, or “there’s a typo in the client class”, or any number of other possibilities in the open landscape of a software development project. This makes him not just an explorer, but (at least in certain respects) an investigative journalist, a scientist, and an engineer, at any given moment.
+
+## It’s Not As Glamorous As It Sounds
+
+Before I puff myself up too much, I should point out that investigative journalists are not very well liked by the people they’re investigating. Also, *actual* explorers are much more likely to be eaten by bears and tigers, than I am. Exploratory testing may not involve grinding through rigorously crafted procedural scripts, or filling out extensive reports for management, but it nonetheless requires discipline to execute well, and that means attentively engaging in the good habits of both engineering and testing, on a regular basis. Exploratory testing is just one more useful means to the same end we all have in software development: a quality product.
diff --git a/articles/The-Various-Uses-Of-Vegetable-Condiments-In-Testing.md b/articles/The-Various-Uses-Of-Vegetable-Condiments-In-Testing.md
new file mode 100644
index 0000000..9827cd4
--- /dev/null
+++ b/articles/The-Various-Uses-Of-Vegetable-Condiments-In-Testing.md
@@ -0,0 +1,137 @@
+In my time as a software tester and automation engineer, I’ve seen all manner of tragic misuses of engineering methodologies and their associated toolsets. Agile itself is one I mentioned in my previous post. Second on that list is easily the Cucumber (aka ‘Gherkin’) toolset.
+
+I’ve seen it used as a unit testing framework in lieu of the supplied library of the target language, as plain text documentation for a user application, as an API client for a backend application, and as a management report generator for engineering managers. As bad as all those things might sound, the worst misuse of the tool, I think, is it’s employment as a plain-english procedural DSL for end-to-end tests. Nothing raises my hackles more, than to see long strings of “and then when” chained together in a meandering play-by-play narrative of a tester’s stream of consciousness. That’s not what Cucumber is *for*.
+
+Let’s answer the obvious question that arises from my last complaint: What, exactly, *is* Cucumber for? If you read the [original creator’s blog post about BDD from September of 2006](https://dannorth.net/introducing-bdd/ "https://dannorth.net/introducing-bdd/"), a few things pop out. First, it was a *response to* several problems Dan North saw in the attempt to implement TDD in the early days. Second, *testing problems* weren’t ultimately the problems he was trying to solve. In other words, the problems he encountered with TDD stemmed from a more fundamental problem with the way software was being *designed and built*. The problem with TDD was was that it was downstream from where the real problem lie. In short: it was *still* just one more attempt to mitigate problems with overall software quality by tinkering with the way tests were written.
+
+What he invented to deal with the deeper problem was something he coined as *Behaviour Driven Development*. It is meant to complement the Agile story pattern, by providing a way to *describe* the *behaviour* of an application when a user engages in a discrete interaction with the application. It is fundamentally, a *design* methodology, not a testing tool. To implement the methodology, Dan North constructed a language that could be used to *describe a behavioural design specification*. That language is “Gherkin”, and the libraries that interpret it, are known as “Cucumber”.
+
+Cucumber, therefore, is *for* improving the quality of your software product by focusing on the way you *design the behaviour its human-facing interfaces*. It is not a testing tool, it is a *design tool* that just happens to include the ability to *execute the design requirements*. That design tool is meant to facilitate the [*Behaviour Driven Development* methodology](https://cucumber.io/docs/bdd/ "https://cucumber.io/docs/bdd/"). However, as the Cucumber site itself rightly points out, you may still get some value out of Cucumber as a testing tool, without necessarily *doing BDD*:
+
+> *Just because you're using Cucumber, doesn't mean you're doing BDD.* [*There's much more to BDD than using Cucumber*](https://cucumber.io/docs/bdd "https://cucumber.io/docs/bdd")*.*
+
+But I think it’s also the case that getting value out of Cucumber as a testing tool requires understanding how it’s meant to be used in the BDD methodology. In fact, I’d go so far to say that if you don’t understand, then you’re actually going to *make your situation worse*, by using the tool. So, if you want to use it, here’s where to begin:
+
+## What Is A Behaviour?
+
+What does it mean to design an application by describing it’s behaviour? Applications do not “behave” in the sense that a living thing behaves. Living things are self-motivated. They will act spontaneously, even when driven by biological urges. Nothing necessarily must *happen to them*, for them to decide to move this way or that, go to sleep or wake up, scratch your couch up, or chew your slippers.
+
+Software applications, on the other hand, don’t do any of this. They will sit idly, until the battery on your laptop dies, quietly waiting for you *to do something to them*. If the action you take is something the software is designed to notice, it will offer up the defined response to your action. In a word, a **behaviour** is a discrete, single *cause-and-effect* event.
+
+For example, if you have a fallow balloon, when you blow air into a balloon, the balloon expands. Notice the elements of that example: (a) a balloon that is in a certain condition, (b) a *catalysing event*, and (c) a balloon in a new condition after the event. Behaviour then, in the context of BDD, is the description of a cause-and-effect relationship between a Software application and a user, at the point of an interaction.
+
+Another way to put this, is to call it a described “[state transition](https://www.sciencedirect.com/topics/computer-science/state-transition "https://www.sciencedirect.com/topics/computer-science/state-transition")”. In fact, [Bob Martin has famously explained](https://blog.cleancoder.com/uncle-bob/2018/06/06/PickledState.html "https://blog.cleancoder.com/uncle-bob/2018/06/06/PickledState.html") how Cucumber is not a plain-English *procedural* *DSL*, but a plain-English [*finite state machine*](https://brilliant.org/wiki/finite-state-machines/ "https://brilliant.org/wiki/finite-state-machines/") specification:
+
+> *If the Gherkin requirements are complete, then they describe the complete state machine of the system, and the complete test suite for the system.*
+
+And what does that look like, to Uncle Bob? Like this:
+
+> `GIVEN that we are in state S1 WHEN we recieve event E1 THEN we transition to state S2`
+
+## How Do I Get To The Museum?
+
+Anyone who has worked in test automation over the last 15 years will instantly recognise the familiar “Given, When, Then” keywords in that transition example. What they won’t recognise, is the disciplined approach to the use of those terms. What Martin outlines in his example is a *discrete transition event*. A system in state S1. A catalysing event E1. A system in state S2. That is not at all typical of the way Cucumber (aka “Gherkin”) has actually been deployed in the field. The broader reasons for this will be examined later, but the immediate reason is because everyone who approaches this tool, approaches it the same way they approach singing.
+
+When someone asks you “*do you know how to sing?*” or “*can you sing row, row, row your boat?*”, you will answer yes. You will do this because *as everybody knows*, if called to do so, it’s just a matter of opening your mouth and blowing some air past your vocal chords. But, as we all **also** know, not everyone who “can sing”, gets a position at [La Scala](https://www.teatroallascala.org/en/index.html "https://www.teatroallascala.org/en/index.html").
+
+Similarly, you would have no problem telling me what the words “given”, “when”, and “then” mean. They are simple, very common words in the English language, and they are used all the time to speak about things that come one after the other. So, of course, you will tell me you know how to use them in a Cucumber scenario. *Doesn’t everyone*?
+
+The following screenshot is typical in the testing field, I have found, of what those sorts of assumptions produce:
+
+<img title="" src="file:///Users/gregory.gauthier/Documents/BlogPosts/29c72b97-5bd3-4b15-bc41-037c6f10a944.png" alt="" width="859" data-align="center">
+
+This is obviously not a description of a discrete state transition. What the author of this scenario has done, is to describe his personal journey through the application to some terminal end point. In effect, the author has given you a ***procedure*** for how to get to the museum: “*Head straight down Main, turn left at the Tesco, watch out for the big sign on your left, keep left, then head south to the round-about and take the third exit, and then just before the gas station make a hard-right then go up the ramp….*”, and so on.
+
+Sure, you might say, but is this really a problem? After all, it describes a complete user journey, and user journeys are the ultimate test of the usability of the application.
+
+This argument fundamentally misunderstands the nature of the tool. It is excusable, because (as I’ve already outlined), the interface is plain English, and we are already predisposed to think in linear terms because that’s how we live our lives: “…*and then I took a shower, and then I brushed my teeth, and then I got dressed*…”. It is true that there are (and should be) procedures involved in the implementation of the *executable instance* of a proper Gherkin spec. But those procedures are to be found in the so-called “glue” underlying the Gherkin. In other words, in the programming language bound to your Gherkin specs through your Cucumber library (whether Java, or Python, or Ruby, or whatever).
+
+## The Cost Of Discipline
+
+There is another reason why not knowing how to use Gherkin well is somewhat excusable. The notion of a finite state machine is a concept that comes to us from academic mathematics and computer science. Many of my colleagues over the years, while competent in their own right, were not academically trained computer scientists (indeed, neither am I). If you look the concept up on the internet, the explanations you’ll find will not look even remotely similar to what is found in the Gherkin syntax. So, really, Kudos to Bob Martin for recognising it back in 2018.
+
+Once recognised, though, we would do well to apply the concept carefully and consistently to Cucumber. This dispute is more than just an abstract debate about the placement of BDD in an academic theory of engineering practices. As any trades contractor can tell you, the misuse of tools can be incredibly costly (sometimes even deadly). And there are many reasons to think this of Cucumber.
+
+For starters, linear stream-of-consciousness instruction lists shown in the screenshot above make it next to impossible to *normalise your underlying code.* Every new scenario “journey” is a whole new lexicon of words and phrases that need to be married to some executable script beneath the Gherkin. Whereas, with a well crafted state-machine approach to scenarios, the potential for *reusable code* increases dramatically. Consider the following example:
+
+```
+Scenario: The User Views His Profile 
+  Given I launch the application 
+   When I enter my userid 
+    And I enter my password 
+    And I click login 
+    When the application loads 
+    And I click on my profile icon 
+    Then the application show me my profile 
+    And I can see my details 
+
+Scenario: The User Updates His Profile 
+  Given the application is already running 
+    And I have successfully logged in 
+   When I can see the dashboard 
+   Then I can click on my profile icon 
+    And I can see my details 
+   Then I edit my display name 
+    And I click save
+```
+
+This example is a typical representation of what can be found in the field. Note immediately, two things: First, the “view” scenario has more steps than the “edit” scenario. Second, the application launch and login processes are rendered in completely different language here. Third, there are further subtle differences in the “click on my profile” steps in each. As well as other minor differences.
+
+Each one of these differences is going to have underlying knock-on effects. Each line of the scenario is a “hook” to a piece of code that executes in the background. But because the language is so different between the scenarios, each one will need it’s own unit of code to execute what is essentially the same function. If your testers are writing their own execution code, then this will cause them to spend more time writing code, than testing. If your developers are writing the execution code, then you’re robbing them of an opportunity to optimise the test suite.
+
+Compare the above to this:
+
+```
+Background: Prepare the application 
+  Given The application is running 
+    And A standard user is logged in 
+
+Scenario: The user views his profile 
+  Given I am at the dashboard 
+   When I navigate to my profile page 
+   Then I can see my user details 
+
+Scenario: The user edits his profile display name 
+  Given I am at the dashboard 
+   When I navigate to my profile page 
+    And I change my display name to "Yosemite Sam" 
+   Then I can see "Yosemite Sam" on my profile page
+```
+
+In this example, the scenarios are supported by a background stage that rolls the login into a single block. The background clause won’t be ideal in all cases, but for many scenarios, this is a good technique for eliminating repetition in your Gherkin, making it much easier to maintain. What’s more, the reduction in repetition means reducing the likelihood of dialectic proliferations of the same functionality (“the application is running”, “the application is loaded”, “the application has started”, etc).
+
+In addition to the background stage, notice also that each step in the scenarios is worded identically: “I am at the dashboard”, “I navigate to my profile page”, and so forth. These usages insure that there need be *only one* piece of glue code for each of these steps, in any scenario where they are used – further reducing the maintenance issues.
+
+Finally, and most importantly, notice that the scenarios are *structured state transitions*. There is a well-defined starting condition, a discrete set of catalysing events, and a clearly defined *expected end state*. Regardless of **how** the glue code makes each of these steps happen, these test scenarios make it extremely clear what our expectations are for each starting condition couple to each catalysing event.
+
+One implicit lesson we can take from this, is that *a scenario is not a user journey*. A scenario is a segment of a user journey that we believe to be important enough to test. It is a state transition from one set of assumed conditions up to the point in the user journey where we are, to another set of outcome conditions expected after a user interaction: “I navigate to my profile page”, or “I change my display name to ‘something’”.
+
+This is just one instance of how Gherkin scenarios like these could be improved. Much more could be said (for example, who am “I”, in these scenarios?). However, there’s simply not enough room to go on. One could write an *entire book* on Cucumber best practices like this (and it shocks me that nobody has yet). But, suffice to say here, the tighter and more terse your Gherkin, the better your behavioural specification will be – and, the less likely you are to throw the entire effort out as a complete waste of company resources (something I have seen happen numerous times).
+
+## All The Wrong Reasons
+
+One of the side-effects of the proliferation of Cucumber without the BDD methodology, is that other purposes for Cucumber began to proliferate as well. I mentioned some of them at the beginning. But there is one purpose that has turned Cucumber into a weapon opposed to its own creator’s original end goal.
+
+In many shops, Cucumber was promoted by siloed test managers who had convinced themselves that Cucumber was a means by which they could get automated tests without needing code competent testers.
+
+In such shops, testers wrote all the scenarios without understanding how the code that executed them worked, and entry level developers wrote all the glue and harness code, without understanding what the cucumber scenarios were actually *for*. In every case in my experience, this has resulted in behemoth testing projects that have little or nothing at all to do with the applications under test. The daily goal of testers is to constantly nag junior developers about testing dashboards that have turned red for one reason or another. Entire internal organisations devoted to nothing but making the machine that turns green, stay green. Ultimately, costing the institution orders of magnitude more money than if they’d just had a few small cross-discipline teams working on the application together, without any automation.
+
+## Conclusion: A Solution In Search of A Problem
+
+To re-quote the Cucumber site:
+
+> *Many people use Cucumber to do test automation, to check for bugs after the code has already been implemented. That's a perfectly reasonable way to do test automation, but it's not BDD.*
+
+I would take this a step further. If you’re not “doing BDD”, I would highly recommend you *not* to use Cucumber or the Gherkin language. Contra the Cucumber assertion, the experience in the field, is that writing Gherkin after-the-fact has been a near disaster, relative to the goals that methodologies like Agile and BDD set out.
+
+Adding the additional layer of a plain-language DSL, even just as (perhaps especially as) a test automation tool opens up a near impossible to resist landscape of temptations to bad design and development habits and even worse organisational choices.
+
+If your shop is not working well, exploring new processes and methodologies can be an opportunity for significant improvement. In such a situation, BDD might just be the cure you’re looking for. If it is, then a disciplined approach to your Gherkin specifications will also naturally follow as part of the BDD process.
+
+But if your shop *is* working well, then introducing disruptive new practices can completely derail your team. The half-way step of adopting the tools of that methodology without the methodology itself, may seem like a “perfectly reasonable way to do test automation” for some. But from my experience, has been nearly as chaotic as introducing the entire methodology to an already mature and stable shop.
+
+If you have competent developers, they will know how to write tests. If you have a healthy, functional development process, then those tests will naturally align with design and requirement goals.
+
+If you have competent test engineers, they will know how to properly test your applications, and if you have a healthy functional development process, those testers will contribute to design and requirements early on, to insure testability.
+
+If you find that neither of these things is true, then Cucumber on its own is probably not going to help you.
diff --git a/articles/five-essential-lessons.md b/articles/five-essential-lessons.md
new file mode 100644
index 0000000..d4c7dc4
--- /dev/null
+++ b/articles/five-essential-lessons.md
@@ -0,0 +1,51 @@
+Relative to software programming, design, marketing and management, there are comparatively far fewer good books written on the topic of testing and test engineering. In most instances, it is treated as a hygiene component of software development in a few chapters on test construction, or it is described as part of a process management philosophy like Domain Driven Design, or Test Driven Development. However, in spite of what these books would suggest, software testing is in fact, a technical discipline of its own, distinct from all the other roles mentioned here, including software development, and there have been a few well-written books on the topic.
+
+One of the best books an aspiring software tester can read to improve his practice, is the Kaner, Bach, and Pettichord book “[Lessons Learned In Software Testing](https://www.amazon.co.uk/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124 "https://www.amazon.co.uk/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124")”. This book is a comprehensive bible of 293 battle-tested insights into software testing, accumulated over decades, and drawn from direct experiences as well as academic study. It does much more than just train you to pass a certification test. It is a practical guide to testing as a distinct practice in a way that no certification process could ever hope to be.
+
+There’s no room in a blog post to cover all 293 lessons. However, what I will do here is [borrow a technique from Mortimer Adler](https://www.amazon.co.uk/Six-Great-Ideas-Mortimer-Adler/dp/068482681X "https://www.amazon.co.uk/Six-Great-Ideas-Mortimer-Adler/dp/068482681X"), and try to distill the book down to the most important lessons that I think every tester really needs to know, if he wants to be a good tester. These “lessons” aren’t one-for-one duplications of lessons from the book, but rather distillations of several, or augmentations of them, to include details I think are missing or obscure. They’re also not the *only* important lessons. Mostly, they’re just meant to inspire you to go read the original book.
+
+## Lesson 1: Testing And “Quality Assurance” Are Different Things
+
+ There is a long standing practice in software development to call the tester the “QA”, but “assuring quality” is not what a tester does. His testing may *contribute* to the quality of the product, but the tester is first and foremost a *fact-finder*, *not an auditor or a gatekeeper* (this point will become more apparent, and more important as we proceed).
+
+As noted in lesson 11 in the book: “…*test results and bug reports provide information that facilitates the assurance of quality on the project, but that assurance results from the effort of the entire team*…”. In other words, product design, product development, and product testing, are all necessary components insuring the quality of the delivered product.
+
+The tester’s role is to provide the information that tells the team whether or not what they say to themselves about the product, is true. When they discover it is not, then the team can have a conversation about what ought to be done about it. Sometimes, this will lead to immediate changes to the product code. Sometimes, nothing more than revising understanding or expectations is enough.
+
+## Lesson 2: Testing Is An Empirical Discipline
+
+As I’ve floridly described [in a previous post](https://perspectum.atlassian.net/wiki/spaces/~712020d73d7fb444534bfbb08564f3576e2046/blog/2025/05/12/3545038875 "https://perspectum.atlassian.net/wiki/spaces/~712020d73d7fb444534bfbb08564f3576e2046/blog/2025/05/12/3545038875"), testing is a practice that is focused heavily on comparing what we think the world is like, to what we actually find when we investigate it. This is similar to the way a scientist works, in one very important way: ***it begins with questioning***. Every good tester will learn to question everything (though, as lesson 7 advices, not always out loud). Among the questions a tester should be asking (of both his team and himself), the first and most common will be, “*how do you know?*”.
+
+The $20 word encapsulating this particular question is “*epistemology*”, which in philosophical circles, just means the method by which one justifies one’s beliefs. Lesson 16 calls testing “*applied epistemology*”. What is meant by this, is that testers take the philosophical study of knowledge (in particular, empirical knowledge), the the scientific study of cognitive psychology, and the discipline of critical thinking, as tools that not just enable the practice of software testing, but enable its *excellence*. As the authors put it in lesson 17: “*Lots of people who never studied these subjects have done good testing. But if you want to be **better** than good, learn this stuff.*”
+
+## Lesson 3: Testing Is An Evaluative Discipline
+
+Lesson 24 makes the simile to scientific practice explicit: “*All tests are experiments performed to answer a question about the relationship between what a product is and what it should be.*” However, that assertion should make something else very clear. Testing is not just discovery, but *evaluation*.
+
+The right half of the relationship in that statement is answered by ongoing conversations between the members of the development team and their customers (product teams, clients, etc). The left half is discovered by the tester. In the gap between what the product *is*, and what it *should be*, lies a *normative judgment* about it. There is, in fact, a *right way* and a *wrong way* to be the software. The degree to which the relationship is consonant, is the degree to which either the product is good for the purpose that has been set out, or the purpose itself is achievable.
+
+For a software product, *purpose* is the value it provides to the customer. That value is constituted in whatever problem it was built to solve. The degree to which it solves that problem is the measure of its quality. The higher the quality, the tighter the relationship between what the product is, and what the product should be. Or, to put it much more succinctly, we can quote lesson 62: “*Quality is value to some person*”. Testing is the practice that tells us whether the product is achieving its purpose.
+
+## Lesson 4: Typically, Automated Testing Isn’t
+
+Reiterating an important point from my first section, “Lessons Learned” asks this question in Chapter 5: “*The role of testing is to gain information. What information is your automation providing?*” This question is difficult to answer for most, because test automation wasn’t implemented to provide information. It was implemented as a cost-cutting measure. Often on the misbegotten view that testing is a low-yield activity in the development process, that is generally not worth its cost. This, in turn, is typically because those shops don’t know why they’re testing.
+
+Chapter 5 goes on to answer its own question: “*Use automation when it advances the mission of testing.*” What is the mission of testing? To gather and disseminate information that is necessary for judging the quality of the product. Or, to put it more succinctly, as I like to say, “*automation is a tool, not a goal.*” If the tool is not getting you to your goal, stop using it. Lesson 106 reinforces this view: “*A test tool won’t teach your testers how to test. If your testing is confused, test tools will reinforce the confusion. Fix your testing processes before automating them.*”
+
+To be fair, good unit tests very often do help to get a project to its goal. However, there are many forms of so-called automated testing that do not. Chapter five’s introduction suggests that one way to avoid the mistake of “automation first”, is to first figure out what you want to test: “*Design your tests first, before deciding which to automate. This prevents you from falling into the trap of automating tests that are easy to automate, but weak at finding defects.*”
+
+What’s interesting is that most of the Lessons in this section of the book are suggesting uses of automation that aren’t actually testing functions. They’re about acceleration, extension, scale, and volume. They’re about ways to use automation to *automate* what at tester does, not to actually *test*. To put it another way, automation is about cybernetically extending a human tester. If you have an application for that kind of extension that works, it can be enormously valuable. However, ultimately, Lesson 106 has the last word: *“If you buy [a test tool instead of hiring a tester] you may get rid of your testers only to end up with a bunch of busy tool users, a lot of activity, and little or no bug finding. Where’s the value in that?*”
+
+## Lesson 5: Testers And Programmers Are Not Adversaries
+
+One of the oldest myths in software development, is the depiction of the cackling tester who makes it his life’s mission to make the programmer cry. It even has its own [famous Tik-Tok meme](https://www.tiktok.com/@thetestersfamily/video/7195725882575637803 "https://www.tiktok.com/@thetestersfamily/video/7195725882575637803") now. As funny as this is, it’s completely the wrong way to think about the relationship between the programmer and the tester.
+
+Ultimately, programmer and tester are both there to produce a quality software product. Their roles are not *adversarial*, they are *complementary*. To foster this complementarity, mutual respect is necessary. Mutual respect elevates the quality of the relationship between developer and tester, and in so doing, will necessarily elevate the quality of the product.
+
+Lesson 6 counsels the tester to “*run with the programmers*”, and Lesson 150 urges tester to “*understand how programmers think.*” It even goes so far as to say “*The best way for you to learn how to interact with programmers, is to become one and to work with other programmers as your peers for a while. Come back to testing after you’ve written production code, had it criticised, condemned, and praised by testers, users, managers, and fellow programmers.*” While I don’t go quite that far, the implication is clear: nothing is more effective at fostering a sense of shared mission, than walking a mile in your colleagues shoes.
+
+But there is a deeper point to be made here, as well. Namely, found in lesson 39: “*You can’t avoid bias, but you can manage it*”. One of the insights I’ve gained in my years as a tester, is that you can leverage complementary biases, for the sake of quality. Lesson 39 goes on to list a number of common cognitive biases: Assimilation, Confirmation, Primacy, Representativeness, and so on. The lesson focuses on the testers own awareness of these biases, and treats them as potential hazards. But this is, I think, a mistake. Since programmers and testers are *both* susceptible to the same biases, but are susceptible to them under different conditions and motivations (see lesson 150), the biases marry up, in the interaction between software and tester.
+
+The best example of this, can be found in confirmation bias. Programmer is eager to see his functionality work. He iterates over his code numerous times until he gets an outcome he is hoping for. Shazam! Success! Commit. Push. The tester, equipped with not just the requirements, but the boundaries and corners of those requirements, iterates over the functionality, until he gets an outcome he is hoping for. Shazam! Bug! Cut. Publish.
+
+You can see this process actually playing out in the Tik-Tok meme. This process repeats as often as necessary, until you get to a point where it’s more costly to keep iterating, than to deploy. In other words, until you’ve reached a point of practical quality. On this model, therefore, the developer should actually be gratified to see test reports with bugs in them. It means there is still an opportunity available for further improving the quality of the product. A goal you both seek.
diff --git a/articles/perfection-and-testing.md b/articles/perfection-and-testing.md
new file mode 100644
index 0000000..2bd6187
--- /dev/null
+++ b/articles/perfection-and-testing.md
@@ -0,0 +1,23 @@
+> ...*this book is not for people who think that they can write a perfect program and be perfectly sure that it is perfect... you must also believe that human thinking can be perfect…. Humans are not perfect thinkers... If your thinking were perfect, you would not need testing. If you believe that you must always be perfect, then you would find the existence of testing or testers rather upsetting, because it would imply that your thinking cannot be perfect. But if you say, 'Well, before I invested my life savings, I might want to do a little testing,' then you won't always be upset by the very idea of testing*... ~Gerald Weinberg, ["Perfect Software And Other Illusions"](https://www.amazon.com/Perfect-Software-Other-Illusions-Testing-ebook/dp/B004J4VVE2 "https://www.amazon.com/Perfect-Software-Other-Illusions-Testing-ebook/dp/B004J4VVE2")
+
+
+
+## Don't Be Like Goofus
+
+In the 1960s and 1970s, an American magazine called "[Children's Digest](https://en.wikipedia.org/wiki/Children's_Digest "https://en.wikipedia.org/wiki/Children's_Digest")" ran a series of cartoon illustrations called "Goofus and Gallant". They were two-panel allegories comparing a pair of twin brothers. Gallant always did the right thing; Goofus always did the wrong thing. The purpose of the cartoons was to gently scold the young reader into adopting the “polite” behaviour: "*You don't want to be like Goofus, now, do you? You'd much rather be like Gallant, right?*"
+
+<img src="file:///Users/gregory.gauthier/Documents/BlogPosts/assets/8bde58f1-2111-47ad-89b1-0ccad9d7e3a3.jpeg" title="" alt="" data-align="center">
+
+This is essentially what Mr. Weinberg is doing with the quoted argument: "*You don't want to be like Goofus, who thinks he's **perfect**, now, do you?*" Not only is this argument embarrassingly fallacious, it's deeply insulting. It is perhaps the worst possible way to convince a product manager of the value of software testing. Framing the question of testing as a juvenile moral imperative is almost assuredly going to alienate your colleagues and your customers.
+
+## The Perfect Is The Enemy Of The Good
+
+I've been in tech for 37 years. In all that time, I have yet to encounter anyone who believes there is any such thing as "perfect" -- whether we're talking about hardware, or software, or thinking, or finances, or anything else. What I *have* encountered, are lots of people who are over-confident, or not confident enough, or who have misjudged the risks involved in their choices (one way or another), or who have made faulty predictions about either the demand or the value of what they were building, or who have misjudged their own capacities.
+
+None of this has anything to do with perfection, or anyone's belief that they are. What it *does* have to do with, is the mismatch between their assertions *about* reality, and what *actual* reality will yield up for them. And *that* is what testing is for. It is a tool for exposing the gap between our expectations, and the reality about which we have expectations.
+
+The best testers are able to make that gap visible to a software development team, and help them to avoid falling into it. They can show how the ability to narrow that gap means the ability to reduce the risk of embarking on a software development project, and taking on the burden of its costs; and how it means the ability to better predict outcomes, meet market needs, and ultimately, increase profits. In short: testing is how an organisation enables itself to be better than it was yesterday. What testing is not, is a means by which that organisation can apologise for not being perfect.
+
+The choice of whether or not to test is not a simple binary moral choice between being Goofus or being Gallant. It is a judgment about confidence levels, competence, market demands, functional context, and customer needs. The former, in fact, is a psychological trap. It's the reason why many companies fall down ridiculously expensive and protracted rabbit holes of endless testing and "quality gating". They're terrified of looking like Goofus to themselves, or one of their clients.
+
+The mature organisation, however, understands that testing is just a tool. And tools are meant to be used at the right times, for the right reasons. Some things get tested rigorously, some things get tested lightly, yet other things get ignored. A seasoned software development team will be able to tell you which is which, almost intuitively. And where that intuition is missing, a good leader can fill in the gaps.
diff --git a/articles/resources-for-testers.md b/articles/resources-for-testers.md
new file mode 100644
index 0000000..ed61ca4
--- /dev/null
+++ b/articles/resources-for-testers.md
@@ -0,0 +1,58 @@
+For anyone already pursuing a career as a software tester, some of these resources will be familiar. For those new to the field, or interested in understanding what it is that a tester does, these lists may help you.
+
+## Books
+
+“*Book Learnin’ tm*“ is not really how I got started in tech. But books are still a fantastic tool for gaining knowledge not available from narrow experience, and a good tool for helping to organise our thinking about testing, and encouraging discipline in the practice of testing. Along those lines, here are five must-reads:
+
+- [**Lessons Learned In Software Testing**](https://www.amazon.co.uk/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124/ref=sr_1_4?crid=3VKPR7QYJGBUQ&dib=eyJ2IjoiMSJ9.yfGfVcQKbBV432wutjzNHS9Q11eSSX54XVUbsepRDxwv6KrXywIkUsp8VqrgcAH2LN-1cULpBcyg0bW4U4yCuYLbdl_TlKnrOMYHQTmjsSzO0JOcPN1QhlGd3HGHBEE66jKG3MbCARwjsAaoy0QxlCIibyL9NSM6cq7pQVwfgGfGTk7_S_96ZfPFaE3xWb0aPw6HrBxuqkbGYHAWi3NDdZj9UV7UYB0GFYj0rwq0INE.cE9FVg94DlmoUb-2bobcEJfWd_0ywIG8llvxKi8du34&dib_tag=se&keywords=james+bach&qid=1765802766&sprefix=james+bach%2Caps%2C88&sr=8-4&ufe=app_do%3Aamzn1.fos.95fd378e-6299-4723-b1f1-3952ffba15af "https://www.amazon.co.uk/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124/ref=sr_1_4?crid=3VKPR7QYJGBUQ&dib=eyJ2IjoiMSJ9.yfGfVcQKbBV432wutjzNHS9Q11eSSX54XVUbsepRDxwv6KrXywIkUsp8VqrgcAH2LN-1cULpBcyg0bW4U4yCuYLbdl_TlKnrOMYHQTmjsSzO0JOcPN1QhlGd3HGHBEE66jKG3MbCARwjsAaoy0QxlCIibyL9NSM6cq7pQVwfgGfGTk7_S_96ZfPFaE3xWb0aPw6HrBxuqkbGYHAWi3NDdZj9UV7UYB0GFYj0rwq0INE.cE9FVg94DlmoUb-2bobcEJfWd_0ywIG8llvxKi8du34&dib_tag=se&keywords=james+bach&qid=1765802766&sprefix=james+bach%2Caps%2C88&sr=8-4&ufe=app_do%3Aamzn1.fos.95fd378e-6299-4723-b1f1-3952ffba15af"), James Bach - A classic volume of great advice for any tester, whether seasoned or new to the role. There are “lessons” in this book that I still apply, even after almost 20 years in software development and testing.
+
+- [**Explore It!**](https://www.amazon.co.uk/Explore-Increase-Confidence-Exploratory-Testing/dp/1937785025/ref=sr_1_1?crid=11E6XD2PQWYBL&dib=eyJ2IjoiMSJ9.v7WDX8rkm5L7zPPo7FziVy2Dg9b5udSXaGxWha7jxQ21PU6DO3tR0dwNTCFS6Wk1.c8TyzKOSRyrr7hWoBZj7QsX5eVV-6qVNLjDMbsoNqBc&dib_tag=se&keywords=Elisabeth+Hendrickson&qid=1765803647&s=books&sprefix=elisabeth+hendrickson%2Cstripbooks%2C82&sr=1-1 "https://www.amazon.co.uk/Explore-Increase-Confidence-Exploratory-Testing/dp/1937785025/ref=sr_1_1?crid=11E6XD2PQWYBL&dib=eyJ2IjoiMSJ9.v7WDX8rkm5L7zPPo7FziVy2Dg9b5udSXaGxWha7jxQ21PU6DO3tR0dwNTCFS6Wk1.c8TyzKOSRyrr7hWoBZj7QsX5eVV-6qVNLjDMbsoNqBc&dib_tag=se&keywords=Elisabeth+Hendrickson&qid=1765803647&s=books&sprefix=elisabeth+hendrickson%2Cstripbooks%2C82&sr=1-1"), Elisabeth Hendrickson - The essential How-To guide for exploratory testers in an Agile environment. It offers several useful techniques, like charters and diaries, for structuring exploratory testing sessions. A definitive must-read.
+
+- [**Agile Testing Condensed**](https://www.amazon.co.uk/Agile-Testing-Condensed-Brief-Introduction/dp/199922051X/ref=pd_bxgy_d_sccl_1/525-5077970-5211661?pd_rd_w=G9vUs&content-id=amzn1.sym.ec630614-3f9e-4b7f-ba9a-fe89f8e4113f&pf_rd_p=ec630614-3f9e-4b7f-ba9a-fe89f8e4113f&pf_rd_r=XNV4CN7CHKJ9QB8J5YD4&pd_rd_wg=LUXYU&pd_rd_r=fc92e5eb-e502-4ac2-8174-a71d591b9ddb&pd_rd_i=199922051X&psc=1 "https://www.amazon.co.uk/Agile-Testing-Condensed-Brief-Introduction/dp/199922051X/ref=pd_bxgy_d_sccl_1/525-5077970-5211661?pd_rd_w=G9vUs&content-id=amzn1.sym.ec630614-3f9e-4b7f-ba9a-fe89f8e4113f&pf_rd_p=ec630614-3f9e-4b7f-ba9a-fe89f8e4113f&pf_rd_r=XNV4CN7CHKJ9QB8J5YD4&pd_rd_wg=LUXYU&pd_rd_r=fc92e5eb-e502-4ac2-8174-a71d591b9ddb&pd_rd_i=199922051X&psc=1"), Janet Gregory and Lisa Crispin - This is a modern repackaging of Lisa Crispin’s two famous volumes “Agile Testing”, and “More Agile Testing”. It offers a number of new insights and observations not found in the original books, and is an easier read for folks new to the testing role.
+
+- [**Holistic Testing**](https://www.amazon.co.uk/Holistic-Testing-Weave-Quality-Product/dp/1999220579/ref=sr_1_1?crid=29PDHUKG18PQT&dib=eyJ2IjoiMSJ9.e0b7AjOrD1DN4lqCqqkekaHsUt_-R14fNZF7Q6QI5ArkR9Y58TUyaza2QkcUs9kLIHrYaK35BlulzBH6EJAPPJiVn6s0R0tHP5klRWKVt7c.ItmI28AW_hl2_I4TfD1oFvRD7Exni0uBvpBj4RgJEgA&dib_tag=se&keywords=lisa+crispin&qid=1765802708&sprefix=lisa+crispin%2Caps%2C102&sr=8-1 "https://www.amazon.co.uk/Holistic-Testing-Weave-Quality-Product/dp/1999220579/ref=sr_1_1?crid=29PDHUKG18PQT&dib=eyJ2IjoiMSJ9.e0b7AjOrD1DN4lqCqqkekaHsUt_-R14fNZF7Q6QI5ArkR9Y58TUyaza2QkcUs9kLIHrYaK35BlulzBH6EJAPPJiVn6s0R0tHP5klRWKVt7c.ItmI28AW_hl2_I4TfD1oFvRD7Exni0uBvpBj4RgJEgA&dib_tag=se&keywords=lisa+crispin&qid=1765802708&sprefix=lisa+crispin%2Caps%2C102&sr=8-1"), Janet Gregory and Lisa Crispin - This is an attempt by Crispin and Gregory to envision a testing methodology that makes quality a component of every engineering role in a software project. It’s an interesting concept, and a solid attempt to break the paradigmatic dogma that only “testers are responsible for quality”.
+
+- [**The Art Of Software Testing**](https://www.amazon.co.uk/Art-Software-Testing-Glenford-Myers/dp/1118031962 "https://www.amazon.co.uk/Art-Software-Testing-Glenford-Myers/dp/1118031962"), Glenford J. Myers (updated by Corey Sandler, Tom Badgett) - This book is basically the grandfather of all testing books. Whereas most books on software testing target particular modern development techniques, languages, or testing methods, this provides a comprehensive presentation of time-proven software testing approaches, from the early days of software and hardware development. (Good luck finding a copy!)
+
+- [**A Practitioner’s Guide To Software Test Design**](https://www.amazon.co.uk/Practitioners-Software-Design-Computing-Library-ebook/dp/B001GS7030/ref=sr_1_1?crid=3LQDACWHRZDHJ&dib=eyJ2IjoiMSJ9.LOKSBRYSkLCpQ2B1ynQPdzSdiD5fOo56FeNLDjJDQ9soQptrzQBqZQAZAbqXDgST.xfenhbFaMpCow0oIUp9JmY4-BcQDTS1Tv5DEw5TJ3TY&dib_tag=se&keywords=A+Practitioner%27s+Guide+to+Software+Test+Design&qid=1765807872&s=books&sprefix=a+practitioner%27s+guide+to+software+test+design%2Cstripbooks%2C76&sr=1-1 "https://www.amazon.co.uk/Practitioners-Software-Design-Computing-Library-ebook/dp/B001GS7030/ref=sr_1_1?crid=3LQDACWHRZDHJ&dib=eyJ2IjoiMSJ9.LOKSBRYSkLCpQ2B1ynQPdzSdiD5fOo56FeNLDjJDQ9soQptrzQBqZQAZAbqXDgST.xfenhbFaMpCow0oIUp9JmY4-BcQDTS1Tv5DEw5TJ3TY&dib_tag=se&keywords=A+Practitioner%27s+Guide+to+Software+Test+Design&qid=1765807872&s=books&sprefix=a+practitioner%27s+guide+to+software+test+design%2Cstripbooks%2C76&sr=1-1"), Lee Copeland - This book is the test engineer’s bible for test design. From equivalence classes to state transitions, from requirements definitions to test case construction, this is the ultimate How-To guide. If you were to take a college course in software testing, this would be your textbook. It’s available on Amazon, but it’s ridiculously expensive.
+
+## Blogs
+
+Blogging is a dying art form. Twenty years ago, everyone had a blog. Now, the blogging practice is almost exclusively a marketing chatter pipeline. However, there are still a few diamonds in the rough out there worth checking, from time to time.
+
+- [**Google Testing Blog**](https://testing.googleblog.com/ "https://testing.googleblog.com/") - This blog is *developer* heavy. Some count this as a mark against it. I do not. For one thing, it’s often littered with little [gems like this post](https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html "https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html"), highlighting an interesting reconceptualisation of the infamous “testing pyramid”. For another, I subscribe to the James Bach’s advice that testers should “run with the programmers”. The closer you are to the development, the better able you are to identify it’s potential weaknesses.
+
+- [**Lisa Crispin Holistic Testing Blog**](https://lisacrispin.com/agile-testing-blog/ "https://lisacrispin.com/agile-testing-blog/") - This blog focuses mainly on meta-level Agile testing practices. Lisa is one of the preeminent voices in Agile testing, and an excellent counterpoint to older “waterfall” style approaches. She is the author of “Agile Testing” and “More Agile Testing”. Essential reading for testers working in Agile environments.
+
+- [**James Bach Satisfice Blog**](https://www.satisfice.com/blog "https://www.satisfice.com/blog") - James Bach is a legend in software testing. He’s not as well published as Lisa Crispin, or as well admired in Agile circles, but his book “Lessons Learned in Software Testing” is an absolute must-read for any tester in any environment, and his blog often surfaces extremely interesting ways to think about testing.
+
+- [**Sticky Minds Blog**](https://www.stickyminds.com/sm-topics/testing "https://www.stickyminds.com/sm-topics/testing") - This blog is devoted to commercial test practices. It’s structured like a marketing blog, but it’s run by testing professionals who subscribe to the platform, and articles are vetted for quality. They also occasionally publish interesting white papers. It’s a good place to keep track of industry trends and explore testing case studies.
+
+- [**Visible Quality Blog**](https://visible-quality.blogspot.com/ "https://visible-quality.blogspot.com/") - This is a tester from Finland who’s been blogging for many years. Her insights and observations come directly from her experience in different industries. It’s interesting to check in once in a while to see what’s on her mind.
+
+- [**The Green Report**](https://www.thegreenreport.blog/ "https://www.thegreenreport.blog/") - This blog is almost entirely devoted to automated testing tools (such as Playwright and Cucumber). There is a vast library of posts offering tips and tricks for implementing automated tests in a wide variety of different circumstances.
+
+## Essential Tools
+
+Software Engineers use software engineering tools. Software test engineers use software test engineering tools. Here is a short list of tools I use every day:
+
+* **Your brain** - As I've discussed in several other posts, your critical thinking skills are your first and most important tool. Everything else follows from that.
+- **The web browser console** - As more and more applications have moved into the cloud, and more and more user interfaces have been designed around the web browser, the browser’s developer tools have become an ever more essential component of software testing. This is useful not just for peaking under the hood, but also for simulating behaviours, exploratory testing, and a wide variety of hacking applications.
+
+- **A screen capture utility** - saving logs, config files, and results are an important part of testing. But sometimes there’s just no substitute for WYSIWYG. A screen cap utility read to hand is a must-have.
+
+- **A terminal** - Even if you are a so-called “black box” tester, sometimes you need to do things to the box that just aren’t possible from a GUI window. In those instances, it is extremely useful to know how to get around the command line. Every OS has a default terminal application. Learn to use it.
+
+- **An API probing tool** - The most popular options at the moment, are Insomnia, Postman, and [Bruno](https://www.usebruno.com/ "https://www.usebruno.com/") (my favourite). They all do pretty much the same things, in slightly different ways. If you’re feeling especially industrious, most of what is done in these tools can be done in scripting languages (especially Python).
+
+- **A debugging proxy utility** - this may be only occasionally necessary, but when it is, it’s a lifesaver. Personally, I’ve used [Charles](https://www.charlesproxy.com/ "https://www.charlesproxy.com/") in such cases.
+
+- **A scripting language** - It doesn’t necessarily matter what language, as long as it has the features needed to accomplish your testing needs. I’ve used Python, Bash, JavaScript, Go, Perl, Rexx, PROLOG, Java, and C# at various times in my own career.
+
+- **A code and/or text editor** - Whether you use something simple like Notepad++ or Kate, or you prefer a fully kitted out development environment like Visual Studio or JetBrains IDEs, you’re eventually going to need a code editor. Even if only to inspect a config file or a json export. Pick one and get used to it. My favourite for lighter tasks, is [VIM](https://www.vim.org/ "https://www.vim.org/").
+
+- **A ticketing system** - for logging test findings that are eligible for referral to the engineering backlog.
+
+- **A test case management tool** - for creating “to do” lists for testing. This can be as simple as a basic text editor, or a complex as a full test case management software solution. The project will determine the need.
+
+- **A test execution reporting tool** - this can be as simple as an email or comment on an engineer’s ticket, to a page in a confluence document stack, or as complex as a full test execution reporting software solution. The project will determine the need.
diff --git a/articles/the-categories-of-testing.md b/articles/the-categories-of-testing.md
new file mode 100644
index 0000000..fbd683e
--- /dev/null
+++ b/articles/the-categories-of-testing.md
@@ -0,0 +1,97 @@
+I’ve already discussed in [a previous post](https://perspectum.atlassian.net/wiki/x/GwBN0w "https://perspectum.atlassian.net/wiki/x/GwBN0w"), albeit to an incomplete degree, what a tester is. In this post, I’ll be addressing perhaps an even more important question. Namely: *what is a test?* The answer is hinted in yet [another previous post](https://perspectum.atlassian.net/wiki/x/uICZ5 "https://perspectum.atlassian.net/wiki/x/uICZ5"), where I asserted that a tester is fundamentally a “*fact finder*”. From that label, one could infer a very low-resolution definition: if a tester is a fact finder, then a test is the process by which a finder goes about finding his facts.
+
+This answer is not wrong, but it’s also not very informative. There are lots of facts to find in the world. My precise height and weight. The date of the Whiskey Rebellion. Where the data for my project is stored. The property of transparency in glass. What time you arrived at work this morning. And so on. Every one of these facts entails a different process by which they are discovered. Does that make every fact-finding effort a test? Does it make every fact an artefact of a testing activity?
+
+In a word, no. There are a wide variety of ways in which we come to discover facts, and not all of those activities are “tests”. Even within academic disciplines this is not the case. A historian, a mathematician, a scientist, and a theologian all employ different techniques for the discovery of facts (and, indeed, have very different uses of the word “fact”, but that’s a story for another time). So, what are we talking about, then?
+
+## The Role Of The Tester
+
+A tester is a fact-finder in a specific context, and of a specific kind. Namely, a tester is only interested in facts about the project on which he works – and his discovery processes will be those best suited to provide him with the facts relevant to the aspect of the project under scrutiny.
+
+Thus, the tester is a finder of facts about the application he is testing, facts about the people who interact with the application, and facts about the relationship between these two poles. He uses testing practices appropriate to each of these three questions, to discover the relevant facts.
+
+But, just as there are many different kinds of facts about the world and many different kinds of disciplines that discover those facts, there are also many different kinds of facts about your software project, and many different kinds of testing needed to discover those facts.
+
+## Testing Categories
+
+Any cursory internet search will yield dozens of pages that will give you a variety of lists of “kinds of tests”. But most of these lists don’t do a very good job of *defining* the kinds, choosing instead to describe the practices and outcomes in lieu of a definition. Others will offer two very broad (and again, not very informative) categories of “functional” and “non-functional”, where everything from units to user experiences counts as “functional”, and everything from configuration to compliance counts as “non-functional”.
+
+Instead, as I’ve already telegraphed above, I think it makes more sense to group kinds of tests by the kinds of facts that we’re interested in, not by the kinds of activities we’re engaged in to discover those facts. To put it another way: what matters is not so much *how* we gather the information, but what the information *is for*. When viewed from this vantage point, there are essentially three kinds of facts we’re interested in:
+
+- Facts about the behaviour of the the application under test
+
+- Facts about the behaviour of the human beings interacting with the application under test
+
+- Facts about the relationship between the two
+
+The facts gathered in each of these three categories enables us to make decisions about the way the application is constructed, the possibilities it will offer to users, and how those possibilities are presented. It will also enable us to make decisions about who will be using our application, how we expect them to use it, the kinds of experiences we want them to have, and the value we expect them to derive from those experiences.
+
+### Application Behaviour
+
+This is what most people think of when they think of “functionality” - what does your application *do*? Under this category, many familiar headings will appear: API testing, unit testing, integration testing, and so forth. But, again, we should think in terms of the kinds of facts, and what they are for.
+
+Here, context is the key concept. Different contexts have different scopes, and as such different facts we care about. As the context changes, the scope changes, and with it, so do the human beings involved.
+
+#### **Units**
+
+While it’s true a developer is not necessarily a *user* of an application he is building, he is nonetheless a human being that interacts with the application. His interactions are as a *builder*. So, he is intricately familiar with its structure, its component parts, and the relationships between them.
+
+As he makes changes to the application, he will want to know many things: is the unit of change producing the results I expect? Is the unit affecting the units around it? Are the changes affecting the structural integrity of the whole? Are there any unexpected outputs? And so forth. A developer will want to answer these questions quickly and precisely, as a part of his workflow. To be productive and efficient, he cannot wait weeks for each change to land in the hands of a user before discovering these answers.
+
+This is the purpose of unit tests. They are a programmatic tool enabling the application to provide the developer with immediate feedback about his changes. They provide facts that are essential to decisions the developer makes during development process.
+
+#### **Integrations**
+
+Integrations are a level above units, and involve the orchestration of two or more units. This is sometimes called “functional testing”, in the sense that multiple units combine to produce whole conceptual “functions”. Think, for example, of a unit that generates a numeral every time it executes, and another that adds numerals it receives to an accumulator to produce a new number. Independently, each is useful in its own right. Together, they produce something neither could do independently: an infinite accumulator. This is a ‘function' because it performs some relatively simple transformation, but requires the integration of multiple units to accomplish the goal.
+
+The purpose of an integration test, then, would be to prove that what I described to you just now, is actually what happens when you put these two units together. This would be the first question you might ask: “does it do what you say it does?”. Also, you might want to answer some (but not all) of the questions from the section on units. Typically, the developer is person interested in the answer to these questions. In many development organisations, the developers will therefore also write their integration tests. However, in some cases, integration tests can be written by test engineers, or by other specialised roles tasked with the responsibility for certain kinds of integrations.
+
+#### **Systems**
+
+Systems are orchestrated collections of integrations that deliver a coherent value to a user. Think of a computer system. It is the assembled result of hundreds of integrated functions, and thousands (or tens of thousands) of individual units. From component parts like capacitors, to integrated circuit chips, to the motherboard and its ‘daughter’ boards, to the chassis and all of the peripherals, the final result is a product that you and I can use to accomplish an infinite number of different goals.
+
+As we move into wider and wider contexts, the questions we want to answer will grow in scope along with the move. System Testing is essential for discovering the answers to questions that cannot be asked at smaller contexts like the unit and integration level. It is one thing to know how much stress a wheel can undergo at speed. It is another thing to know how a steering assembly will behave when wheels of a certain weight are attached to the axel. But it is yet another question to know how an entire vehicle will perform with that steering assembly and wheels, on a test track. This, then, is system testing.
+
+At this level of testing, the number of questions we will want to answer will increase asymptotically. And the ways of deriving answers to those questions is myriad and diverse. There are whole categories of questions one can ask about a complete system. Internet lists will often display these as separate kinds of testing on testing lists: performance, security, compatibility, reliability, user journeys, and so forth. As such, tests may be written and performed by any number of different kinds of people, from developers and testers, to application specialists, or industry reviewers, or specialised auditors (think Underwriters Laboratories).
+
+### Human Behaviour
+
+So far, we have only been dealing with questions we might have about the behaviour of the application under test. But there is another aspect of testing that is often neglected when considering the the testing of applications: namely the behaviour of the human beings who use them.
+
+The facts we’re most interested in getting out of this kind of testing are different from the kinds of facts we get out of application behaviour testing. In this case, we want to know if a user is able to accomplish a goal, what kinds of processes and functions he prefers in accomplishing his goal, and even his feelings and opinions about various features of the application.
+
+**User Experience**
+
+In the same way we often make assumptions about the way an application will behave when we subject it to certain conditions, we also often make assumptions about the way a human will behave when we present them with an application user interface, and give them a goal. This is where user experience testing comes in. It’s purpose is to compare our assumptions about our users, to the real behaviours exhibited in real world conditions.
+
+Today, this is sometimes called “usability” testing (because of the modern trend of assigning an “ility” adverb to every aspect of an application). This might involve walking a user through a particular task and making a note of where he struggles to complete it, or asking a user to point out where certain things are found in the application UI, or it could be as complicated as giving a user a complete goal to accomplish and recording his journey from start to completion.
+
+**Quality vs Quantity**
+
+The two main varieties of “usability” testing are “qualitative” and “quantitative”. The former is traditional “UX” testing, in which user feedback is collected and used to improve the design of an application with a focus on the qualities of the individual user experience. The latter is designed to identify problems with process efficiency or performance bottlenecks, and involves collecting benchmark indicator data that can be tracked over the span of a large cohort of users, or over a large number of user journey iterations.
+
+**UX Testing Techniques**
+
+Here are some common techniques for collecting either qualitative or quantitative facts about user experience:
+
+- *Concept Testing:* Select users are presented with wireframes, paper sketches, or physical mock-ups, and testers engage in conversations with users about the proposed concepts.
+
+- *A/B Testing:* Two different versions of an application UI are deployed to a UAT environment or production environment, and select sets of users will be presented with either the “A” version or the “B” version. Evidence of the users' journeys are collected and evaluated to determine which version is desirable.
+
+- *“Heat Map” Analysis:* This is one of the “quantitative” techniques. This essentially aggregates a record of the places on the application where clusters of user interactions have taken place, across a cohort of users. It provides information about common user behaviours, and places where the application may be causing behavioural bottlenecks.
+
+- *Card Sorting*: This technique is designed to improve the information architecture of a product, by evaluating the way your users understand the concepts, topics, and categories of information employed in the application.
+
+- *Moderated Testing*: This testing is an observational technique meant to provide direct feedback about the mechanics of a user journey. Users are given specific tasks to accomplish, and testers record the relative ease or difficulty of accomplishing those tasks. Often additional subjective feedback is also collected as part of this process.
+
+### Application-User Relationship
+
+The third and final question any good development team will be interested in asking, is what sort of relationship exists between the user and your product. This question is a bit of a meta-question, in that it arises out of a synthesis of the first two questions, and a third question. Namely, market demand and business needs. The goal is to discover how the first two questions connect in the middle to deliver value, and the facts needed to answer that question are derived from the outcomes of the first two questions, combined with what can be discovered about the broader needs of customers.
+
+This is a question asked more often by sales and service teams, or by product owners, than by development teams and testers. The kinds of facts that would be interesting, and the sorts of questions that would surface those facts are going to be business delivery oriented, but focused on the product lines provided the business. This is sometimes known as “market testing” or “business development”, and is beyond the scope of this article.
+
+## Conclusion
+
+The perceptive reader will note the gradually expanding scope of each of these kinds of “tests”. The further up you go from the unit, the greater your view of the landscape. Simultaneously, the further up the “stack” you go, the less specific and granular your understanding of that landscape. From a plane you can differentiate farmland from urban areas, but you would’t be able to tell me where the occupant of flat 10 in building 4 of the urban area has parked his car, or how much grain farmer Smith has left this quarter, for his cows. Likewise, farmer Smith could tell me about his grain, but could not tell me what the population of the urban area is, or whether there is enough roadway to handle the new development in region 3.
+
+Each context offers different kinds of facts, and as such, different kinds of questions can be asked within them. This requires different kinds of tests – and different kinds of testers – who are trained to ask the right questions, and to interpret answers looking for the kinds of facts within those answers that help to make decisions about the product being tested.
diff --git a/articles/the-logic-of-software-testing.md b/articles/the-logic-of-software-testing.md
new file mode 100644
index 0000000..05166a5
--- /dev/null
+++ b/articles/the-logic-of-software-testing.md
@@ -0,0 +1,93 @@
+Most testers aren’t consciously aware of the fact that their work requires them to engage in a fairly complex and rigorous set of inferential procedures. Most of us grow up absorbing them intuitively, to one degree or another, by way of the accidents of experience; never giving them names of their own. Aristotle would say you do not know a thing until you are capable of giving it a proper name, and you cannot name things properly until you can define their fundamental essence. Given that as our motivation, let us make a proper inventory of the ways in which a tester thinks.
+
+## What Do You Know, and How Do You Know It?
+
+Software testing is “knowledge work” in the most literal sense of the term. The work of the tester is intended to provide a body of evidence from which a software development organisation can establish a shared understanding of what they have built.
+
+In philosophy, the field of study in which this work belongs is “epistemology”. Epistemology is concerned with what you know, how you know it, and why you believe it is true. It is from this field of philosophy that testers derive core concepts of their work. Notions like “belief”, “truth”, “fact”, “perception”, “judgement”, “opinion”, and of course “knowledge” itself.
+
+Software testing is not itself an academic discipline. It is one *applied practice* of the discipline of Epistemology. The difference cannot be stressed enough. Testers practice the art of discovering what can be known about software. For comparison, another *applied practice* of epistemology would be scientific fields like chemistry or physics. Mathematicians and philosophers (in other fields) also engage in the applied practice of the discipline of epistemology. What differentiates the scientist from the mathematician, is the *kind* of knowledge their practice is interested in, and the methods required to obtain that knowledge. As noted in several previous posts, software testing is also interested in certain kinds of knowledge, and employs certain methods of its own, suited to obtaining knowledge particular to its field.
+
+What methods are those, exactly? How is the tester moving from mere opinion to knowledge, using these methods? Let's explore them, one by one.
+
+## Four Key Ways We Reason As Testers
+
+There are many forms of procedural reasoning that investigators, scientists, and indeed software testers engage in, when they are attempting to reach a confident conclusion. Among the variety of methods, there are four essential forms that occur most often in our daily lives, as technicians and testers. Let's examine each separately.
+
+### Conditional Logics: The Twin Pillars
+
+The first two should be immediately recognisable from their description, because we engage in this almost continuously, throughout our daily lives:
+
+- **Modus Ponens** - If P implies Q and P; then Q. Used to derive knowledge from conditional statements and established premises. This form of reasoning is typically known as "confirmation" or "validation", in practice. If we find "P", then the positive assertion in "Q" is true. We found "P", therefore "Q" is the case. Here's an example: If the marble jar is full, then John has put all of his marbles away. The marble jar is, in fact, full. Therefore, John has put all his marbles away. This is a useful mode of reasoning where certainties are high, such as in mathematics. However, as we'll next see, this mode of reasoning can be deceiving in more material contexts.
+
+- **Modus Tollens** - If P implies Q and not Q; then not P. Applied to test and falsify knowledge claims by examining their logical consequences. This form of reasoning is often thought of as "falsification" or "exception reasoning". If we find "P" then the positive assertion in "Q" is the case by implication. However, we know from observation that "Q" is not the case. Therefore, "P" cannot be the case, either. Let's take the example from Modus Ponens and rework it: If the marble jar is full, then John has put all his marbles away. However, there are marbles on the floor. Therefore, John *has not* put all his marbles away, *even if the jar appears full*.
+
+To put it simply, Modus Ponens is primarily about *what we can know*, and Modus Tollens is primarily about *what we cannot know*. Thinking about the examples in particular, we can see that the difference between these two forms of reasoning lies in *where we focus our attention*. To put it another way, the difference lies in where we make our observations. In the case of Modus Ponens, the imperical anchor is **P**. The example is primarily concerned with *what state the jar is in*. In the case of Modus Tollens, the empirical anchor is **Q**. That example is primarily concerned with *what state the marbles are in*.
+
+In software testing, the gap between the two forms of reasoning can show up in a wide variety of ways. Perhaps the most common (and entertaining) symptom of this is the sarcastic developer slogan, "Works On My Machine!". The developer's focus is *on his code*. The tester's focus is *on the target environment*. The developer is operating in Modus Ponens mode, the tester is operating in Modus Tollens mode. Or, to put it more simply: The deveoper is asking himself the question, "what gets the code to work", and the tester is asking himself the question, "what gets the code to stop working".
+
+### Induction: Can you reproduce it?
+
+The next most common form of reasoning can be seen in the question asked in this heading. Given a situation in which I observe X when I do Y, am I justified in concluding that X always follows Y? What criteria must be satisfied to qualify for justified belief? Repeating the scenario two times? Ten times? A hundred times? This is known as ***inductive generalization***.
+
+Our intuition might incline us to suspicion at such an approach to belief. How could *any* arbitrary number of repetitions justify a belief? But before we concede to our skepticism, consider the fact that the most common example of a conclusion drawn from such a generalization, is our automatic expectation that the sun will rise in the east tomorrow morning. In our own context, an example of inductive generalization that directly affects our business would be the phases of a drug trial, where conclusions are drawn from the results of thousands of trial volunteer repetitions.
+
+Still, we should take care when using inductive generalization to reach conclusions about our work. There are two common traps of generalization of which we ought to be wary. Let's discuss each separately.
+
+***Dirty Inductions***
+
+The first is "weak" or "dirty" generalization. This form of induction too easily accepts a generalization as true, because no counterexample is available. The problem can be demonstrated by extending the drug trial metaphor from above. Let us consider: Children who get the measles vaccine almost never get measles. We conclude from this, that the measles vaccine prevents the contraction of measles.
+
+But is this conclusion justified? To see why it is not, let me modify the analogy slightly: People who wear garlic necklaces are never attacked by vampires. So, we conclude, garlic neclaces are effective wards against vampire attack. What's the problem with this? Essentially, we haven't established an actual threat. Or, more precisely, we haven't established a causal relationship between the lack of vampires and the presence of garlic. The people who *don't* wear garlic necklaces *also* don't experience vampire attacks. So, what's really going on here?
+
+Likewise, with way we've framed the story of the measles vaccine. We would need to establish a like-for-like threat between two similar groups of people, and then show a difference in the group that took the vaccine. In a scientific study, the untreated are known as a "control" group. In this kind of inductive generalization, we are attempting to find a way to rule out the people who don't wear garlic neclaces, so that we can establish a firm basis for our generalization about those who do wear garlic neclaces. This is what is known as "eliminative" or "comparative" induction, because it is an attempt to reason from two parallel lines of evidence in which one line has had a variable introduced, while the other has had it eliminated, providing an anchor for comparison.
+
+***Correlation Versus Causation***
+
+The second problem with inductive generalization is the problem of spurious association. This form of induction too easily accepts a causal claim from a consistent association. It assumes a causal link from a correlation, even if a causal agent is unknown. The fallacy in this assumption has been famously illustrated at the website [Spurious Correlations](https://www.tylervigen.com/spurious-correlations "https://www.tylervigen.com/spurious-correlations"), where, among other things, we can discover that the national per-capita consumption of margarine in the US is nearly perfectly correlated with the divorce rate in the state of Maine:
+
+![](/Users/gregory.gauthier/Documents/BlogPosts/assets/31964a5e-eb5d-478b-9be5-2c7e6612e542.png)
+
+The central question still open on this example: is the decline of margarine consumption responsible for the falling divorce rate? Or is the falling divorce rate the cause of the decline in margarine consumption? It turns out, both questions are illustrative of the "spurious association" problem. These sorts of simple linear associations are quite easy to find. What is much more difficult, is being able to maintain the correlation. If you were to expand this graph out by 40 years, the relation would collapse. In addition, there are literally dozens of much more sensible common causes that could be identified to explain this brief period of correlation. As off-the-cuff examples: a decline in preference for vegetable oils, a change in economic policy in Maine making marriage more lucrative, the migration of people inclined to divorce to other states, the cost of margarine production, and so forth. There are presently over three thousand such examples of spurious association to be found on the [Spurious Correlations](https://www.tylervigen.com/spurious-correlations "https://www.tylervigen.com/spurious-correlations") website. They're quite fun to read.
+
+However, sometimes correlation is indeed an excellent indicator of causation. The most famous modern instance of this is the history of cigarette smoking. For decades, cigarette smoking was strongly correlated with many health problems. Lung cancer, pulmonary disease, ischemic stroke, and several lesser health conditions were very often observed in the majority of the population that also regularly smoked cigarettes. Many people pointed to this as an obvious problem, but others (including many doctors) dismissed the concerns as a spurious association. It wasn't until the 1970s, that medical science had managed to finally isolate actual causal agents, such as aromatic hydrocarbons, nitrosamines, and aldehydes, that were directly responsible for the cancers and pulmonary diseases associated with smoking. Over the same period, numerous experts and investigators have failed to find "third variable" explanations that could break the strong correlation between the two phenomena, in the way that one easily could with margarine and marriage.
+
+### Abduction: Elementary, My Dear Watson
+
+This form of reasoning is perhaps the most common across all engineering disciplines. It is the kind of reasoning we do, when troubleshooting a problem, or searching for systemic causes to those problems. The plain English way to describe this form of reasoning, is "inference to the best explanation", and it works by taking an aggregation of weakly related observed phenomena, and hypothesizing plausible common causes, eliminating each until we land on a hypothesis that explains all the phenomena together.
+
+Perhaps the most famous cultural illustration of this kind of reasoning can be found in Arthur Conan Doyle's Sherlock Holmes novels. Most of the mysteries he solved, were (despite his declarations to the contrary) concluded *abductively*, not *deductively*. For example, here is how he did just that, in [The Adventure of Silver Blaze](https://etc.usf.edu/lit2go/40/the-memoirs-of-sherlock-holmes/573/adventure-1-silver-blaze/ "https://etc.usf.edu/lit2go/40/the-memoirs-of-sherlock-holmes/573/adventure-1-silver-blaze/"):
+
+- **Observation** (surprising fact): The watchdog did not bark on the night of the crime.
+
+- **Inductive generalization**: “In my experience, dogs bark at strangers 99% of the time.”
+
+- **Abduction** (what Holmes actually does):
+  
+  - *Step 1*: *Speculation*: There are three possibilities: The dog was removed; the dog was drugged; the dog knew the intruder.
+  
+  - *Step 2*: *Elimination*: Evidence establishes the dog was present, and not drugged (this, through inductive inferences).
+  
+  - *Step 3*: *Abductive conclusion*: “The absence of barking is surprising under the stranger hypothesis, but completely expected if the culprit was someone the dog knew. The ‘familiar person’ hypothesis explains the data far better than any rival. Therefore, the best explanation is that the thief was someone the dog knew.”
+
+  As the Holmes novels demonstrate, this form of reasoning can be and usually is an extremely powerful tool in everyday life. Indeed, so powerful that Holmes is often contrasted as nearly superhuman in his capacity to discern, compared to the police and his companion Dr. Watson. However, as the method would also indicate, this form of reasoning is heavily dependent upon experience. Or, to be a bit more explicit: the accumulation of empirical knowledge that can be used to reason inductively to generalizations ("In my experience, someething does X when Y"). Thus, this form of reasoning is also perhaps the most susceptible to a whole host of problems. Among the most common:
+
+- *"Cherry-Picking"* - selecting only the bits of evidence that validate a hypothesis we prefer
+
+- *Availability Bias* - taking the first thing that comes to mind as the most "plausible" hypothesis, regardless of whether it satisfies all explanatory criteria.
+
+- *"Satisficing"* - taking the first hypothesis that "fits", out of convenience. Different from Availability Bias in that the hypothesis has to actually satisfy all the explanatory criteria.
+
+- *Emotionalism* - confusing certain explanatory virtues with the truth. In other words, taking a hypothesis that is emotionally satisfying, over an hypothesis that satisfies all the explanatory criteria.
+
+- *Undecidability* - two or more hypotheses are equally capable of satisfying all the explanatory criteria, and no additional information tips the scales.
+
+- *Faulty Background Assumptions* - if the generalizations we draw from experience are skewed or mistaken, the abduction will typically fail. What if Holmes' experience had been that only about 50% of dogs bark at strangers?
+
+- *Overconfidence* - taking the "best explanation" as final and definitive.
+
+Indeed, we can see hints of this in the Holmes story above. Why should we take the generalization as read? Perhaps, if we were to test Holmes' anecdotal experience, we would find that statistically speaking, only about 50% of dogs bark. Even if we assume this background knowledge, why are his three speculations the only possibilities? Perhaps the dog was poorly trained? Perhaps the dog was exhausted and the culprit was especially stealthy? Perhaps the dog was distracted by something else? The possibilities are actually endless. Holmes never checks any of these. He simply declares the “best” explanation based on his own background beliefs and moves on. This is why philosophers of science say Holmes is a brilliant literary example of abductive reasoning done badly in real life.
+
+## Conclusion: Think About It
+
+This post is not intended to make philosophers out of engineers or testers. It's also not intended to advocate for any change in the way we do things. However, it is advocating for a more *conscious* approach to what we already do, day to day. Aristotle rightly points out that It is one thing to be really good at some particular thing, but quite another to *know why* you are good at it. To advance from "experienced practitioner" (an "empiric"), to a genuine artisan (an "epistemic"), is to graduate from knowledge of the *what*, to knowledge of the *why*. It is knowledge of the why that gives us genuine mastery over our environment. And it is that mastery that elevates the quality of any endeavour. So, I would encourage everyone to spend just a little time, thinking about how they think about their work.
diff --git a/articles/the-perturbation-theory-of-exploratory-testing.md b/articles/the-perturbation-theory-of-exploratory-testing.md
new file mode 100644
index 0000000..309ac32
--- /dev/null
+++ b/articles/the-perturbation-theory-of-exploratory-testing.md
@@ -0,0 +1,110 @@
+## Perturb- What?
+
+Perturbation Theory is a powerful mathematical framework in physics used to find **approximate solutions** to complex problems that can't be solved exactly. You tweak a well-understood system slightly, in a controlled way, and see how those small changes ripple through. This technique is ubiquitous in quantum mechanics, but it also pops up in classical mechanics, electromagnetism, and even cosmology. The core idea: Start with a "simple" problem you *can* solve exactly, then treat the complicating factors as tiny "perturbations" and calculate their effects step by step.
+
+Consider the problem of Jupiter in calculating planetary orbits. It turns out that approximating the trajectory of a planet orbiting the Sun (the exact, solvable part) while accounting for the slight gravitational tug from Jupiter (the perturbation), requires ridiculously messy equations without the aid of something like Perturbation Theory.
+
+Many much more sophisticate real-world physical systems are too intricate for closed-form solutions. For example:
+
+- In quantum mechanics, the Schrödinger equation for multi-electron atoms or molecules is nightmarishly complicated.
+
+- In particle physics, interactions between quarks or fields involve infinities that exact math can't tame.
+
+Perturbation theory shines when the "extra stuff" (like interactions or external fields) is **weak** compared to the main system.
+
+## What Does That Have To Do With Software Testing?
+
+A “Perturbation”
+
+As a software tester in a large, complex environment, I wonder if the technique of "*tweaking a well-understood system slightly and seeing how those small changes ripple through*" could be applied to a practice like exploratory testing. Very often, I deal in "complex problems" and "approximate solutions" for them. I imagine a principle like the one behind the "perturbation theory" might be extremely useful in testing.
+
+In fact, perturbation theory's elegance in handling complexity through controlled approximations translates beautifully to software testing, especially in exploratory contexts where you're navigating black-box behaviours without exhaustive scripting or extremely thorough documentation. In fact, it's not just a loose metaphor; software engineering has formalised similar ideas under terms like **perturbation testing** and **chaos engineering**, which treat the application as that "well-understood system" and introduce deliberate tweaks to reveal hidden ripples (bugs, vulnerabilities, or resilience gaps):
+
+1. **Perturbation Testing (for Domain Errors and Vulnerabilities)**:
+   
+   - This directly echoes the physics concept: You perturb arithmetic expressions or environmental variables in code to detect faults that slip past traditional unit tests. For instance, in a financial app, tweak a calculation like total = price * quantity by swapping operators (+ instead of *) or injecting off-by-one errors, then run the perturbed code and compare outputs. Ripples? Silent overflows leading to bad trades.
+   
+   - In exploratory terms: During sessions, use this to probe edge cases. Tool tip: Browser dev tools or Postman can inject perturbations like malformed JSON payloads. It's great for "approximate solutions" in large systems, as you can automate low-order checks and explore higher-order manually.
+
+2. **Chaos Engineering (for System-Wide Ripples)**:
+   
+   - Here, perturbations are intentional failures (e.g., killing pods in Kubernetes or spiking latency) injected into production-like environments to observe holistic responses. Netflix pioneered this to harden streaming services—think: Tweak network conditions slightly and watch if recommendations degrade gracefully or cascade into outages.
+   
+   - Exploratory angle: Frame your charters around "steady-state hypotheses" (e.g., "The app handles 10% traffic spikes without dropping sessions"). Start small (λ ≈ 0.1), measure, then scale. Tools like Gremlin or Litmus make it low-friction for testers. In complex setups, this uncovers non-obvious interactions, like a microservice tweak rippling to auth timeouts.
+
+## How Would That Even Work?
+
+Figuring It Out
+
+In perturbation theory, you baseline a solvable model (H₀) and layer in small disturbances (λV) to approximate outcomes iteratively. In testing:
+
+- **Unperturbed baseline**: The "happy path" or nominal workflow—e.g., a standard user login with valid creds in your app. This is your exactly solvable starting point, mapped out via quick smoke tests or session charters.
+
+- **Perturbations**: Introduce minor, controlled variations—invalid inputs, timing delays, resource constraints, or config tweaks—and observe the "order-by-order" effects. First-order: Does it just shift the output slightly? Second-order: Does it cascade into failures elsewhere (e.g., a UI glitch triggering a backend deadlock)?
+
+- **Approximate solutions**: You don't need to test *every* combo (impossible in complex systems); instead, prioritise perturbations based on risk (e.g., high-impact areas like auth or payments) and iterate until the ripples stabilise or reveal breakpoints.
+
+This mindset shifts exploratory testing from pure ad-hoc wandering to a more structured "scientific experiment," where each tweak builds confidence in (or debunks) the system's robustness. It's approximate because real environments are chaotic, but that's the point: You're modelling resilience under uncertainty, much like physicists approximate quantum interactions.
+
+## Applying It to Our Workflows
+
+In a complex environment such as ours, starting simple avoids overload. Here are some examples of how we could apply a “perturbation theory” approach to testing at Perspectum:
+
+- **Charter Design**: "Perturb user inputs in the data-selection flow and map first-order UI ripples." Log variations systematically (e.g., via session notes in Rapid Reporter).
+
+- **Risk-Guided Scaling**: Use historical bug data to pick perturbations—focus on "weak couplings" like API integrations.
+
+- **Hybrid with Automation**: Pair exploratory perturbations with scripted “fuzzing” frameworks (for example, AFL++, which is useful with C++ apps), then explore the “ripples” with follow-up charters.
+
+- **Metrics for "Good Enough"**: Track coverage not by lines-of-code, but by "perturbation tolerance" (e.g., % of tweaks that stay within SLAs). This is just one of dozens of ways to make “coverage” a high resolution signal for quality.
+
+This approach could make our testing more predictive and less reactive, turning approximations into actionable insights.
+
+## How It Might Look In Practice
+
+Here is an example using Elizabeth Hendrickson’s “Explore It!” approach to exploratory testing. The framework employs a concise charter statement, focused data collection, and time-bound sessions. Here is how we might synthesise a “Perturbation” version of such a framework:
+
+The charter treats the whole service working “correctly” as our "unperturbed baseline" (the nominal end-to-end workflow) and introduces controlled "perturbations" (small tweaks to inputs, timings, or configs) to reveal ripples (e.g., data integrity issues, SaMD analysis issues, or report inaccuracies). This keeps the session structured yet flexible, ideal for a complex, regulated domain like medical data handling.
+
+In practice, you'd document this in a Jira ticket or a Confluence page. Ideally, it would be run during a sprint in a pair. Both a test engineer and a dev for pair-testing. Aim for 60–120 minutes to avoid fatigue, and debrief afterward to log insights as stories or defects.
+
+#### Example Charter Details
+
+|                                                         |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Section                                                 | Content                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| **Charter Statement**                                   | Explore the resilience of the end-to-end study data pipeline by perturbing key workflows around data uploads, associations, downloads, SaMD analyses, and report distribution. Focus on first- and second-order ripples in data integrity, usability, and compliance. **Hypothesis**: Small input or timing perturbations will expose integration gaps without cascading into full failures.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| **Scope & Focus Areas**                                 | **Baseline Workflow**: Simulate a "happy path" cycle: Customer uploads valid DICOM files (e.g., 100MB anonymized scan); associate with a trial project/clinical diagnosis; download to analyst workstation; run SaMD analysis (e.g., liver segmentation); generate PDF report; distribute report via appropriate channel. <br>- **Perturbations** (Prioritize 3–5 based on risk; start small, λ ≈ 0.1–0.5): 1. **Input Tweaks**: Malformed uploads (e.g., corrupted headers, oversized files >500MB, or non-DICOM formats like JPEG). 2. **Association Delays**: Slow portal uploads, or intermittent connection problems (simulate with browser throttling or proxy tools like Charles). 3. **Download/Access Perturbs**: Partial downloads, concurrent analyst sessions, or role-based access tweaks (e.g., revoke mid-download). 4. **ML/Visualization Ripples**: Inject noisy data into analyses (e.g., add synthetic artifacts); perturb viz params (e.g., wrong slice orientations). 5. **Report Generation**: Tweak output formats (e.g., invalid email domains) or trigger bulk distributions. - Out of Scope: Full performance/load testing or hardware-level scanner sims—focus on app-layer behaviours. |
+| **Resources & Setup**                                   | Environment: QASDEV or UAT Tools: Browser (Chrome DevTools for perturbations), Postman for API mocks, sample DICOM files (from public datasets like TCIA), screen recorder (e.g., Loom). Data: From the S3 test data bucket.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| **Time Box**                                            | 90 minutes total: - 10 min: Setup & baseline run. - 60 min: Perturb & observe (cycle through 2–3 areas). - 20 min: Debrief & note promising leads.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| **Stop Conditions**                                     | Time's up. - 3+ high-severity issues found (e.g., data leakage). - Hypothesis validated/invalidated (e.g., no ripples beyond first-order errors). - Boredom or blocker (e.g., auth outage—escalate).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| **Heuristics & Questions** (Perturbation-Guided Probes) | What happens when a perturbation hits a "weak coupling" (e.g., ML model on bad data)? - First-order: Immediate error? Second-order: Corrupted downstream reports? - Compliance lens: Does any ripple expose PHI (protected health info)? - Use SFDPOT (Structure, Functions, Data, Platforms, Operations, Time) to brainstorm tweaks on the fly.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+
+#### Sample Session Notes (What It Might Look Like Post-Run)
+
+During execution, jot real-time observations in a table or bullets—treating this as your "order-by-order expansion." Here's a fictional but realistic excerpt from a 90-min run:
+
+|      |              |                       |          |               |
+| ---- | ------------ | --------------------- | -------- | ------------- |
+| Time | Perturbation | Observation (Ripples) | Severity | Notes/Actions |
+
+|       |                                                                                                                          |                                                                                                                                     |          |                                                                                                  |
+| ----- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------ |
+| Time  | Perturbation                                                                                                             | Observation (Ripples)                                                                                                               | Severity | Notes/Actions                                                                                    |
+| 10:15 | Baseline: Upload valid 50MB DICOM to Trial #123.                                                                         | Full cycle completes: Associated in 2s, downloaded clean, LMS accurate (complete segmentation), report delivered in 30s. No issues. | Info     | Screenshot workflow; baseline stable.                                                            |
+| 25:30 | Input tweak: Corrupt header in zip upload (edit via hex editor).                                                         | Upload scan success, but zip extraction and dicom parsing fails. No data leak. Second-order: Analyst sees no worklist task.         | Medium   | Log as perf story; test retry limits.                                                            |
+| 45:00 | Download perturb: Concurrent access by two analysts (same file).                                                         | Race condition! Both analysts take the task to be executed. Only one analyst sees the task on his worklist afterward.               | High     | Repro steps: [Bulleted login sequence]. Escalate to backend team—potential sync bug.             |
+| 65:20 | ML perturb: Add noise to slices in Horos.                                                                                | LMS fails to segment. Results include un-flagged low-confidence metrics—risky for clinical use.                                     | Critical | Hypothesis busted: Ripples cascade to compliance violation. Propose input validation guardrails. |
+| 80:00 | Report tweak: Invalid email (e.g., "[test@nonexistent.com](mailto:test@nonexistent.com "mailto:test@nonexistent.com")"). | Distribution queues but bounces silently; customer dashboard shows "sent" status falsely. No notification.                          | Medium   | UI/UX issue; add bounce webhook?                                                                 |
+
+#### Debrief Insights
+
+- **Wins**: Uncovered 2 high-impact bugs in 90 min—faster than scripted tests for this complexity.
+
+- **Learnings**: Perturbations amplified integration risks (e.g., ML sensitivity); next charter: Dive deeper into LMS perturbations.
+
+- **Coverage Gaps**: Only did LMS. No BodyComp.
+
+- **Perturbation Rating**: Model worked well; higher-order ripples (e.g., from noise) were most valuable.
+
+This charter keeps things approximate and iterative, much like perturbation theory—start with the solvable baseline, layer in tweaks, and approximate the system's "energy landscape" (stability).
diff --git a/articles/what-is-a-competent-tester.md b/articles/what-is-a-competent-tester.md
new file mode 100644
index 0000000..a82122a
--- /dev/null
+++ b/articles/what-is-a-competent-tester.md
@@ -0,0 +1,9 @@
+Wise words from the early days of the web explosion:
+
+
+
+> “*A particularly terrible idea is to offer testing jobs to the programmers who apply for jobs at your company and aren’t good enough to be programmers. Testers don’t have to be programmers, but if you spend long enough acting like a tester is just an incompetent programmer, eventually you’re building a team of incompetent programmers, not a team of competent testers…*” [Joel Spolsky](https://www.joelonsoftware.com/2010/01/26/why-testers/ "https://www.joelonsoftware.com/2010/01/26/why-testers/")
+
+
+
+
diff --git a/articles/what-makes-us-better.md b/articles/what-makes-us-better.md
new file mode 100644
index 0000000..caf2d22
--- /dev/null
+++ b/articles/what-makes-us-better.md
@@ -0,0 +1,39 @@
+Recently, it has been asserted that Claude will make engineers “better”. Even if we stipulate to this assertion, what immediately comes to mind for me is, “better at what, exactly?”.
+
+## The Carpenter Analogy
+
+Let’s simplify the question by making an analogy to carpentry (we’ll take the assumption that software development is a ‘craft’ in a similar sense as carpentry). Carpenters have many tools. Some of them are categorically different from others. For example, the hammer and the sabre (jig) saw.
+
+The hammer doesn’t merely make the carpenter “better” at producing wood-crafted artefacts. It expands what is possible to be made, because with it the carpenter can make use of metallic fasteners, whereas without it, driving a metallic spike into a piece of wood is an exercise in absurdity.
+
+The same is not true for the sabre saw, though it may seem so on the surface. Yes, the sabre saw makes possible a whole range of new artefacts that are not possible without it. But the difference between it and the hammer, as that the sabre saw is *replacing* a tool that already opened that possibility up: the bow saw.
+
+Why is this significant? Because the real categorical distinction is not what artefacts the tools make possible, but what *habits* the tools make necessary *in the carpenter*. In a nutshell, the transition from hammer and bow saw to nail gun and sabre saw is a transition to a *different kind of craft*. And with it, categorically different skillsets and constraints and even materials used in the production of artefacts.
+
+So is the sabre-saw user a “better” carpenter than the bow-saw user? Only if we redefine “better” away from the original standard. He is better at rapid, repeatable, complex curves. He is worse (or at least differently skilled) at the deep tactile feedback and material intimacy that the bow-saw craftsman possessed. The artefact itself changes character: one carries the visible signature of hand and breath; the other carries the signature of machine-assisted repeatability. As Aristotle would say, the *telos* (ultimate end) has subtly shifted from the *qualities* of a *unit* to *quantities of units.*
+
+## What Does This Have To Do With Claude?
+
+Perhaps a more direct analogy will make the case clearer. I think that the distinction between pencil-and-paper, slide-rule, calculator, and spreadsheet PC, is one of *degree*, while the distinction between all of those tools and the LLM, is one of *kind*.
+
+- **Paper-and-pencil**: Pure externalisation of memory and stepwise reasoning. You still perform every logical step; the paper merely prevents forgetting and lets you see the chain at a glance.
+
+- **Slide-rule / calculator**: Accelerates arithmetic and logarithmic operations, but the *selection* of which formula, which approximation, which interpretation belongs entirely to you. The device has no model of the problem — it is a dumb multiplier of your own causal understanding.
+
+- **Spreadsheet PC**: It automates repetition and what-if analysis, but you still have to *construct the model* cell-by-cell. Every formula is your own thought made explicit. The spreadsheet never surprises you with a “better” formula it invented; it only executes what your [*techne*](https://plato.stanford.edu/entries/episteme-techne/ "https://plato.stanford.edu/entries/episteme-techne/") (practical skill) already enables.
+
+In every case the *telos* remains untouched: the human retains full mastery over causes, constraints, and judgment. [*Phronesis*](https://plato.stanford.edu/entries/aristotle-ethics/ "https://plato.stanford.edu/entries/aristotle-ethics/") (practical wisdom) is actually **strengthened** because the tool forces clearer articulation (“if this cell changes, what must that cell do?”). The craft expands in power and scale, but the kind of skill — deliberate, sequential, fully owned reasoning — stays identical. Hammer territory. The carpenter is still the same kind of carpenter, only faster and capable of larger structures.
+
+But in the case of an LLM, the tool is no longer an extension of your reasoning; it is a *statistical simulation of* *reasoning itself*. It does not just *compute* — it generates the next step, the architecture, the test suite, the explanation, sometimes even the problem statement.
+
+With a calculator or spreadsheet we have to type the formulas ourselves; the act of typing would require at least minimal causal thought. Claude encourages us to bypass that entirely. The model produced a fluent artefact whose internal logic we never have to own. The skill required has shifted from “*model the system in your head and express it mathematically*” to “*prompt effectively, triage obvious junk, and make sure the black box produces the right outcomes.*”
+
+The older tools left the engineer’s [*hexis*](https://iep.utm.edu/aristotle-ethics/ "https://iep.utm.edu/aristotle-ethics/") (disposition) intact and deepened it. The LLM invites a new *hexis*: fluency in orchestration, comfort with probabilistic correctness, and delegation of causal responsibility. That is not “more of the same, only faster.” It is a new craft whose [*telos*](https://plato.stanford.edu/entries/aristotle-causality/ "https://plato.stanford.edu/entries/aristotle-causality/") can quietly drift toward “*whatever the model can ship before the next stand-up*” rather than “*systems whose causes I can defend in a crisis.*”
+
+Aristotle’s test is definitive: a true tool for the craftsman must *serve the existing telos* and enhance *the virtues required to achieve it*. The hammer and slide-rule pass. The sabre saw is borderline. The LLM crosses the line into a device that can substitute for the craftsman’s core activity. It is closer to giving the carpenter a robot arm that decides where to cut than to giving him a better saw.
+
+## The Bottom Line
+
+To be clear, LLMs are not an *inherently* bad things. However, they are tools that are much more dangerous than anything we’ve ever used before. It is possible to make use of Claude in the slide-rule sense, but the seductive impulse to treat Claude like a substitute for genuine cognitive effort, will only *at best* make you better at a *different kind of craft* whose name we may eventually have to change – and at worst, make you a slave to your own tools.
+
+Still, even if we stipulate that an LLM is a tool in the sense that a calculator is, tools do not *inherently* confer *phronesis*. It is something that can only be gained by continuous practice *of the right activities*, *in the right way, under the right circumstances*. It is **sovereignty over the causes** plus **sound judgment in irreducible uncertainty**. The LLM can supercharge our *techne*; only we ourselves can grow in *phronesis*, through praxis and study. When both rise together, we can indeed become “better” engineers. That is the only definition of “better” that survives Aristotle’s standard.
diff --git a/assets/agile-manifesto-highest-priority.png b/assets/agile-manifesto-highest-priority.png
new file mode 100644
index 0000000..982a092
Binary files /dev/null and b/assets/agile-manifesto-highest-priority.png differ
diff --git a/assets/agile-manifesto-main.png b/assets/agile-manifesto-main.png
new file mode 100644
index 0000000..a190fa0
Binary files /dev/null and b/assets/agile-manifesto-main.png differ
diff --git a/assets/clipart/clipart-atomic.png b/assets/clipart/clipart-atomic.png
new file mode 100644
index 0000000..ba14b22
Binary files /dev/null and b/assets/clipart/clipart-atomic.png differ
diff --git a/assets/clipart/clipart-clipboard.png b/assets/clipart/clipart-clipboard.png
new file mode 100644
index 0000000..7fcf22e
Binary files /dev/null and b/assets/clipart/clipart-clipboard.png differ
diff --git a/assets/clipart/clipart-desk-worker.jpeg b/assets/clipart/clipart-desk-worker.jpeg
new file mode 100644
index 0000000..a4ff2fe
Binary files /dev/null and b/assets/clipart/clipart-desk-worker.jpeg differ
diff --git a/assets/clipart/clipart-gears.png b/assets/clipart/clipart-gears.png
new file mode 100644
index 0000000..d4d7222
Binary files /dev/null and b/assets/clipart/clipart-gears.png differ
diff --git a/assets/clipart/clipart-inspector.png b/assets/clipart/clipart-inspector.png
new file mode 100644
index 0000000..69f4bcf
Binary files /dev/null and b/assets/clipart/clipart-inspector.png differ
diff --git a/assets/clipart/clipart-microscope.png b/assets/clipart/clipart-microscope.png
new file mode 100644
index 0000000..a322f4a
Binary files /dev/null and b/assets/clipart/clipart-microscope.png differ
diff --git a/assets/clipart/clipart-people.png b/assets/clipart/clipart-people.png
new file mode 100644
index 0000000..fa3e12e
Binary files /dev/null and b/assets/clipart/clipart-people.png differ
diff --git a/assets/goofus-and-gallant.jpeg b/assets/goofus-and-gallant.jpeg
new file mode 100644
index 0000000..ede5f3e
Binary files /dev/null and b/assets/goofus-and-gallant.jpeg differ
diff --git a/assets/graph-spurious-correlation.png b/assets/graph-spurious-correlation.png
new file mode 100644
index 0000000..812de6f
Binary files /dev/null and b/assets/graph-spurious-correlation.png differ
diff --git a/assets/memes/meme-amazing-stories.png b/assets/memes/meme-amazing-stories.png
new file mode 100644
index 0000000..59ff929
Binary files /dev/null and b/assets/memes/meme-amazing-stories.png differ
diff --git a/assets/memes/meme-bear-poking.png b/assets/memes/meme-bear-poking.png
new file mode 100644
index 0000000..a4763ca
Binary files /dev/null and b/assets/memes/meme-bear-poking.png differ
diff --git a/assets/memes/meme-dev-vs-qa.png b/assets/memes/meme-dev-vs-qa.png
new file mode 100644
index 0000000..8700aee
Binary files /dev/null and b/assets/memes/meme-dev-vs-qa.png differ
diff --git a/assets/memes/meme-figuring-it-out.png b/assets/memes/meme-figuring-it-out.png
new file mode 100644
index 0000000..ec2ee17
Binary files /dev/null and b/assets/memes/meme-figuring-it-out.png differ
diff --git a/assets/memes/meme-tucker.png b/assets/memes/meme-tucker.png
new file mode 100644
index 0000000..9223c13
Binary files /dev/null and b/assets/memes/meme-tucker.png differ
diff --git a/assets/memes/meme-very-bad-man.gif b/assets/memes/meme-very-bad-man.gif
new file mode 100644
index 0000000..841a993
Binary files /dev/null and b/assets/memes/meme-very-bad-man.gif differ
diff --git a/assets/site-supervisor.jpeg b/assets/site-supervisor.jpeg
new file mode 100644
index 0000000..1ae2447
Binary files /dev/null and b/assets/site-supervisor.jpeg differ
diff --git a/assets/very-bad-gherkin.png b/assets/very-bad-gherkin.png
new file mode 100644
index 0000000..ac4706a
Binary files /dev/null and b/assets/very-bad-gherkin.png differ