<![CDATA[True Test Tech]]>https://www.truetesttech.comhttps://substackcdn.com/image/fetch/$s_!lAQu!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd3488521-0417-447d-9b38-cbcf7aac1b4e_1024x1024.pngTrue Test Techhttps://www.truetesttech.comSubstackSat, 09 May 2026 11:14:18 GMT<![CDATA[How brewing beer reinforced my thoughts on testing.]]>https://www.truetesttech.com/p/how-brewing-beer-reinforced-my-thoughtshttps://www.truetesttech.com/p/how-brewing-beer-reinforced-my-thoughtsTue, 30 Apr 2024 01:20:46 GMTOver the weekend I decided to try my hand at brewing beer. For those who know me, I have a chronic case of curiosity. Here’s what usually happens. I see something interesting and my brain starts to ask, “I wonder how that works?”, and before you know it, I’m down a rabbit hole. Well, this is no different. I was recently on vacation and visited several distilleries, where I started to wonder how the distilling process works. Once I got back home, my curiosity overcame me and I bought a kit to start home brewing. What’s interesting is how something unrelated that we are learning can show us perspective in the process.

What I enjoyed was the checklist of all the things I needed to do. I unpacked the box of bottles, carbonated drops, yeast, and extract. Step one, clean EVERYTHING. When I say everything, it says to clean EVERYTHING! I understand that cleaning would be the first step, but I was surprised at how far it told me to take it. The instructions even had me put the can opener for the extract into the cleaning solution.

As I thought about it, I started to think about what wisdom could I gain from making beer.

Just as I needed to put my environment into a clean and sterile state, testing software is similar. Brewing beer can quickly be ruined by tiny microorganisms that are invisible to the eye. It will warp and tarnish the beer as extra bacteria or dust come in contact with the yeast and sugars. When software is not in a clean and known state, you can’t trust the outcome of your tests. Often in the past, I’ve had a test fail due to bad data in an environment, or sometimes the previous test didn’t properly clean up after itself. There are any number of potential risks that can cause your test to be unreliable such as someone accidentally dropping a table in QA, which unfortunately is a true story.

Each test that you perform, whether it is manual or automated, should start from a place where everything is clean. Where there’s no leftover data, no drivers hanging around, just clean and sterile. If we have a CREATE operation, we will attempt to create a DELETE operation at the same time. While the delete operation is not yet needed for the business, the added value for cleaning up the tests has been amazing and I would highly recommend it.

As you test and bring the risk assessment to your organization, think of ways to make the tests more reliable. Start by putting the application under test into a known state and leaving the environment cleaner than you found it.

Thanks for reading True Test Tech! Subscribe for free to receive new posts and support my work.

Additional Reading:

https://www.homebrewersassociation.org/how-to-brew/brewing-best-beer-malt-extract/

Thank you for reading True Test Tech. This post is public so feel free to share it.

Share

]]><![CDATA[What is fast anyway?]]>https://www.truetesttech.com/p/bowing-at-the-altar-of-fasthttps://www.truetesttech.com/p/bowing-at-the-altar-of-fastSat, 27 Apr 2024 20:01:43 GMTI’ve been internally wrestling with the concept of what fast means in software, and came across this little gem about Speed Is the Consequence. Not the Goal.

Software is an interesting subject because while it is built on hard sciences such as mathematics, it’s soft and malleable like thoughts. Software isn’t concrete like a building or a road, it’s something purely mental held together by 1’s and 0’s. Something in the physical world is done once it’s built, but software isn’t like that.

I’ve heard terms like we need to move faster or we aren’t shipping code fast enough. If you don’t hear it, some teams feel it. There’s also a parallelization of how building software is the same thing as Toyota’s factory and how it makes cars.

Sometimes we have to read between the lines and maybe this is what they mean.

  1. We need to find ways to provide value to our paying customers if we want them to come back.

  2. We don’t have product market fit - start throwing spaghetti at the wall and we’ll do what sticks.

  3. Our competitors have an advantage and we are losing market share.

  4. Go make me more money!

  5. We need to stop deploying production code from our laptops.

