change

How Do you Eat a Mastodon?

jo2sn Enterprise IT, Softwaretesting , , ,

… one piece of the time. Really. Don’t worry about it – it’s similar to eating an elephant.

While Discord and Slack sites can be places to go for communities with the faill of Twitter – they are closed systems. You need an invite and communication closed within the instance. This is good for closed discussions you want to gatekeep. Mastodon seems to be the place for serendipity and cross-collaboration across topics and communities. It’s not new, the framework started in 2016 gaining 1 million users in 2017. There are a number of great and extensive guides – one of them is fedi.tips. Another great guide is Mastodon Lessons Learned by Lisi Hocke (@lisihocke@mastodon.social).

Hi I’m Jesper🧷🌻🐐📕🗺🇩🇰 (@Jo2sn@mastodon.social)

Signup and Servers

For Mastodon, you create accounts on a server (or instance) in the Mastodon-based network. Through a shared protocol the people on the servers can communicate with posts, threads, likes, and resharing as known from other platforms. Mastodon is really the software framework (on GitHub) and the network called “Fediverse” – but people mostly call it “on Mastodon”.

Someone wrote that picking a Mastodon Server feels like selecting a character in a new video game. You don’t really know what you’re looking into and how you will play the game. Luckily you are not fixed to one account on the Mastodon network. You can have multiple and easily redirect from the old to the newer. I have tried jumping profiles myself, as the first one I made was on a server with too few general topics. One of the elements of Mastodon is that each server has a timeline – besides the ability to communicate across.  

Some servers are topic-based on Open-source software, others on art and LGBT, you can pick a specific server and expect the local content mostly on that topic. Or you can pick a general-purpose server – if one topic doesn’t define you. There are some tools, like debirdify that can help you in the process – but not yet a 1-click tool to move over. 

Two ways to select a server:

People can and will move to many places – there is yet to be a primary test community instance. 

Profile and Settings

  • Your username is text-based, but you can go crazy with emojis in the profile name field
  • Create your profile with a picture, banner, and profile text
  • Profile meta-data and hashtags will help people find you and recognize you
  • Add 2-factor authentication and save the password and keys
  • If English is not your native language, there are other languages available (German is rather prominent). Selecting a language seems to give you more content in that language.
  • Enabling the “slow mode” setting is recommended. It forces you manually to reload the feeds and not have the dreaded firehose. 
  • Make an #introduction post and write your favorite hashtags, that will help people find you.
  • Write your Mastodon username @user@server.name in your Twitter bio so that others can follow you

General Use

As there is no algorithm to drive engagement, so use hashtags and reshare content from others. Likes are only posted to the author – so reshare/retoot great posts. Similarly to following people you can follow hashtags like #MinistryOfTesting and #TwitterTestingPeople. The culture of Mastodon is to be inclusive. Use Content-Warnings and hide images as a common rule – and ALT-text on images as a general rule. 

Mastodon has free apps (Android, iOS) for casual use and some pay-to-use apps. Currently, it seems you can’t follow hashtags in the iOS app, so I tend to use the browser more. There is a range of choices – see what bests fit you. You can get a long way with just the primary site.

Servers are run by small teams of admins, so in peak periods there might be suboptimal performance. Most servers seem to be funded by patreons or similar fundraising. 

In theory, an instance could close down and take everything away. If you have content that is more permanent and you want to own, put it somewhere you control. The same challenge is true for ad-based social media (Facebook) and subscription-based platforms like Medium. 

If you feel like organizing the content coming your way, enabling the advanced web GUI setting will give you columns like “TweetDeck” – but the setting is global for your login. Sometimes I just want a quick read over the timelines, other times I want to monitor specific topics. To monitor topics I have set up columns in Sengi https://sengi.nicolas-constant.com/. It’s a per-browser setting, so it’s more of a topic radar that can be different across my devices. Personal lists are a feature too, but it seems based on people not so much on topics. 

Do notice that direct messages aren’t private messages. All the people you tag can read the messages. So don’t tag the people you want to rant about. 

The visibility of a toot/post follows the flowchart below. 

Via @geekyMary@Mastodon.social: https://mastodon.social/@Geekymary/109290888512800541

Where I Have Changed

jo2sn Softwaretesting , , , , , ,

The Ministry of Testing Bloggers Club suggested that I write a post based on “In testing, I have changed my mind about ________”. As this blog dates back to 2012 with consistent (220) articles about testing, and my career in the field dates back to 2002 – it seems a 20-year experience should give me a few things. Testing is still not dead – and it’s still about the context (lower-case context, not CDT).

It’s not about: Testers being the only ones doing Testing

yeah, not so much these days. Testing is an act that any role can do in context. It’s about the testing – not so much the testers. And I have realized that even classic test management tasks can be done by someone else. Testing is not owned by the testers – it might be stewarded/facilitated by us, but it’s performed by a team member (who could be a tester).

It’s not about: Perfect Requirements

