Public notetaking, a 12 year sample

When I started this blog, I called it Seasoned Tester's Crystal Ball and wrote down the tag line that has remained unchanged since:

This blog is about thinking of things past, present and future in testing. As much as I'd like to see clearly, my crystal ball is quite dim. Learning is essential and this is my tool for that.

I did not foresee that a blog since 2010, 12 years of public notetaking on twitter 2010 - 2022, and four years of public notetaking on mastodon 2022 - 2026 would realize the vision of being a tool for my own learning. I imagined reading back to what I thought in the past, laughing about how naive I had been, and how little I knew even if I was already seasoned 16 years ago.

I did not foresee when I started this that I could spend a Friday evening, AI-assisted, finding things I have said on twitter worth quoting even now when all that material is deleted but archived in internet archive (please donate to it, they do such great work) because I set up for it before I deleted data from what used to be Twitter's servers - at least, that is the theory.

What I set up today is what people call a second brain, basically a structure of routines that pull together your sources of notes to a structure in an Obsidian multi-vault structure with LLM wikis, allowing my AI harness access to all this public information that I had already classified systematically, giving me thematical learning opportunities on things I might benefit from for me, but not pay attention to.

So when I pull out of this material, it's not generated text. It is my text. 16 years of my text, and 12 years of my text on twitter. So I wanted to share what I pulled out on my 12 years on exploratory testing.

As per this blog, it is as much public notetaking as any. I hope google's interests to have my texts around stay (blogger). I hope Microsoft's interests to have my texts around stay (github). And I hope internet archive stays when the corporations don't. What I wrote is my legacy, and I have been planning for maintaining that digital legacy for some time now with choices I make. Robots and some people have hit this blog 2 040 234 times, so my small contribution to the teaching ideas for AI without risking a copyright violation counteraction as I share with CC-BY license making my intent of use what you can clear.

The 12 year sample of me quoting me

These things are a condenced, thematic digest where selection is delegated while the source remains me. It's drawn from my personal Twitter archive covering 2010-2022. As it emerges, I spoke particularly to 11 themes:

