Relations – are about half of IT

You can’t have IT projects without relations. Relations matter more than it seem.

Recently I had an online call with the adults around the 14yo: An autism psychiatrist, the school guide/trainer, his mom and I. Online on teams, obviously. The other adults in the call were struggling with all the online schooling and interaction, and no face-to-face with the young student. Besides all the stress of the pandemic they had a hard time working at all.

To me online meetings are a natural way of working. I have been working primarily through online interactions the last five years or so. The people I work with are distributed away from me, they are in Copenhagen, China, Philippines and other places. It seems the teaching industry broadly has to catch up with the lessons and tricks from the IT industry. Besides the stress of the pandemic and lockdowns IT people can actually do their work. So I mentioned that I only work online.

And the psychiatrist said, but for IT people relationships aren’t so important.

… oh …

Relations matter in IT projects

The psychiatrist probably doesn’t know the inside of an IT project, and are probably only aware of the City IT staff when something is not working or they are rolling out yet another upgrade of her systems. So to her it seems that IT is all about the deliveries – not so much about the relationships. (to bad really)

On the inside of IT projects, relationships are about half of the story – the actual IT thing is the other half. For the clear and simple things relations matter less (the commoditized, as Wardley would point out). When you think about it, IT have a huge range of models and frameworks around the relationship part: Cynefin, Agile Manifesto, Scrum, Team Topologies etc. The more you move around on Cynefin the more relations matters.

3D version from Rob England Cognitive Edge

Relations are obviously important to line managers, coaches, lead roles and people in enablement roles. But for the individual contributors in the teams – relations matter too. First of all, time has run out for the expert douche bags and hero culture. Everyone talks about the whole team approach to quality.

Secondly the research from the Accelerate is clear – besides all the mechanics of delivering IT – the culture of the workplace impacts the business performance. Lastly, when you look at incentives for the individual, the non-monetary matters are becoming a key differentiator. Especially given the pandemic – gone are the bro culture of foosball tables. What’s hot is work from home, team diversity, moral practices and a decent team culture.

There will be a trend in the future, that changes the IT office landscape yet again. The best teams will meet online for some of the work – and join in collaboration spaces or getaways for alignment. Because even for IT work relationships matter – and at the end of the pandemic even we will adjourn in our teams.

Automation is for Other Roles Too

Automation of business tasks is no longer for the software developers only. Similarly test automation is no longer for testers and test engineers only. Both these trends help to create smarter testing performed by non-testers.

As discussed in “No Code, No Test?” and in posts before that, automation tools like IFTT, Airtable and other tools are emerging to enable not only private end-users but also enterprise end-users to do business automation. As an example it’s being actively discussed among the local administrative hospital staff how to apply RPA for data entry and data updates.

I know RPA/low-code implementation is often a symptom of an underlying problem with system integration on one side, and poor process for system optimization on the other. That’s just the way it is, not all systems in the world are based on state-of-the art microservices or processes. It’s a mess of things and your mileage will vary.

XKCD 2347: Dependency

The low-code business tools emerge and gain tracking – and enable what Gartner calls the Democratization of Expertise and Mabl calls customer-centric testing. In either case it allows for some digital transformation of business activities, that are not directly reliant on software development activities. Yet the more complicated and complex even the low-code solutions become, the more important it is to maintain and test. .. and that’s where the automation best practises come in. Visual Tests are Still Code

Similarly for Test Automation.