After decades in IT, it’s clear that even requirements are never perfect. When we look closer we see the business requirements can vary from a profound idea to a rudimentary feature of the system under test. Even in regulated industries requirements can be both about a specific configuration in a SaaS system or a loose idea of a relevant dashboard. Sometimes a requirement can be by design of an underlying commodity product – there doesn’t need to be a test case for everything.

The more rigor you add to the requirements management – the more fragile it becomes. It’s key to understand the risks and bets of the person paying for your solution. – in that lies the true borders of the delivery. Much can go informally along if it aligns with stakeholder values.

It’s not about: Defects

Back in the day defects needed to be accounted for, tracked, and distributed. Besides testing documents – defects were the only tangible delivery of the testers. The defects needed to be raised and closed. I recently wrote a guideline that stated that only observations that couldn’t be fixed within a day should be raised to the project manager for shared handling. In that context fixing things is within the same team. If it’s for another team to fix, defects are simply something communicated between the teams (check team topologies for team interactions). Sure you can still find a blocker or a P1 – what matters is how fast you can fix things.

It’s not about: Month-Long Testing Phases

The more time there is from idea to implementation – the more the requirement risks not addressing an up-to-date business objective. Timing is key. Some tools provide epics and user stories – but the structure is often misused to be a simple work aggregation – and not goal aligned.

The counter-intuitive trick is not to add formality, and more time between releases – but less. Less time between feedback between idea and implementation, and less time between implementation and test. Less time between the various forms of feedback adds to better results faster.

It still happens, I’m sure, that a business needs a month-long testing phase before a release; having a range of business staff to participate in testing the latest release of the enterprise ERP or CRM. More often the testing phase is one sprint behind the development activity. I have pondered this a lot.

At best testing is an integrated activity in the team and in the sprint. But if testing is a more separate activity – it can be both agile and context-relevant. So I have changed my mind about this anti-pattern.

It’s ok for testing to be in the next sprint –

if that adds consistency and less stress to the team*

* Seperate boards needed. Your Mileage Will Vary

Why Do We Fall, Master Bruce?

jo2sn Enterprise IT, Softwaretesting, Wardley's theories , , , , ,

… So that we can learn to pick ourselves up, Alfred! I was recently reminded of this quote from watching the “Batman Begins” movie with my 16yo. I really needed that reminder. Then I read the two blog posts by Beren on “Those who Failed” and “Versus the Endboss“. Let’s put it out there that we fall – and fail to remember that we fall.

I had been part of a large project – but had read the culture all wrong and we had failed hard. For a number of reasons and maybe mostly for systemic reasons. The team expected one mindset and one way of tooling – we provided another one. Even with all my best intentions and know-how of change management, this crashed. As Hannes elegantly put it, we had cycled too far ahead of the team:

  • The team expected minutes of meetings and agendas, we worked for making things visible and shared
  • The team expected testing to be checking the requirements, we worked for testing to support critical decision making
  • The team worked political with back channels, we worked open and power-lifting
  • The team participants had agendas that didn’t align with the project’s purpose
  • The team expected all things equally important, we worked by priority and deadline
  • The team expected detailed test cases to be approved at all steps, we provided intentions and purpose
  • The team expected detailed handovers, we worked entrepreneurially to set things in motion
  • The team expected an error-free lead, we worked knowing I wouldn’t remember everything

At one point I was arguing that the team needed to read Hofstede’s cultural dimensions theory – to read up on the different cultures we would be interacting with (our customers). In retrospect, we should have used it on ourselves first of all.

Hofstede’s cultural dimensions theory

It’s a little more detailed than Westrum – and even Westrum might have helped. That is if we had been able to articulate the conflict well in advance. Perhaps a senior hire should have spotted the signals beforehand. As an outsider, I relied on people telling me things. I couldn’t hear or see the back-channel communications. This is a struggle for many staff people when switching roles:

Initially, no one from the operations organization and latest implementation opted for the leading the activity. As we had no playbook or project plan (only the produced artifacts) – I made a scrum-board-inspired work tracking system. Perhaps I should have used a Wardley map first of all as recommended by John Cutler in “TBM 18/52: We Need Someone Who Has Done “It” Before“

What is Wardley Mapping doing for us here? It is letting us explore a more nuanced view of the problem space. Instead of treating things as one problem, we break the problem apart into a bunch of capabilities. When we do this exercise we typically find:

Not everything is an existing playbook. Not everything is a new playbook.

To solve new problems, we need a foundation of stable playbooks. For example, to solve that crazy new problem, the team might need a foundation of trustworthy data.

Yes, you can break things apart to see them better. But you’re also dealing with the whole thing.

But then again the team would probably have stalled over the very concept of a strategy map. People are weird. No matter how it looks at first, it’s always a people problem. And even if you do try to take the first steps – your steps could be in the wrong direction. Even Master Bruce will fall in that situation.

You Cannot Be Everywhere

jo2sn Softwaretesting , , , , ,

