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.

Lessons Learned in Cloud Testing

For reasons of regulations and data restrictions, we were recently doing a cloud project for a large customer of ours. Cloud resources had to be spun up, granted access to, utilized, and taken down (CRUD-like). But we had to do it without granting any of the customer’s employers access to the cloud controls. They couldn’t even have a cloud admin. So for various organizational reasons, we designed the solution below.

The user would order cloud activities in a “shop” and the requests sent first to the customer ticketing system, then to our ticketing system. And finally to the cloud pipelines and scripts. And there my friend is where the testing started.

Testing Input Sanity

The first script was for initializing the cloud services: Ressource Name. First of I found out the (cloud) developers had already tested the happy paths. I loaded Bugmagnet and gave some funny names, as the requirements for that field hadn’t really been that specific.

https://bugmagnet.org/

I quickly learned that the cloud provider was already sanitizing the input, so no Little Bobby Tables were allowed. It made the customer think, though, and she added a rule for the shop with regard to the Ressource names. This was coded as a regular expression (Start with a capital letter, then some letters, perhaps some numbers) – not that we or the cloud cared for that strict naming scheme, it was more of a business usage rule. Was that a bug? No mostly something that testing finds – not a bug.

I Found A Bug- Can I Go Home Now?

The next request could assign privileges to the cloud resources. Based on the resource name and Access Level, the cloud resources would be enabled. Among the access level options was “admin” rights. Which was directly opposite to the whole purpose of the project, and the customer risked breaching the regulatory inertia/controls.

And that was really the only formal bug we logged. And I don’t go home – I quickly reached out to the team, had the Accces level parameter removed and all was good. The intention was all along that only one contributor access level should be granted. That level was then hardcoded in the code repository.

And then we tested further around creating things already created, revoking resources that were not there, and race conditions for revoking the services. The only thing that really gave us a challenge was when a request failed (say you request something already there). Having the two ticking systems pick up the response and send the error message back to the users was more trick than expected as they were more REQUEST focussed – but we managed. Without creating a bug the team worked together and resolved the issues.

Key Learnings

As always this is a story retold from actual experience, there are details I can’t share and elements I preferred to have done differently – but due to the organizational culture had its own way.

• A mindset toward input sanity and access control is key to supporting business goals
• Bugs, issues, and observations will be found they are learnings for the team, not problems
• Hold end-2-end rehearsals of the solution and play out the scenarios
• Don’t restrict the testing activities to software development, look at the whole solution

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

#267 – Reminder – it’s about Story Shaping

In agile delivery teams, it’s recommended that stories and features are discussed before being developed. A checklist called “Definition of Ready” can be used as a reminder to check that the delivery team has everything needed to prepare the delivery of the feature. A key ingredient is a shared understanding of how to confirm the delivery – for the whole team.

Story shaping requires at least three people to get together. They are not amigos nor amigas. They are often three, sometimes two people, and often more. They represent the different viewpoints needed to deliver: builders mindset, testing mindset, security mindset, operations mindset, business mindset, etc.

No one person can hold all these viewpoints – at least a builders mindset and a requester/business mindset is needed.

If you skip doing story shaping your acceptance criteria and testing activities will be misaligned. And you will either have overdone the effort needed or underestimated the challenges of the story.

One customer, three people to do the story shaping

#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.

Grogu agrees

Stop Writing Overdone Test Plans

While I have previously talked about writing down expectations and alignments – I would much prefer a more lean and up-to-date approach to test plan documents. Looking at what we know now, an separate test is more of a sign of missing trust between parties than a collaborative value add for the business needs.

Trends for the Tester Role

YMWV – this is a model for reflection not to a 1:1 scale of everything in the universe. It might be useful.

The space for the testing professional is under pressure – for my own role and even more for the “traditional” testing professional. At least since 2017 there has been a shift and ongoing disruption. I finally have a form to visualize some of the trends that puts the role of the tester under pressure:

• SIT / UAT debate
• Low-code trend
• Modern Testing
• Quality Engineering and whole team approach

I still see two key areas (stars below) for the classic tester to move into: exploratory testing based on weak signals and supporting the end-users low-code activities (test tool smith). For the more managerial and coordinating role I will have to get back to you in a future blog post.

Darlings, Pets, Cattle and GUID’s

Kill your darlings and treat your tests more like cattle than pets, are among some of the heuristics currently around for managing your environments and automation test suites. These heuristics tells me that the environments and automation are in a state of product or even commodity, while previously the tests and environments where like darlings and pets – named and nurtured.

The Testing, not the Testers

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!

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, their 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 their systems. So to them 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.