What If You Are Not Around?

Yes, you. What if you’re not around – what will happen with your tasks? Perhaps you feel that you can’t really take time off – because you are in the middle of everything. All teams need some way to handle both planned and unplanned absences. It’s not a matter of if – it’s a matter of when.

The topic came up recently on the Ministry Testing Club: How do you mitigate the risk of someone leaving the company. My answer was shared on LinkedIn, which led to Melissa reminding me to blog about it. Having been absent from the blog for a while, it was an appropriate topic 😉.

First of all, plan your planned absences. Whatever your local PTO and vacation law allow plan as much as you can in advance. Knowing that you usually need X amount for summer and Y amount for the holidays is a great start. Perhaps keep a few in reserve, if you are more of a person who has to take time off more reactively. I know the Nordics have generous laws with both vacation allowance, illness with pay, and child illnesses. While laws are laws, the culture can vary from company to company on how to manage absences. As with many other themes – be in control of your own time.

Where I work, we have a project allocation system that also covers “non-working” requests. As shared in the Club and in the LinkedIn post, a test lead recently submitted vacation 8 months in advance and had it approved. The customer, though, updated the project release date and a test lead was required during the test lead vacation. We struggled to find a replacement, as everyone else was already accounted for. There was no immediate mitigation of that test lead being away in that team.

A Peer System

We do have graduates, student workers, and other entry-level positions in the company. I try to engage with them and train them. So that they can learn and I work on something else. I called it a “peer system” in the Club reply above. It really goes for all roles, especially for those that are prone to bottlenecks. As I’m writing this I see yet another post on soMe, where a tester has 11 work items in status “Ready for test” at the end of the sprint and on a Friday. Testers are not the only ones prone to being bottlenecks. Principal staff easily becomes bottlenecks if they are the only ones to approve PRs, review work, do firefighting, etc. Being a bottleneck you become prone to stress, overworking, and potentially long-time unplanned health events that will make you absent.

How about if we formalized a peer system a little more. Appoint a peer for everybody! Have someone that you keep in the loop and someone that keeps you in the loop. It’s not about Cc’ing your manager on everything. They are usually doing management stuff and should have a similar peer. Perhaps you – if you are an aspiring manager. Some years back a coworker of mine became manager after having been a maternity leave temp for the previous manager. A sign of a good company is that they take business continuity management seriously in the leadership group. It’s actually a thing – if you need it at your place let me know.

Delegate Your work

Good leaders, even the informal ones without hierarchical responsibilities always try to delegate and work themselves out of a job. They share everything, work in public, and don’t sit on information or documentation. While it seems beneficial to be the go-to person (even for testing), it doesn’t scale in the long run. If you hoard skills and practices you become a bottleneck, a single point of failure. Rather you should move from “me” to “we” and learn to grow what you master in others. This will also help you grow yourself. There will be more about growing into leading testing activities in my book on the topic 😉.

I will always try to work collaboratively and share what I know. Plan your own time both for today, this week, and for the future. Yet life happens and having a peer helps both you and your peer if you are not around.

#299 – Wordy Documents Are Not Better

Spending your time writing long-form test documents is not an efficient way to communicate, nor will it get you the situation-specific support that you probably need. Don’t listen to the stochastic parrot – request information that is relevant to the situation at hand.

Recently I read a Slack thread on test plans, and one of the comments was that we should stop making things so wordy and reduce overexplaining everything. That reminded me of the time I wrote a 100-page test strategy that was very far from strategic – it was rather a specification of the how & the what, and less about why. Unfortunately, I had no choice in the content as it was part of a local public tender reply. To win the thing we had to provide a document called “Test Strategy” with items like:

• Start and Approval Criteria
• Listing of Applied Testing Types
• Milestones
• Risk areas
• Methods for testing coverage
• Test environments and test data
• Test tools
• Consideration of the Need for Test Automation

I’ve been around the testing block to recognize the old book this is coming from it’s older than 2008 BTW). While it seems helpful to elaborate on everything and the kitchen sink, it’s mostly busy work of empty calories. We have better ways of working than a big specification (of testing activities) upfront.

Don’t spend time writing a detailed Test Plan which will be out of date in no time and most people don’t bother reading (TL;DR). Instead, focus on communicating. The best plan doesn’t win. The best intelligence wins!

Andy Glover, LinkedIn 2023

The Stochastic Parrot

My bet for the future is that long-form template documents will soon be generated using large language models. The more you ask for the more will be auto-generated by a stochastic parrot [On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? 🦜 Authors: Emily M. Bender, Timnit Gebru, Angelina McMillan-Major, Shmargaret Shmitchell]

The better approach for customers of IT services is to ask for less text. Have the documents zoom in on the vendor’s perception of the client’s challenges. Yes, it will take more time and effort – but you can still score a short essay for the tender process.

Make shorter planning documents – and for strategies, make a map.

Business needs are for innovative deliveries – usually not commodity services.

#297 – Stop Hoarding, Start Growing Others

The more you learn in your role, the more important it becomes for you to share and build skills in others. If you hoard skills and practices you become a liability, a single point of failure. Rather you should move from “me” to “we” and learn to grow what you master in others. This will also help you grow yourself.

In my many years in the same role, I simply took on more tasks. We just dug in and worked, often putting in overtime. People grew and were promoted based on being scarce. We could never recruit as skilled as us. We were the Go-To team. Tasks and knowledge were often hoarded. After a change in the team, I realized that it was the wrong way around. Both for me, for the organization, and for all the new people in the field.

People Develop Where They Almost Can

Experienced people generally thrive with novel and emerging problems. They eat wicked problems for breakfast and know their way around the complexities of Cynefin. They will usually be bored by the more simple and rote tasks. Their preferred field is to work with new situations (Illustrated below, left figure).