A key lesson with the whole situation is, that there is no Nirvana, no steady state nor closure to everything. The only constant is that life is ever changing. Coming up around the corner is a new change – some can be planned for and others not so much. Imagining that things can be different is the first step to dealing with change (Thank you, Virginia Satir).

There will always be more things needing attention. Sometimes it’s based on the fear of missing out (FOMO) and the urge to be involved in everything. You will very easily find yourself stretched too thin – and needing a way to scale the effort, both professionally and personally. Clocking more hours will only work in the short run. Remember, it’s ok not to scale – sometimes it’s actually the best solution.

Continue reading →

Strategy is about Making a Map

jo2sn Softwaretesting, Wardley's theories , , , , , , , , , , , ,

Strategy is not where you are heading, but how you’re getting somewhere in the long run. That goes for all strategies, and even for test strategies. Though for test strategies we often get caught up in mechanics of selector strategies, testing types and techniques that we lose track of the higher purpose: Moving the business towards a vision.

Continue reading →

The Testing, not the Testers

jo2sn Enterprise IT, Softwaretesting , , , , , , ,

Occasionally I see posts and discussions, where testers are indignated that this and this company has no testers. How could they! Or similarly when a product is released publicly with significant issues: See – it’s because they have no testers! Or that the testers are not taken seriously. OMG!

Continue reading →

Someone else will do it

jo2sn LEGO, Softwaretesting , , , , , , , , ,

The testing activity has been under change for long. And it’s clear that the testing activity has shifted. Even the test managers have to re-calibrate – as other roles will be doing the test management activity. Be prepared, as someone else will do your testing job. Work on building self-reliance in others and be prepared to hand-over what you can do.

There is more to testing than testing specialists punching test cases. The testing activity as such, has shifted (both left and right), and testing is being done by more roles than “testing people”. Depending on the context, the explicit testing activity is done by a mix of developers, testing specialists, end users and others.

I often find myself as the only testing person on the project. The testing activity is done by automation specialists and end users in one project, and by technical operations staff and end users in another. In these projects either the technology or the business knowledge is paramount, and not so much exploration, flaws and edge cases for specialized testers to explore.

me, 2020. YMMV

Similarly for the test managers – there’s a trend/shift, that sometimes the test management activity is shifting away from the test managers. Even to me – even if I’m sometimes more an a “project manager of the testing activity“, a “Test coach” or similar. The trend is already there – coined sometimes as “whole team approach to quality“. Yes, most of the test management activity can be done by scrum masters, Release Train Engineers and even project managers ….

Recently I was asked to assist a large transition project for a holding company with many brands. Each brand had their own applications and technology stack, but the holding company had decided to move the hosting. So the holding company’s Project Management Office (PMO) was put in charge of facilitating the brand’s testing activities – an activity they had never considered nor done before. My role would only be to provide guidance, not do the actual facilitation.

Which got me thinking….

And after some deep thinking. – I do have the privilege to be able to adapt. I don’t need to hoard knowledge or make power moves (anymore) or worry about health-coverage or any of the lower Maslow pyramid terms (anymore).

It’s very natural for me to hand over project approaches to my co-workers. I’m often on the “blue team” to outline the strategy, My best field of work is to bring clarity and consistency, not scalability or repeatability to the practise.

I naturally hand over learning anyways, so why not re-calibrate when the thing I do has reached a stage, where it’s repeatable. And then focus on building the skills in others, work myself out of the test management role as we know it.

And don’t worry that someone else will eventually do my (testing and test management) job. The first step is to acknowledge the trend/pattern, second to redefine and bring clarity! Let’s explore and see what we find!

Someone else will do the building, not Emmet. His task is repeatable.
Someone else will do the building, not Emmet. Their task is repeatable.

Shoot, Neglect or Train?

jo2sn Enterprise IT, Softwaretesting , , , , , , , , ,

How you treat the bringer of (bad) news tells me a lot about the organisation and potential for business growth. Go Read Accelerate – that book is full of insights. One of the models, is the organisational types from Westrum:

[ Screen capture from the Kindle issue of Accelerate ]

Andy Kelk has a to-the-point description about Westrum on their blog:

To test your organisation, you can run a very simple survey asking the group to rate how well they identify with 6 statements:

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
  • On my team, information is actively sought.
  • On my team, failures are learning opportunities, and messengers of them are not punished.
  • On my team, responsibilities are shared.
  • On my team, cross-functional collaboration is encouraged and rewarded.
  • On my team, failure causes enquiry.
  • On my team, new ideas are welcomed.

The respondents rate each statement from a 1 (strongly disagree) to a 7 (strongly agree). By collecting aggregating the results, you can see where your organisation may be falling short and put actions in place to address those areas. These questions come from peer-reviewed research by Nicole Forsgren.

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture

So when a passionate person comes to you with (bad) news, what do you and your organisation do? Do you reflect, ignore or hide the request? Do you say that it’s not a good idea to bridge the organisation? Do you raise an Non-conformity and set in motion events to bring “justice”? Do you experiment to implement the novel ideas and actively seek information?

FAIL = First Attempt In Learning.