1. What Exploratory Testing Is (core concepts — mindset, learning, agency)
2. ET vs. Scripted Testing (test cases as output, not input)
3. ET and Automation ("contemporary exploratory testing," the automationist's gambit)
4. History and Attribution (your research into Cem Kaner, Elfriede Dustin, the 1984/1988/1999 dates)
5. Defending the Term (pushback on deprecation and "ad hoc" framing)
6. Teaching, Courses, Mob/Ensemble Testing, and the Book
7. Community and Peer Conferences (ET Dinners, DEWT, ET19)
8. Managing Exploratory Testing (charters vs. sessions, agency)
9. Developers and Exploratory Unit Testing
10. Personal Journey and Career (2010 → 2022 arc)
11. Craft Notes (bugs, serendipity, real sessions)

This topic was 1304 tweets out of 33551, and I have yet to dig into what else did I talk about as I felt I was always on this topic.

1. What Exploratory Testing Is

Not a technique or a phase — a mindset built on learning, agency, and opportunity cost, whether or not you touch a keyboard, script, or piece of automation.

• "Exploratory testing is more of a mindset emphasizing that you need to learn continuously. Every day a little better. Love my work."
• "Agile testing is the idea that developers can test, and that testers can contribute before development. Exploratory testing is the idea that testing is skilled activity."
• "This testing the verb vs testing the noun is very useful. Been thinking for last few hours how ‘all testing is exploratory’ is true for the verb but not the noun."
• "Exploratory Testing makes many uncomfortable because it requires decision-making. You are responsible for results and you decide how you get to those results. You decide, you are wrong (or right), and you learn."
• "Bugs, by definition, are behaviours we did not expect. What sets Exploratory Testing apart from the non-exploratory is that our reference of expectation is not an artifact but human imagination supported by external imagination of the application and any and all artefacts."

2. Exploratory vs. Scripted Testing

Test cases are a valid output of exploratory testing — never a valid input.

• "Scripted vs. exploratory continuum just doesn't clarify it for me. I often create the script after I've explored. Hands-on with sw first."
• "If test cases are input to your testing, it's most likely not Exploratory Testing. With Exploratory Testing, test cases (and documentation in general) is output."
• "As an exploratory tester, there is one thing I create 'test cases' for - bug reports. That's when writing step by step repro instructions may make sense (if I can't avoid it, and I often can)."

3. Exploratory Testing and Automation

From around 2018 on, the central thread: rejecting the manual/automated split, reframing automation as something built through exploring — leading to 'contemporary exploratory testing' and the 'automationist's gambit'.

• "What's with the idea that I need automation to free my time for exploratory testing? Assumes devs can't do decent quality without automation"
• "The new tools ‘automating exploratory testing’ are to that goal what IDEs are to ‘automating programming’. And that’s helpful. I love an IDE with great refactoring support. It makes coding more joyful. But we rarely say ‘automated refactoring’."
• "I woke up realizing this is a perfect way to describe what I do with Exploratory Testing. I have the automationist's gambit to it. Like with queen's gambit in chess, this has attacking prowess and has requirements for opponent to defend properly. Inspired. Thank you Chris."
• "Exploratory Testing is the pink. It keeps everything else in shape, and fills all the gaps."
• "Comfort in my peers also thinking that the "exploratory testing cloud on top of testing pyramid" and "let's slap some exploratory testing after everything else is done" are ridiculous notions. You can't automate well without exploring. You can't explore well without automating."

4. History and Attribution

Amateur historical research into where the term actually came from, and pushback on narratives crediting it to one person.

• "Brief history of Exploratory Testing. Introduced by Cem Kaner in '80s to describe smart way real companies were doing testing that was different as it avoided separating test design and test execution, maintaining tester agency and learning."
• "1988 'Testing Computer Software'. Cem Kaner. We have added more understanding to the concept of Exploratory Testing since it was coined in 1984."
• "I know from personal conversations with a now-retired head of testing at Social Insurance Institution (KELA) that they were doing Exploratory Testing before Cem Kaner coined the term. Reading about their early computer work in HS today (in Finnish)."
• "Way too many people ask me to credit James for "exploratory testing". Like the concept somehow belonged to him. Newsflash: I was doing it before I learned James exists. I found out about James existence researching ET at university."

5. Defending the Term

Pushback on attempts to retire, rename, or diminish 'exploratory testing' as vague, unskilled, or synonymous with 'ad hoc'.

• "I have spent 25 years of my career exploratory testing, a concept that is 34 years old. Saying I should stop being what I am because there was a jerk using the word... Does not leave you with many words."
• "Service announcement. We have not retired Exploratory Testing. We are rediscovering it. Love the stuff from Anne-Marie Charrett, James Lyndsay, Alexandra Schladebeck and Simon Tomes just to mention a few are doing on it."
• "There is a reason why people conflate exploratory testing with ad hoc / monkey / no discipline — their colleagues hide the discipline or lack the discipline. Mystifying it is hurting us all."

6. Teaching, Courses, and the Book

A teaching practice and a self-published book, plus popularizing 'mob testing' as a way to teach exploratory testing experientially.

• "It’s started: Exploratory Testing Book in now in progress and first increment is on LeanPub"
• "I enjoy the two day classes on Exploratory Testing as we learn to work together and go much deeper on testing and the application."
• "This week I taught a course on hands-on Exploratory Testing. Still reflecting on what I learned from it myself. The first major learnings bubbling up are about what to call the course. I could call same contents "Test Case Design" or "Agile Testing", more people would find it."
• "I'm doing a complete 2022 rewrite of my book on Exploratory Testing and the old version will be replaced with increment of the new already today."

7. Community and Peer Conferences

In-person exploratory testing communities in Finland ('Exploratory Testing Dinners'), later international peer conferences.

• "Great discussion at Exploratory Testing Dinner yesterday. Addressed reporting (again), cultural differences and bug reporting this time."
• "We'll organize a peer conference for European teachers of exploratory testing to learn from each other. Netherlands or UK? #DEWT5"
• "#ET19 has a nice mix of people who have taught Exploratory Testing to thousands and those who practice it. I’m hoping to rediscover it as the ‘smart testing not everyone was doing at the time’ it was used for 35 years ago."

8. Managing Exploratory Testing

Against treating session-based test management as the only, or best, way to manage exploratory work — agency is the real lever.

• "It would be just as bad to create / fix all charters for exploratory testing beforehand. Unadaptive planning."
• "Exploratory Testing isn't this thing where you create big test cases and call them charters. If you think you can create charters and pass them around in your team, you are learning on a short leash that limits you."
• "One of the most common ways of managing Exploratory Testing is 'stealth'. We hide it and focus on what the organization expects. I'm seeking for ways to stop hiding it, because it is what makes our testing worth doing and our test automation worth having."
• "Agency is at the core of Exploratory Testing."

9. Developers and Exploratory Unit Testing

Exploratory testing happening at the unit-test and code level, not just at the UI.

• "I’m lucky to work with devs who are just as good exploratory testers as most of the testers. The ‘focus makes me better’ myth of testers that died with continuous delivery."
• "What does it look like when developers do Exploratory Testing? A lot of times it looks like they make better unit tests. They go about and learn about their application also in integrated context (and don't make excuses in it not being their job), but lessons turn to unit tests."
• "I'm taking a moment to dig into exploratory unit testing. Yep, that is a thing. That tends to be how some of my favourite TDD folks get to good levels of quality, raising the bar on their intent and closing the results gap."

10. Personal Journey and Career

A 25+ year career arc, from an early job where a team lead handed her Cem Kaner's book, through introducing exploratory testing to skeptical organizations, to pushing back on being boxed in as an 'exploratory testing guru'.

• "If one get paid more for "planning" testing = documenting than testing, exploratory testing may have difficulties."
• "Changed from product business to pension insurance to show exploratory testing is possible there. Made significant progress today."
• "I've identified as a context-driven tester for a really long time, and I am now coming to terms with not being that any more. I choose places of work that allow for smart testing ('contemporary exploratory testing') and do transformations to it."
• "I was in someone's job interview today and they boxed me as "exploratory testing guru". While it is great to be guru, they were completely out of touch with my work on contemporary exploratory testing and I'm off the box."

11. Craft Notes: Bugs, Serendipity, Real Sessions

Texture from the practice itself.

• "The bug treasure troves for exploratory testing practice: airline pages. I wonder if they’d like to know of all the bugs they have."
• "I'll share you my favorite Albert Einstein quote: "It's not that I'm so smart, I just stay with the problems longer". I've connected that idea with good exploratory testing for years."
• "Three hours of Exploratory Testing with three different constraints on the same application. One produced 7 cases in test automation, 2 bugs. One produced hundreds of unstructured test ideas, tens of bugs. One produced a mindmap, 4 bugs. All but one of the bugs were different."

Breaking what you thought you knew about testing in 30 minutes

I am passively recruiting, meaning I look for the people that think of testing differently. This creates an interesting frame for the conversations I have.

The first point of entry is the willingness to explore a mutual future together, and I don't do that by reading your CV. I do that by having a conversation. In that conversation, I am not testing for the right answers, I am searching for boundaries of identity, potential and true willingness for a mutual journey.

Many people with 20 years of testing experience come out of that 30 minutes smiling, curious, but also with breaking what they thought they knew about testing. You need to break things to build them up in a different structure.

What I start with is asking people what they see in their future with testing role, grounded to what they have learned in the past. Not reiterating what their CV would say, but talking about what would be a mutually happy and valuable route forward in their mind.

I often hear things like this:

• modernization to automation
• technical automation architecture leadership
• transformations, delivery management
• good practices and processes

Essentially, these are about power over telling people what to do. I tend to call them out as abstract, and push the next stage to testing of a tiny application. After all, if you plan on telling others how, having good ideas about that how is kind of essential.

I flash our e-primer, now within the Capture the Bugs feedback application. I tell them I want to know what they want to know, and that I want them to test this application. And then we iterate.

The iteration can take us anywhere:

• a lot of people make claims like they see a bug when they don't, and struggle to explain what lead them to a conclusion
• too many people want to try text field with numbers and special characters, without any connection to the domain
• a lot of people don't know how to learn a domain when they don't yet know what they don't know
• sometimes we discuss the risk of long text, the boundaries and the architecture's impact to relevance of information you could find if you go big

There are things that I always bring in:

• test automation that enables us to test things we couldn't easily by hand if only we had better ideas
• using AI not to generate test cases but to generate the bug lists - the result we are trying to achieve here

For people with traditional testing experiences and idea of exploratory testing as random clicking, the level of intent, learning and sensemaking I require feels surprising. They see that indeed the thing I ask as testing is nothing like the testing they have 20 years of experience with.

Failing with the exercise is the beginning. The possible journey together builds on what you do with having been shown there is something else, and concluding that what I was asking for was not that unreasonable - especially since AI of today can deliver 32/65 problems known in that application with three prompts: "Test this" (finds 4), "Do better" (finds 29), "I know 65, can't you do better" (finds 32). Elizabeth Hendrickson was half joking when she said yesterday in conversation after her talk that asking AI to explore does not need a separate skill, her book "Explore it" is part of a law suit with illegal use of copyrighted materials as training data. She already taught it with best of what she got.

On realizing the change we need in the field to move to think about testing differently and finally letting go of that test case obsession, another framing I really liked came from a group discussion with Lisa Crispin. The group at large was not happy with the book title "Taking testing - seriously?", and from a light rant lead to a true insight channeled through Lisa:

If we took software development seriously, that would already include quality. Creating that separation isn't helping us learn.

We have a real challenge when AI already today does better than many of our testers. And I am recruiting people who can help me change that, with ideas of what making that change while making it solid business entails.

I found one and she started a month ago. I found one more, and I'm building up the right runway for learning together. And I am looking for more people who I can drop into the frame. They need to have ideas of how things are different in collaborative software development that we take seriously. They need to figure out sociotechnical systems, virtuous and vicious loops, and make impact with feedback.

Every conversation, whether it was a crossing of paths or aligning them is worth the time. Taking up the invite is a prerequisite for some potentially good learning.

Comparing Blue, Yellow, Red, Pink and Purple - How are they Different

As a tester, I have grown a practiced skill of classification. There are a lot of emergent criteria to classify, and with practice, I have added slices of perspectives that allow me to see things. Seeing what is said, I look for things that aren't said. And looking at testing tools, I look for options and differences.

And right now, AI for testing tools are overwhelming in options. With AI, everyone has a tool and discovery of value is harder than ever. I wanted to take a pick at calling out some of the patterns I might be seeing.

The Marketing Layer

Imagine there is a small tech company somewhere far away, and you are a business minded person setting up a product company some 30 years ago. You make a deal of taking their promising tech, and you add a facade layer, product name, a slidedeck and your access to people they didn't have access to. You take Blue (with a contract), you call it Yellow. Over the years you add things to Yellow, and eventually you remove Blue from your Yellow. A valid way of building a product business.

Imagine there are open source tools, and you are a technically savvy person who sees value on grouping them some 30 years ago. Each small piece is available with a license that allows for redistributing with constraints, but they aren't thematically packaged together. You take Red and Pink, and you call it Purple. Over the years, the thematic packing grows stronger in value, you add things that fits to Purple. Purple becames known, and majority of people don't even know there are Red and Pink inside.

Adding that marketing layer is today easier than it was some 30 years ago. And since it is easier, it's done in scale making understanding all the Yellows and Purples and Rainbows hard. Creating products with AI support changed the game.

Control over Long Term Value

Imagine a Finnish public sector company posting out a RFP for products in Accessibility Auditing and Monitoring. And ending up with both Blue and Yellow on their list. If Blue decides they can no longer build and maintain due to lack of financial resources, there is no Yellow. Paying for Yellow when the value is generated into both Yellow and Blue by Blue means you may end up eventially with a facade. Liking the facade of Yellow but needing the value of Blue is a real choice when making the purchase decision.

Architecture-awareness is not optional. For the Purples of the world, in worst case scenario, open source allows for Purple to maintain Pink2, when Pink actually is no longer around. For Yellows of the world, closed source is protected by win-win financial incentives.

If you are used to connecting things in world of accessibility Deque aXe is the Blue. There are a lot of tools that add little the what they make available as open source.

Architecture-aware

We look at a testing tool, and they have all these features. And they all have AI in them, a lot with the promise that you can use your already approved models* meaning the cost of what really is AI is outside the box they are selling. Their product does nothing without buying the other product. So how do we choose when comparing them all is not feasible, and architecture-awareness is needed for any comparisons of relevance beyond "I like this person and want to give them my attention, maybe even some of money".

Repeating this over and over again in being presented tools, I build and grow a classification frame, that allows me to get tool folks to tell me less marketing speak:

What we've built, I'd kept selling the "unique layer" angle, you'd have been right to call it blue-with-files-on-the-side.

Let's briefly touch these perspectives of classification for AI in testing -conversations.

First, I look for where the value add they invest in is:

• Packaging is when they have facade level value and tell their story uniquely
• Surface is when they provide value by having their own user interface they expect you to interact in
• Files is when they drop you things that make AI better for specific slice of work
• Harness is when you have a loop (agent) and some of their own built-in instructions akin to files to drop
• Model is the engine that does the work.

Second, I look at the time perspective of value:

• Constraints are the things that must be true (ideas about data most prominently) for any of the value to be available
• Lifecycle is the idea of what stays around when you no longer pay them money

A lot of the tools are like gym membership. Going to gym is required. And if you no longer pay, anything you built on is no longer available.

Third, I look for their idea of testing

• Task expansion is the idea that in age of AI, I don't want testing that reports bugs. I want testing that fixes the bugs. I don't want dedicated testers providing the service, I want to level up everyone in the teams.

My Yellow, my Choices

I would be hypocritical not calling out that I got my Yellow too. My Yellow is called, for now, CGI Test Intelligence Mesh, and it's files we drop in a particularly consumable way with a change of license mechanism.

If prompt engineering is an individual skill of how to talk to AI, context engineering is how your team and project talks to AI. And in my case, how your team brings in external influences impactfully.

The choices I make come from the belief that we need to distribute the control over long term value.

Capture the Bugs - Feedback on learning how to test

You may have run into a popular learning tool in the security space, Capture the flag. These are essentially instrumented unsecure applications, where as you test, you get score for insighs and hints on what else could you try out as attack vectors.

Functional testing includes security testing, but in addition includes a whole lot of perspectives that may not have security implications. With that in mind, I paired with Ru Cindrea to co-create self-service version on a learning style I have used in classroom settings for decade(s) - learning testing by testing, and getting feedback founded on someone else going before you.

In this post, I want to provide you a link and current state description on work that will evolve further but would already be useful for your self-study, and talk about the background leading up to this.

Capture the Bug Current State

You can find the application at https://exploratory-testing-academy.github.io/capture-the-bugs/.

It now supports two features for one test target, e-primer:

1. input coverage - you can't find problems if you can't imagine things to try out in an application. If this feels hard to do, we also included a mode where it tells you classes, or even examples.
2. results coverage - you can list things you found, and it tries to compare them with in-browser AI model to a list of 65 known bugs. It tells you what bugs we know of when you think you're done.

I should change the UI to say "We expect you to try 35 kinds of input and report 65 issues we know of. Traditional professional testers find 18% of bugs on other comparable test targets, and learning testing (and using AI) raises the measured bar."

That is it. Test without the answer key, without us watching you test for now. We'll eventually add a choice of reporting your results to you, but it's not there now. You get feedback on input and results coverage. For input coverage, you can choose to update the level of guidance it provides you - from usual testing with your sources of imagination, to seeing classes we had in mind without the specific examples, to specific examples to make sense of how inputs are different. Results are evaluated after you call done, with an in-browser AI component trying to match your style of reporting to our style of baselining expectations.

We would love if you reached out in socials if you try this out, or if this style of learning is interesting to you. Maaret prefers DMs in linkedin or mastodon.

Backstory

Capture the bugs is really a step forward in a decade(s) long teaching of exploratory testing, learning to test by testing. Different test targets require different techniques, and this particular test target is heavy on inputs, while it has a lot of non-input related issues you could raise too. When hundreds of testers have tested this with me in job interviews, online pairing sessions and classrooms, I have built both an answer key to what is expected, and a course to teach you the theory around testing an application such as this. Course is available at https://qe-at-cgi-fi.github.io/material-portal/cetf/index.html for its latest edition.

While being aware of 65 issues on this application worth starting a conversation on, I've been doing benchmarking with other applications. For todo app, the discovery has been that people professionally paid to do testing, being put under the open schedule and required to test and report, find as little as 18% of bugs. This benchmarking has been both a motivation for working towards better, more accessible testing education on resultful testing where you decide actively on acceptable risks, rather than miss out on conversations you could be leading. The very same benchmark has been a sad realization on the testers at large on not delivering on our value proposition on being allowed to focus on quality.

At my 30th year on testing, I am even more focused on scale and legacy, and transforming from someone who loves to do testing to someone who grows more people who love to do testing. Testing is a great profession, but it is not an easy one. It is endless learning, collecting stories of bugs of relevance while walking a minefield of intentionally left behind issues. There is great hope for its future with task expansion, and the idea that to report a bug with AI is to fix it and leave behind test automation that tracks our expectations.

Capturing some more of the learning, one piece of action at a time.

How can our employees find information faster?

For first day post-vacation, two things happened that inspired this post:
1. I took a tool vendor course "OpenAI PartnerU Foundational Knowledge, July 2027"
2. I spent over two hours trying to order a mobile phone for a colleague joining next week

This combination left me with a sense of insight worth blogging about, on failure demand.

In this age of AI (= everything is AI), one of the core questions I noted down for the course I took was the idea of moving from discussing AI to moving to discuss what we do and then considering right tools to enhance it. One of the questions they highlighed was:

How can our employees find information faster?

I had just spent two hours on something that should have been five minutes. I wanted to select a specific phone from a short list of preapproved phones, and order one. But alas, things don't go as I want them to go. There had to be a bug.

The bug was a lovely combination of a new security feature in Chrome / Edge (shared engine for the architecture-aware) and the application handoff implementation between ordering systems of two different companies. The sense of powerlessness with a production bug was overwhelming. Multiple options of who could do something about it, hard to find routes to any and all of them, and a task I was on a schedule for but unable to process. A model example of cost of quality beyond appraisal (testing).

This idea of cost of quality, follows from the idea that quality if free. Someone could have tested and FIXED a bit more so that I would have to struggle a lot less.

I tested for workarounds quite a bit.

• I searched our internal boards for other people with the same kinds of problems to see if they had experienced it, only to discover a plethora of other problems in the same flows but not this
• I updated Chrome, in hopes of it being due to some internal state of not having updated my browser
• I tried restarting the browser, private browsing and more permissive browser settings, none of which helped
• I installed Edge on Mac in hopes of it working on Edge when it did not work on Chrome

And finally, I asked Edge Copilot. The Microsoft AI chat. Read the links about when a few security feature might have been introduced, and took the second option for workaround proposed: I used Firefox, and everything was fine again.

Going back to the question than directed my thinking:

How can our employees find information faster?

I could have asked AI immediately instead of first struggling through the easy options. But really, I should not have been in need of this information. My goal should not be to find this information faster, but to not need this information. I had run into an example of failure demand.

Failure demand is this idea in quality, where lack of it creates work we then consider relevant. It has been one of the most powerful heuristics on my learning journey to realize that we want less, not more of testing. Accepting failure demand is a result of powerlessness in the system. And we need to see the system, not just the work we can contribute.

I leave you with this. Always be asking not just how we can do a thing, but what causes the need of doing that thing. Maybe with the very same investment amount elsewhere (let the devs test more!) our organizations delivery systems are better off.

And this bug - not an easy fix. All I did was adding to the body of knowledge in the internal boards with whoever comes after me.

Appropriate speed for the conditions, deliberately

In 2001, I was working at F-Secure, going through a wide scale agile transformation. I was facilitating testing (and releases) for a product where we first got to weekly releases on a millions of personal computers scale, and was pretty proud on learning the ideas about controlling the leash of change to make scope of testing manageable.

Being pretty proud was founded on the idea of being completely opposed to CI/CD when I first learned about it some years before it. I still send a proverbial wave to a particular Petri from Reactor whose face I see whenever I realize how many things I have had strong opinions, loosely held, and completely wrong.

At that time and age, with that particular CI/CD change, I remember learning some skills that are invaluable now when AI is the thing. I learned to be deliberate about how I use my our time.

Before this whole agile thing, test environments rarely worked. We had this gated model, like a countdown to release, from letting developers build components, and them having quality engineers work with teams to package changed components into products, and test those. You tested, and things didn't work. You waited a lot.

Whenever we were waiting, a group of us got together to discuss how we could improve things. Well, we also used time on rating dark chocolate, a pastime I could not directly enjoy due to being allergic to chocolate, but the atmosphere was relaxed and lovely. I made so many lists of experiences, ideas and cross-pollinated those things both within the organization and outside. And because we were learning so much, we improved a lot too. For years, F-Secure Quality Engineering was known as the source of all relevant testers in Finland.

With CI/CD, the waiting for environments quietly vanished. The natural breaks the environment-related handoffs created for us were gone. And we were more productive than ever. But also, we started stagnating on improvement. With the learning culture we had in place, we called it out, and adapted. We started taking deliberate time for fun; for learning; for cross-pollinating our ideas as a community.

I see people on socials discussing now the sense of overwhelm that AI gives us. And I remember that I learned this early on. You have agency. You can choose the appropriate speed for the conditions at hand, deliberately. Even when someone in the world uses the Ferrari run run full speed on German autobahns, youe appropriate speed is one that is healthy for yourself and your team. If you are learning to drive and your attention is on the gear change, go slow to see if people are crossing.

We have choices to make, and the power to make them. Don't be the person telling yourself otherwise.

Faking plans is easier than fighting plans

Ever entered a project as tester early on into a project? At that time when you still hold the illusion that plans are about to be set and you are on time? And then, only to find out that the only early enough is in the time the project manager gets trained on their ideas.

Well, it's a pretty deflating experience, and unfortunately all too common. It appears there is no early enough without a lot of friction to include testing.

The source of friction is in the mental model. Having Plan - Implement - Test - Release is such a simple illustration. But when you actually overlay testing, it's the other side of everything, and if you wanted real tasks and control over it rather than long-running categories in which you report hours into, you would actually need a more finegrained breakdown of the testing tasks.

Context for an inspiration

I worked on a fixed-price project, where the fixed-price was 50% of real price. These are typical in consulting world, and what they effectively mean is that the project environment is born passively hostile with a continuous fight on showing there is a change request lurking somewhere in the communication of two or more parties.

The fixed price estimation included no test planning, because why would anyone plan from testing perspective separate from project. And the whole plan of testing was described in usual abstract terms of unit, integration, end to end -testing and UAT.

I got to plan testing before the project plan, so I outlined the testing tasks:

• Identifying testing not promised within 8 hours effort allocation, when promise was unit, integration, e2e, UAT and what of it was change to promised scope.

• Deciding on quality practices: reviews, pipelines, timing of implement & test in mutually supportive ways

• Reviews of requirements spec, solution spec

• Testing while implementing, collaboratively, unit and integration testing

• Testing after implementing while integrated with a 3rd party system, minimalized, e2e testing

• Testing while integrated with a 3rd party system, necessary scope, but could be e2e or UAT and thus done from two different budgets

• Staying updated on learnings in the project

While planning for testing and reviewing the documents, I found a bug worth 25 000 € / annually, and facilitated a confirming conversation with the client, and patted myself on the back for planning testing early on to avoid expensive problems down the road.

If it only was that simple. Weeks later, I take a look at the project plan and none of the things I planned for testing got integrated. While appearance of a plan is not the plan underneath the surface, I find it both sad and funny that this is how we still insist on doing project planning. Not with a twist: they would not plan for things with people, or read the things from people, they would have AI in between all of that.

There is a special sense of middle finger that comes with "I did not bother reading the idea of key milestones you were communicating with an image, I rather sent your image to AI and here's a wall of text it had to say about it that made me completely miss the point, with a twist of false claims I have no capability of detecting".

I took my wins of finding the bug, and decided appearance of plan and the plan that will be executed can coexist, because faking it is easier than fighting it.

Lessons from the inspiration

As always, doing the work teaches you a lot.

1. Changing other persons mental model was more possible at time before AI. AI allows for not making an effort in building own mental model.

2. Actual collaboration would win over co-creating and handing off artifacts. Two hours together on a plan wins two hours separately on the very same plan. That removes also the AI workslop in between that is worse than before.

3. Change management politics on fixed price projects remain an antipattern caused by competition tactics.

4. Feeling detached from appearance of plans is necessary for survival. You know, that sphere of influence, the cost of applying influence for change greatly outweighs the cost of faking it.

5. The things that matter like access to version control tool to collaborate on in implementation or pipeline so that tests are not in head of someone don't need to make it into plan to make it into action.

6. Use of AI splits us to two: developers and knowledge workers, and I find myself increasingly frustrated with the hurdles the latter crowd creates in the handoff.