To new people in the field, though, it’s the other way around. They love a good template, a cookbook, or an example. Their best work is, usually, to take some half-baked good enough and make it follow given (best) practices. (Illustrated below, right figure).

A sketch/map of two people with different development areas.

When experienced individuals disregard the red cross and monopolize tasks and knowledge, it may initially appear beneficial. They are praised for their perceived irreplaceability. However, over time, this can become a burden for the organization. New systems and patterns emerge, and the inability to adapt becomes a challenge. Work halts, People crack under stress and everyone stops using COBOL eventually. Over time, skills that are not shared move to the left on the evolution scale, but just lower down on the visibility to the stakeholders. (In the jargon of the Wardley Mappers). A pet project in a not-so-good way.

On the other hand, having new people sharing the load and contributing to the tasks helps build new people who can handle tasks like this. It’s easier to recruit people with an appetite for learning and training them, than hiring skilled staff. Thus making more people grow. You can’t be everywhere.

The Career Ladder: Senior vs. Staff

Another way to elaborate on this change is the difference between Senior (L5) vs. Staff (L6) as described by The Developing Dev in the drawing below.

Senior (L5) vs Staff (L6)

As elaborated here:

Staff engineers uplift others around them. They should have the ability to help L5 engineers grow. There are a few ways they uplift others:

• Mentorship – Dedicated mentorship, preferably with senior engineers
• Knowledge sharing – Writing wikis, giving presentations, contributing to Q&A groups
• Collaborations – Growing others while working with them (e.g. code reviews, design reviews, discussions)

L6 engineers should also contribute to growing the organization. This means that they help with recruiting and partner with their manager to improve team health.

Developing Dev, 2023

In the future, I will do my best to stop hoarding skills and start building capability in others. Not only actively sharing knowledge but actively sharing tasks. As I said a few years ago: As you are learning new stuff, I am unlearning to help you

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.

15 years ago my PhD advisor taught me One Weird Trick for editing your own writing. Edit **back to front**, paragraph by paragraph. I still use it and it still surprises me how well it works. When I get my students to do it, it often blows their minds. Try it!

— Arvind Narayanan (@random_walker) October 16, 2022

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.

Have proofread quite a few books for my friends in space. Couple of Stage Mom top tips:
– Avoid colloquial language for global readers
– Know your audience. If for beginners, use footnotes or end notes
– Don’t overuse passive voice
– Tell stories from your experience! pic.twitter.com/sehtnM5bRx

— Tristan Lombard 🇺🇦 (@TristanLombard2) October 2, 2022

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.

Taking My Own Medicine

Recently I had the chance to apply my own templates to myself and my active project – as I had to mentor a new test manager. I was challenged in explaining how I read the upcoming IT environment project. After looking into resources for new test leads, I realized I could take my own medicine.

Photo by PhotoMIX Company on Pexels.com

A year ago, I created a new test plan format – the Situational Aware Test Plan. While mind-maps and one-page test plan canvases exist, I wanted to elaborate using the evolution principles from Wardley mapping and stop writing test plan documents.

The table structure is there to provide guard rails for the elaboration. I will use the Darlings, Pets, Cattle, and GUID -mnemonic as headlines. Our strategic decisions emerge as we use the worksheet based on the current situation and state. The strategies will be the decisions to push a field in the grid to another state. 

Delivery and Situation

	Darlings	Pets	Cattle	GUID’s
New project	Fixed date
Existing delivery speed		Scheduled Quarterly
Test Environments, internal			Repeatable
Test environments with integrations	Crafted	Some existing know-how
Environment Infrastructure			Hosted data center practices
Test data		Known but cumbersome

While this project introduces new test environments, there is an existing environment with a quarterly delivery pace. This is a classic example of the core chronic conflict of pursuing both: responding to the rapidly changing competitive landscape and providing stable, reliable, and secure services (DevOps handbook introduction xxv) as elaborated on Align your Test Strategy to your Business Strategy.

The test team allocated beside me and the new test lead is a new junior and senior tester. We are in the same team, and most are even in the same office. So collaboration will be collaborative and pervasive, with a focus on helping the new people grow.

The test team

	Darlings	Pets	Cattle	GUID’s
Test team collaboration			Growing	Pervasive
Test lead			Growing
Mentoring		Enabling
Domain know-how		Getting there

Test tools and approach

	Darlings	Pets	Cattle	GUID’s
Test activity	Explore integrations		Confirm internal requirements
Test cases			Existing can be updated.
Test case repro			Create new repository

As mentioned in the blog post about visualization, we can now use the map to discuss why we need CT and ET for the project. Based on the project’s layout, I would advise having an expert exploration of the integrations and more standard scripts for the known construction of the internal environments.

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

#266 – Retraining Yourself for the Future

The local university college has a big sign outside saying: “Retrain Yourself for the Future“. The thing is – what is offered is at best years behind the current practice in the industry. If you certify towards a body of knowledge, you forget about the learning journey and only on the outcome. Innovation yet happens in many ways – and industry practitioners are only one form to train for.

#263: There is a Model for your Trouble

Often directors, managers and other decision makers talks about an advanced challenge they have: What can we automate, who should automate and what tools to pick. There more and more I listen, the more I hear – they have not applied any models of the problem at hand. And there usually is a model of the problem space already. Any old model is preferable over no model at all. But it can be hard to see in the middle of chaos.

Implementing Change – First Steps

TL;DR: Stepping into the deep water – have a few supporting first steps.

Photo by Francesco Ungaro on Pexels.com

Inspiration: Ministry of Testing Bloggers Club August Challenge and My three step recipe for overcoming procrastination