WardleyMapping
Understanding the landscape is critical whether you're facing any new situation. One technique that I consistently use is Wardley Mapping. Let me share with you a concrete example to visualize the landscape.
TeamTopologies
What matters is everything around the output - not the procedure/guidance/assessment itself. The way you wire your interactions with others is key to your team's success.
Compliance
Risks, Questions and Requirements are surely part of the tester's hierarchy of needs. As I am exploring new fields, I am seeing how these needs are also a key part of other competence areas' daily needs.
Resilience
Key learnings from directing the testing stage on test leadership and resilience testing in 2024.
Leadership
Contrary to what you might think, hoarding power and being involved in everything is not a powerful move. The real influence is in making room for others and lifting others up. Prepare the new generation in your field and enable them to grow. Cast the stage light on others.
EU-NIS2
Having company procedures for everything is nice. As a testing professional, you have unique skills to bring to the table in trying and testing the procedures - what's the worst that could happen?
Leadership
What is blocking us is the perception that our testing skills cannot be applied outside (software) testing. Of course, they can, and often they are exactly what is required for other parts of the organization to grow.
Resilience
For the next sprint have a disaster recovery test. Of course, you have a plan for that! Having a plan for a disaster is nice but remember the old saying that backups are irrelevant if you can’t restore. So do test your recovery plans as well.
StaffLevel
Individual contributors can convey leadership both in roles and activities without being in the formal organizational management hierarchy. The practical organization for this can take many forms.
all things relating to test strategy, leading testing and compliance activities as an individual contributor on a staff career level.
We need to be better a confirming the requirements consistently and continuously - also the compliance and non-functional requirements. The best way to do this is to go slow and build instrumentation along the way.
Recently, I was discussing test leadership with an experienced practitioner in the agile testing space 👋. The topic of aligning with management came up again. I skipped the topic then. But afterward, I kept pondering the question: How can we get better management buy-in for testing?
The Product Risk Analysis is biased toward functional risks. Let's consider a broader picture of the solution under test.
There are so many places where testing happens. Everyone plays their part. IT testers don't own the words "test" or "quality" - we are not the only ones who can design and perform a test.
We have long fought between functional and non-functional requirements in IT systems development. A new requirement character—compliance—is entering the stage, requiring you to broaden the scope of the testing activities.
There was a standoff in a recent project of mine. It had no gunslingers, hangman’s rope, or a pot of gold. The standoff was about how to work.
Is this the first time you have a compliance testing challenge? It's not my first time.
