Writing a Book in 30 Evenings

As mentioned I have written a book. Looking through my notes I have around 30 versions, one for each significant session of working on it. I have been asked to share tips on writing a book, so here you go, Simon. The key lessons are:

  1. Set a Recurring Time and Space
  2. Unique Content – Reference the Rest
  3. Storyline and Flow
  4. The opposite of passive voice is not an aggressive voice
  5. LeanPub’bing

Set a Recurring Time and Space

One of my book’s themes was moving something from a hunch to a hard truth. And the same really applies here. When I finished my master’s degree while working (back in 2002), I had two slots a week at a “study office”. From that, I learned that not all study days are equally productive “on paper” – but that’s ok. Each session had its purpose.

Similarly for my book project. I set a weekly evening booking in my Calendar – family chores were arranged around it. After dinner, I work start working on the book and work for 2-2½ hours. I used my personal computer in my work-from-home setup.

Unique Content – Reference the Rest

There is so much great content out there already, my focus was on writing about my experience and my vision of better test strategies. But to do that I needed to stand on the shoulders of others to set the scene and describe the techniques I applied.

While writing I did want to bring in loads of existing content to elaborate and provide a foundation for my thinking. While editing I removed most of it, partly because I didn’t want to sound like a high school book report (thank you for that one Tristan). What I did leave in were quotes, recommendations, and listings of the work of others. The book is full of footnotes directly on the page (as compared to end notes) to highlight everyone in context.

Storyline and Flow

Initially, I outlined the chapters and subchapters and it was important to get the right “flow” and storyline into the content. My base model was inspired by “Situation, Complication, Question, Answer” from the guide “How to present to executives” (StaffEng Book) and similar lessons on taking the first steps.

  • This is the situation and challenges
  • These are the techniques, we can build on
  • These are the first steps, where the techniques are used

One thing I have worked a lot on is the flow of the text: Sections would be 4-6 lines long, with empty lines in between. I also worked to reduce “dangling lines”, so no two lines would linger into the next page. No pages should be text only, so quotes and illustrations are important for readability – as well as making the book content visible. Lastly, I worked a lot on having one section end with words that tap into the next section.

The below recommendation is cool, I could have done that too.

The opposite of passive voice is not an aggressive voice

Often I started my “book evening” by reading the book from the start all over again. As I’m not a native English writer, I installed Grammarly and paid for the premium version for a period to rewrite phrases that were in a passive form. Fun Fact: the opposite of passive voice, is not an aggressive voice but an active voice.

The tool you use to write your book isn’t that important. I used Google Docs with embedded Google Drawings, others might prefer Word or other editing platforms. The biggest challenge in publishing was getting the embedded pictures in a resolution that could be printed by the print shop. The book exists in a printed format – but it’s primarily an electronic book.

LeanPub’bing

Self-publishing on LeanPub is intuitive and easy, it also has tools for incremental versions, previews, and updates. Let people sign up for it in advance with price suggestions. That allows you to set a price on the book based on audience-based quotes.

They also have a great system for coupons. I have coupons for those that helped in preparing the book, those I have referenced, and those that participated in the virtual launch. Let me know with the phrase “LeanPubbing” if you want a coupon too.

A Story About Lifting People Up

This article is a parable, it’s not a traditional testing post. But as with all parables, this is a story to reflect on. It comes with all the best and noble intentions. [TW: semi-religious content].

There once was this person named Zach. Well, the name is really not so important. It could have been Dilek, Kim, Brie, or Latoya. Zach’s job was to collect fees among the community members – a service job for the benefit of the community. It could, as well, have been removing spam, sorting, and organizing content. And onboarding new people to the community. Menial work, which could be a hassle to the others – yet important for the community to run.

Reflection: What glue work gets taken for granted where you are?

But, there is no doubt Zach had cut some corners along the way. After all, that’s just the way business was done sometimes, thought Zach. And because of that, the fancy people of the community ignored and dispised Zach even more.

To make matters worse, Zach was not as tall as the others. You could say, that Zach didn’t have the same attributes as many of the others. And that made Zach feel further diminished and small in the eyes of the community. And that probably added to Zach’s cheating. Nothing Zach did was ever really recognized.

Reflection: who is putting in an extra effort to be seen?

One day a superstar and thought leader was present in the community. Everyone in the community gathered around and engaged. There was a buzz going on and Zach wanted to be a part of it. But it was still a burden for Zach to engage. Zach had to make an extra-extra effort just to catch what was going on.

Suddenly the superstar called out: Hey Zach! I see you. I will come to join you where you are. And so he did. The superstar joined Zach, the menial fee collector. Zach pledged to be a better person and has been since. Zach is now sharing surplus energy with the others in the community and has made up for the wrongdoing previously done.

Reflection: Are you meeting people where they are? How can you lift people up that are not seen?

What About Expected Results?

TL;DR: We should know better than to require expected results in test case steps.

Welcome to 2022 – where old wisdom surfaces yet again. Recently I considered expected results in test cases. It seems the topic is still relevant – I wrote about it in “The Expected” back in 2015.

As always we have to backup a bit and consider: What purpose does the detailed steps have to our stakeholders. How visible is the value provided? We have to start from their viewpoint – not build a chain of reasoning up from our own wishful thinking.

Currently I’m working on a project for payments of benefits. We have daily CI/CD and loads of classic manual testing. The key message from the stakeholders is that they expect things to be tested and evaluated. They generally trust us and collaborate with us on the work, so there is not so much discussion on the details as in other projects. Yet the discussion of expected results did come up in our internal dialog: What is the reasoning behind expected results on the test case steps – besides coming from an old book.

Testing is a performance

One of the usual arguments is that it enables hard-over from person to another. While handover can be relevant to consider if the team members changes often. It seems to me just to create redundant information based on requirements and other oracles. I mean where does it it end, why should we add every project information into the test cases and into the test plan. Stop it already.

Let the test cases be evaluated by the person performing the test – to see the whole picture. And not get biased by expected results. I want the persons performing the tests to use their brain and based on the oracles available evaluate the system under test. Also if everything can be planned – why would there be a need for retakes of movie scenes? It turns out even simple instructions are not possible:

Exact Instructions Challenge – THIS is why my kids hate me. | Josh Darnit

Let people do what they are best at

Let’s have testing being a balanced approach, where people evaluate and scripts confirm.

When the confirmation can be determined by an algorithm or by assertions towards an oracle we can code a test for it – and test it continuously. Adding as much automation as (practically) possible, aids the delivery in multiple ways. It aids to build regression testing and help us test that things not only worked once somewhere, but that it works again and again.

On the other hand when there’s no algorithm or explicit oracle in the form of specifications, acceptance criteria or similar authority we can only do a subjective evaluation: at that point in time – given the information available. do not neglect the wisdom of subject matter experts testing.

And in the later situation expected results hinder the exploration of whether the system under test fulfills not on the explicit requirements but also the implicit. We really should know better.

Photo by Karolina Grabowska on Pexels.com

#268 – Who Brings in New Knowledge?

Well, if you are reading this – there’s a good chance it’s you. Especially if you read this with the intention of sharing this with your team. I hope you do, obviously 😊. But perhaps it’s unclear whose responsibility it is, to bring new knowledge to the team. Is it always the team manager job – or is it a dedicated person that by role, or by habit, that bring in new knowledge?

Photo by William Fortunato on Pexels.com
Continue reading