Low-code automation are not primarily for the testers and test engineers. If your team has access to the source code – you can follow the modern testing principles and build in Observability in ( and a lot of the things in the code (from: When to use RPA in testing). That’s so much talk of the town, that it should be considered a best-practise (in the Wardley sense ;).

To me the best case for low-code testing tools (Mabl, TestProject, Testim, Leapwork is to apply it in all the other situations. Co-create smarter testing performed by non-testers and non-developers. Give it to the business people involved in testing SAP or ServiceNow, give it to the supporters using ITSM or similar ticket tracking solutions – give it to all the subject matter experts (SME) involved in the testing. But! Don’t let them sink on it, train them, support them. Let them build confidence on the tool slowly – after all they are not testers.

Where do everyone fit in? The testers jobs will be to explore and to train/enable the experts. I see more testers and test coaches being in the Enabling team – while the SME’s are the key persons in the Stream-aligned team – especially if the tools available to the SME’s are low-code. Have tool smiths (Test engineers) at the ready with building blocks of reusable components, automation best practices and coding snippets (Complicated Subsystem team).

Smarter Coding for the Business

What’s the Problem Here?

At the the recent “Online Test Conference – Fall 2020” a workshop reminded me to look at the problem. And it’s always a people problem. Which got me thinking later on in the program – what’s this talk trying to solve?

About the OTC

The fall 2020 version of the Online Test Conference was the 9th version, and the conference has been online only since the start in 2016. I had a talk in 2017: Shifting is more than Shift Left. Since then the conference has expanded to be over three days:

  • One day European-friendly timeslot
  • One day American-friendly timeslot
  • One day Asia-Pacific-friendly timeslot

With little effort you might be able to listen to talks on two days, – and if not the whole thing is available on youtube afterwards. The conference is driven by Joel and his team from PractiTest. Though the only marketing the push is their free and annual State of Testing Report. the State of Testing report has been running for some years too and provides insightful global trends in the field of software testers.

The OTC is great for multiple reasons: It’s free, anyone can join (and many new people to testing does), the talks are recorded and there’s a bit of a chatter on the slack channels. It’s an easy way to step up your learning.

But back to this year

New this year was online workshops. First off I attended “Workshop with Rob Lambert: Building diverse, inclusive and effective teams by focusing on behaviours“. Which was great on two accounts: interactive and had key takeaways. One take-away was the use of DISC profiles to understand yourself and the team around your delivery. I’m usually cautious about personality tests, but Rob did put it very reasonably.

The primary action item from the workshop was though to look at every meeting and consider:

What problem are we solving?

Rob Lambert, OTC Fall 2020

This can be applied is so many ways. And with the addition: Whose problem are we trying to solve – you can get closer to understanding the business and your team. It might sound off, if you are more a testing type that likes to investigate and spot problems and trends – but at the end of the day you too have to consider what business problem your testing taps into. What is the need of your decision maker?

What’s this talk trying to solve?

Due to time constraints and work I didn’t manage to catch many others “live”. Unfortunately one of the talks I did pick, I had to stop watching. While the talk had both a presentation and a video feed, it seemed as the person was just sitting there talking to himself. Watch the full recordings HERE, and judge on your own.

Not that my talk in 2017 was super, but I learned since then that even an online talk can be engaging. As a presenter you have to pause (Dana), you have to ask the audience questions (Angie) and have a theme or a story/stories. I tried my best on “When Subject Matter Experts test” [Available online with subscription: MoT Dojo].

So the question above applies as well to conference speakers and conference attendees. If I can’t tell what problem he’s trying to solve – or for who, then I’m out. The barrier for exiting online talks is so low, that it will be a factor in the future: to engage the listeners and to be clear on What’s the Problem here.

Photo by Miguel u00c1. Padriu00f1u00e1n on

[Media sponsor for the Online Test Conference Fall 2020]

Where Online was First

December 1-2-3 2020 is the 9th Online Test Conference. Since 2016 the OTC has been Online first, Global first and Free first too. Free to attend and free to speak at. Remember: Your learning is on you – take the first step here!

[Media sponsor for the Online Test Conference Fall 2020]

I’m Part of the MoT

Here’s a list of how I am part of the greater Ministry of Testing Community

Test Bash:

The Club


Align you Test Strategy to your Business Strategy

Obviously! – But often where we fail to do this as testing professionals. We get caught up in terminology discussions, application of standards and obligations and who gets to do the work – that we forget to align with the business side of things. And thus the beatings continue until morale improves – if you don’t align you test strategy to the business*.

The business side can be hard to read. Also coming from the back story that testers long for objectivity – and “just” want to state the facts for the decision makers. I know, I’ve fallen into that trap many times.

We need to be able to read the business strategy and prepare the test strategy accordingly... and business decisions first.

How to Read the Business

Recently I was at the 99-minutes workshop on: Leading a Test Automation Strategy on the Ministry of Testing. (If you’re interested, it’s being rescheduled – but requires a paid MoT membership). In the workshop I was reminded that a strategy is the path towards a goal or vision.

A strategy is the map towards a vision

One way to read the business is to use Wardley maps. The Wardley mapping model was developed by Simon Wardley in 2015 and put in book form on Medium in 2018.

Wardley maps allow the representation of visibility of value on one side and evolution of components on the other side. These elements allow the relative positioning of elements, like on a real map – and allows you to discuss and project changes and paths in the landscape of the business.

How to use Wardley Mapping to understand how you deliver customer value

Wardley mapping have been used for the following, to name a few:

Preparing a Test Strategy

To me there’s more to a test strategy than the model of testing, and there is more to a test strategy than to pick test charters, test coverage strategy, test automation strategy and the visualization of pipelines. .. it’s a path towards a business goal.

Previously I have looked into how Wardley maps can be applied for preparing test strategies: Visualize the Test Strategy, Making a Map of Risks, Broaden the scope of the SUT – let’s look at how we can align the business and test strategy in one map.

We can easily arrange our vertical dimension to be the visibility to the decision maker – not the user as in the default Wardley map.  Using the decision maker as anchor on the map, we can now position elements relative to the value for the decision maker and use that to explore the context of the system under test. The decision maker is mostly interested in things that drives the business, secondly perhaps what kind project or delivery it is – and only after that is the testing activity relevant to consider. 

Align business strategy and test strategy

Readers of the DevOps handbook will recognize the core chronic conflict of pursuing both: responding the rapidly changing competitive landscape and providing stable, reliable and secure services (introduction xxv).

With the above Wardley map – and perhaps a bit more context and data about the specific situation – I can see and start a discussion on how the test strategy aligns with the business strategy and business map.

(*: Headline from Keith Klain: the beatings continue until morale improves)

It’s a Model – not the Truth

Usually when we discuss Observability, Testability, Modern Testing Principles, it should be with the disclaimer from what context the lessons originate and that Your Mileage Will Vary.

There are so many different IT projects out there – that assuming every IT project is about source code is quite a blind spot. Projects that deal with commercial standard systems or outsourced software might have source code underneath – but many teams does not have access to the source. Additionally, many legacy systems from the 90’es and older does not have the same automation capabilities as we have now.

Not all software projects are about consumer facing native apps and websites. While they are numerous there’s still plenty of systems out there for internal and business-to-business use. While the trends from CI/CD are picking up for B2B and internal systems, things doesn’t move so fast.

State of Testing 2020 : Systems, Technologies, Development and Testing Models

State of Testing 2020: Systems and technologies
State of Testing 2020: Development and Testing models

So when someone talks highly of Testability, Observability and building code-based test automation or even as I talk about the benefits of RPA – there are some underlying assumptions. Assumptions of a specific code-base, assumptions of an architecture, assumptions of the test team…

To many (testing) people the terms: Observability, Testability, Modern Testing Principles and the learnings from the Accelerate book – are visions or goals, at best. They are great goals to strive for – again, it’s the learning, not the lesson. Even the Spotify model once highly hyped is not considered an idealistic model from back in time.

I appreciate that the authors of “Accelerate” has but this up-front, that their research and examples are based on: “multiple examples of applying these practices within mainframe environments, traditional packaged software application delivery teams, and product teams“.

I wish other practices and models would do the same – I’ll try my part.

Explore, Code and Business

There are plenty of contexts where testing happens that doesn’t formally involve testers, or formally involve a testing phase. Still contexts like those have testing as an implicit activity.

We are neglecting the business know-how when all we talk about wrt. smarter testing is either the practices of exploration or of coding. Let’s bring in smarter testing for the business and coding sides too.

Smarter Exploration and Coding

Exploration <-> Coding

The ressources are abundant coming from an exploration practice and moving into a coding practice – or the other way around. It’s in this space the debate rages about SDET’s, and test engineers, coders who test, and testers who code. And perhaps the sweet spot in between – automation in testing.

As this is the usual space for testers (of all kinds), we are a bit blinded to see the other spaces. We can see and talk about making exploration more business oriented… BDD, 3 amigos, Product Demo’s, .. observability etc. Similarly we can see and talk about making automation and coding more business based by faster feedback and adding observability. But in both cases the direction is into the business space, not from the business side….

Smarter Exploration for the Business

Exploration <- Business

In the context of small and medium enterprises – there are few testers, no test managers or even a formal UAT. Look at a small municipality too, they have very little formal IT staff, yet heavy rely on IT systems. Public facing websites are just a part of the IT landscape for most organisations.

The managers asks the IT people to configure something, it goes live and perhaps they give it a glance or two. Perhaps the IT team outsource development or implement commercial standard systems – still it’s very often low-key “click and play” – “does this work for you” etc.

There’s plenty to explore when the business experts do the testing. We need to enable the business people to do smarter testing and exploration. They will never see themselves as testers, se we need to reframe their contribution, expectations and provide a space for them to grow their exploration.

Smarter Coding for the Business

Coding <- Business

Similarly we need to help the business in making better coding too. We have solved some of the challenges of automation into moving parts and algorithmic checks to see if anything odd happens. Visual validation tools such as Applitools Eyes can automate into PDF files.

Test Drive by Original seems to be very effective in handling iSeries mainframes with multiple and various application timelags. Remember folk’s there are many legacy systems out there – it’s not all containers all the way.

There is a trend that Test automation, CI/CD and DevOps is picking up for commercial standard systems (SAP, Dynamics 365, Sales Force, Oracle forms etc.). Low-code tools enable test automation on top of seemingly un-addressable user interfaces – or systems without direct ways of building testability and observability. Still visual code is still code – and computer science disciplines apply.

The business side of things will never see themselves as coding or development, so we have to enable them in other words to make smarter coding from the business side of things. While platforms like Test Automation University are great for learning specific technical skills, we still need to reframe it in a business context to enable smarter coding from the business side of things.

You are in the middle – remember to see all the angles.

You are in the middle
You are in the middle

RPA – Tomorrows Best Practise

Recently I was reviewing the offering of the Microsoft Power automate desktop offering, and I realized: Robot Process Automation is still the rave – every tool vendor and their dog has an offering in this space:

oprah's everybody meme
(Everybody has an RPA tool, obviously)

Which is great – but also very very expected. It’s reaching the state change between a emerging practise and a good practise on the Wardley Evolution scale (not yet a best practice? – perhaps to some).

todays innovation becomes tomorrows commodity

[CSC Leading edge Forum | by Simon Wardly | Feb 2, 2012

Making a Map of Risks

I’m currently exploring how “Wardley maps” can be applied in strategies for testing. Here is an example of how I used a map to understand and work with risks.

In my current projects the system under test is not software development, but rather a end-2-end transition of IT services. The technology is part reinstallation, part spin up of containers – in other words, some elements are more or less commoditized. Also some elements are more or less visible to the stakeholder. It seems like a good fit for a Wardley map….

How to use Wardley Mapping to understand how you deliver customer value

Read the intro by Stephan Willemse on Medium

First I need to tailor the horizontal axis a bit. I have read up on the articles by Simon Wardley and Ben Mosior with regards to the framing of “evolution”. For a quick intro read Erik Schön describes the four stages, like this:

  • Genesis: the unique, the very rare, the uncertain, the constantly changing and the newly discovered. Our focus is on exploration. 
  • Custom Built: representing the very uncommon and that which we are still learning about. It is individually made and tailored for a specific environment. It is bespoke. It frequently changes. It is an artisan skill. 
  • Product (+ rental): the increasingly common, the manufactured through a repeatable process, the more defined, the better understood. Change becomes slower here. Whilst there exists differentiation particularly in the early stages there is increasing stability and sameness. 
  • Commodity (+ utility): scale and volume operations of production, the highly standardized, the defined, the fixed, the undifferentiated, the fit for a specific known purpose and repetition, repetition and more repetition. 

There is also a relevant article, where Evolution is the level of ambiguity – which is just one of the relationships Wardley Mapping have with the Cynefin Framework.

The key legend to the horizontal axis is the relative position from unknown/uncharted to embedded/industrialized – to you or the organization being mapped. It’s possible to tailor the labels specifically to the components being mapped – like the legends of altitude lines, buildings and roads on a map. Here’s one for the specific risk context above:

Risk legendUnchartedKnownStableStandard
ElaborationWe don’t know the risks yetWe see these risks.Risks are stabile.Risks are reduced to standard components
Experimental tailored legend

First I map the system landscape: relative to the business vertically and relative to Risk stage horizontally. It gives me this anonymized map:

It’s probably only half-way right, but with this I can consider:

  • How far can I move the elements to the right?
  • What inertia blocks movement?
  • Which ones can I move the furthest?

With the map (position and movement) I can consider what happens when risks change and evolves – how does evolution affect the test strategy?

If we automate Configuration, the risk is significantly reduced.

Reinstallation can only get us to a certain point, due to