If you’re in the boat of the poor souls who have to deploy code from their laptops, there is room for improvement, but I’m not talking about that.

I believe in moving fast with small incremental improvements whether it is technical or organizational. This was popularized in the book “Atomic Habits” by James Clear, and further shown to work by the British Cycling Team referenced in Chapter One.

The more I think about it, the more I believe that to move fast most of the changes of a mature company need to happen at an organizational level, not a technical level. Here are the two that first come to mind.

  1. Organizational Structure might need to change.
    ”Conway's law     describes the link between the communication structure of organizations and the systems they design. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967.” If your software
    is hard to read, feels like siloed black boxes, and you keep thinking that the code you are reading is unnecessarily complex. It could be how the organization communicates and a reorg is necessary.

  2. Makers are on Manager’s time.

    There are Makers and Managers and the way their day is built is completely different. The Manager's schedule is usually blocked out in thirty to sixty-minute increments and each context is similar. The maker schedule needs large blocks of time to solve complex problems. When writing code, even loading context can take up to 30 minutes.

While we might tend to want a tool, framework, or language to solve our tech problems, I wouldn’t start there. As teams and companies look to optimize their work, they should find places to make room for more organizational changes that reflect the desired reality.

Thanks for reading True Test Tech! Subscribe for free to receive new posts and support my work.

Additional Reading

https://qeunit.com/blog/speed-is-the-consequence-not-the-goal/

https://www.satisfice.com/blog/archives/856

https://paulgraham.com/makersschedule.html

https://en.wikipedia.org/wiki/Metacognition

Thank you for reading True Test Tech. This post is public so feel free to share it.

Share

]]><![CDATA[Readability Verses Intention]]>https://www.truetesttech.com/p/readability-verses-intentionhttps://www.truetesttech.com/p/readability-verses-intentionSat, 27 Apr 2024 13:40:28 GMTI often hear the phrase, “Make your code readable.” This phrase is thrown around a lot, but the more I started pairing with other engineers, I realized there’s a gap in communication with these words. The amusing thing about an arrangement of letters is that we can say the same sentence and mean very different things or say words in an almost incoherent way by the way we arrange them. Here’s an example of a sentence in the English language that shows how absurd this can get. “Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo”.

I believe that we as engineers have to start using better words to convey what we mean and intention is one word I would propose as an alternative. Merriam-Webster defines intention as “what one intends to do or bring about”, and that is exactly what our code should do. If you try to push your code to a state where any engineer can understand your intent without talking with you directly you have explicitly made your code more readable. Let’s look at the code example below.

let orientationView = app.frame.size

if orientationView.width > orientation.height {XCUITDevice.shared.orientation = .portrait}

This code is technically readable. We want to check if the width is greater than the height and then assign something as a portrait if it is. While this is a great first draft, we still don’t know what the author’s original intent was. Not only that, we have to pull our minds into a lower-level context and load the implementation details. This was a great stopping point for me to ask more questions as we paired and asked about intent. As he started to explain his intent he was able to distill it into just a few words he said “I want to put the application under test into portrait mode before I start my test”. It was a great moment to put those exact words into code. Here’s what we did to pull those concepts up to a higher level and show intent.

if landscapeOrientation(){  
  changeToPortrait()
}

Now we have done several things with this small refactor.

  1. Hidden the implementation details.

  2. Shown the intent of the author.

  3. Created an easy-to-test function.

As you go about your day making code more readable think about how you intend your code to be interpreted. Others and your future self will thank you.

Thanks for reading True Test Tech! Subscribe for free to receive new posts and support my work.

Additional Reading

https://testing.googleblog.com/2024/04/isbooleantoolongandcomplex.html

Thank you for reading True Test Tech. This post is public so feel free to share it.

Share

]]>