Subscribe to continue reading
Subscribe to get access to the rest of this post and other subscriber-only content.
Resources for Test Strategy Mapping
goatsbook
My Books on Strategies and Leadership
Staff-Level Testing Roles, Career Paths for High-Level Testing Roles, TBD 2025 on LeanPub: https://leanpub.com/staffleveltestingroles
Leading Testing Activities, A Guidebook for New Leaders of Testing, > TBD 2024 on LeanPub: https://leanpub.com/ltabook
Goal-Aligned Test Strategies, Using Wardley Maps to visualize test strategies and align the test strategies with business goals, 2022. -> Available on LeanPub: https://leanpub.com/goatsbook
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:
- Set a Recurring Time and Space
- Unique Content – Reference the Rest
- Storyline and Flow
- The opposite of passive voice is not an aggressive voice
- 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.
On the Shoulders of 112 Giants
In my book “Goal-Aligned Test Strategies,” I draw extensively on the work of others. This is a reference post to further credit my reviewers and to list the 112 references in the book.
Special thank you to Lonnie for my writing evenings and to Simon Wardley for finding a path.
Reviewers and Feedback
- Tristan Lombard, a guardian angel for the project since the start in 2021.
- Praise from Simon Prior, Head of Quality Engineering, EasyJet.
- Feedback from Anne-Marie Charret, Quality Coaching
- Feedback from Anders Dinsen, Senior Test manager
- Feedback from Rikke Simonsen, Test Automation Consultant
- Feedback from Dan Ashby, Director of Quality Services
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.
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.
Tester Aided in Two-Digit Million Dollar Deal
Yes indeed. It has happened for me in the last couple of months. While my role is not tester anymore (but advisor in testing) – it just wouldn’t make the headline as click-baity. Sorry for that, though it does help to prove the point that testing specialists can be a part of bids and tender teams. A testing mindset is needed even before there is an “system development life cycle”.
The Dealing
In the context of bids and tenders the testing activities are mostly about technical writing around how the testing will happen when the dealing’s done. It’s not so much about finding issues – but more about a coherent analytic viewpoint. The customer of the deal often set up “requirements” that the supplier must answer and is scored against:
- Elaborate on a test strategy
- Elaborate on the suggested test process
- Describe relevant testing documents – don’t overdo them!
- Describe testing types and environments in use
- Describe test tools and approach to automation
If you don’t reply to all “requirements” you get a sub-par score, so being able to find information in the organization is key. The contractor uploads the final documents to the customer and the content is evaluated. The evaluation is usually a balanced scoring between the individual reply documents and the price point. Often price wins, even if the scoring of the (testing) documents where at 100% score.
More and more often I see outsourcing contracts that requests 10-15 test phases. It looks like someone has simply thrown the book at it, and not considered if it is an infrastructure project, a software development project or COTS implementation or – what on earth, they actually want to learn from the testing.
So how do you go about to be in on deals like this? – business context and a seat at the table seems key.
Business Context
First of all you need to be part of a company that cater to this size of deals. The deals I have been involved recently have mostly been about national IT solutions for public and semi-public organisations. The national government rarely have their own IT divisions but hire outsourcing companies to develop new solutions, maintain existing solutions along with hosting and cloud journeys. The more you add into the deal the larger the sums rack up. And similar if it’s a eight year contract for full IT operations, devices/laptops, support and application management services – the deal sum easily ends around the ballpark amount in the headline.
It’s probably different where you live and where you work. You might work on a consumer facing app that is paid pr subscription or perhaps in a team that develop a specific business-to-business product. And that’s cool – context matters. But I know even product houses have to go out and close deals with their business customers ever so often.
A Seat at the Table
Being part of bid and tender teams can be a key role for individual contributors in the staff levels. Staff levels are the senior and principal testing roles – that do not have management responsibilities. The term comes from the book “Staff Engineer: Leadership beyond the management track by Will Larson” and well as from “The Staff Engineer’s Path by Tanya Reilly“. The former book has some excellent chapters on getting a seat at the table and staying relevant there.
While having the role does not guarantee you a seat in the bid teams, neither is a staff role a prerequisite to be in. What matters most is probably management’s willingness to step out and let the experts in on the details. This could also be work that was done by heads of testing and managers of testing. Though as manager you should really focus on servant leadership and let your testing pro’s aid in closing the deal.
#269 – We Have Outsmarted Ourselves Again
Links from my talk at “map-camp-use-case-edition” Nov 2021:
Blogposts:
- todays innovation becomes tomorrows commodity
- Broaden the scope of the SUT
- No code, no test
- Darlings, Pets, Cattle and GUID’s
- Trends for the tester role
- Visual tests are still code
Other links:
- Wardley: Enterprise IT Adaption curve
- LEF community: Low-code evolves
- 2021 No-Code landscape for product managers
- Tim Bray: Tl;dr: No-code invocation, from Step Functions, of any API defined in the AWS SDK
- Rosie Sherry: Everything runs Excel
#265 – Using MTTR to Understand When to Test
It interests me deeply to explore why testing is happening. Often it’s because some decision-maker or framework dictates – “This is the Way“. And off we go on the quest to slay the dragon – or move items from point A to point B. Without much thinking about how the side quests help to move the main risks of the story.
The main risks are usually around something irreplaceable – and hence we test and try our best to shield it. But not all risks are equally dangerous. In IT we can build implicit testing into repeatable deliveries and reduce the time to fix things. The faster things are fixed, the better is time to information for the business needs.
#264 – Create Situational Aware Test Plans
From the endless discussions on the proper content and contexts of a test plan, it’s apparently still needed – but what goes in it? Let’s create situational aware test plans inspired by Wardley Mapping.
ISTQB template-based test plan documents are in my personal opinion no longer industry best practice. First of all it’s bloatware. While they intend to be a springboard into considering what is relevant we have ended up with 8 page templates – where every single of the 20 topics are required information. While it looks dazzling – it’s like frosting puffed with empty calories.
What most people delivering effectively software are using is 1) modern test automation and 2) modern test case management tools to lead and manage the test activities. And there is clear research on what 24 factors correlates to high-performing teams. It seems to me the templates have been frozen stale since 2012 – and are hindering us more than helping.
Continue readingHunches and Hard Truths
Recently I was in a network call on the use of automation and machine learning in detection of skin issues (EDB 5.0 in Danish only). Similarly I was reading about automation in the legal space. Both these stories align with the struggles we see in the discussions around how much we can automate. We can model it on this simple continuum between hunches and hard truths:
Complexity is a Matter of Perspective 